Tag: Strategic & Business Management

Achieving the Elusive Work-Life Balance

Written by Neal Whitten,PMP on July 25, 2017. Posted in Articles. 5 Comments on Achieving the Elusive Work-Life Balance

I have personally wrestled with my own work-life balance issues for most of my adult life. In my younger adult days, I could easily have been categorized as a workaholic.

I was divorced after a 17-year marriage and did not see the break-up coming. I’m not saying that a better work-life balance would have saved the marriage, but a poor work-life balance sure didn’t help it any. For me, the integration of my work life and my non-work life has been a rough ride at times but—as a senior-aged person—I have learned a massive amount of knowledge and, dare I say, wisdom, about the highly important subject of finding a satisfactory harmony across all aspects of life. My mission here is to present you with some starter ideas that can fit into a relatively short article—ideas that can help you not only better understand your work-life balance but to give you ideas that can help you achieve the integration that is most important to you.

Work-life balance can mean something different to each of us. For purposes of this article, work-life balance is about achieving an acceptable harmony or integration between your work life—or career—and your personal life.

Studies show that a poor work-life balance can result in unhealthy levels of stress and unhappiness. At risk are your personal relationships, your career and your development as a person, to name a few. Moreover, too much time spent working has its own problems. You run the risk of burning out and hating your job, maybe even yourself. You wake up one day and realize you’re not happy with your life.

What does matter is that you create a personally meaningful life that helps you feel happy and healthy overall. While balancing work and non-work life might not be easy early in one’s career, figuring it out is necessary to lifelong satisfaction. Almost everyone wishes that they had realized the importance of life balance at the beginning of their career. Doing so would have meant less regrets and a more deliberate life. But whatever your age, you can still seize control and drive towards the balance you most desire.

I have created an assessment instrument—called the Questionnaire for Self-Assessing Your Work-Life Balance—to heighten your awareness of the behaviors that are affecting your work-life balance. The questionnaire will also provide a means to rate your collective behaviors and present a score that can give you insight into your effectiveness in achieving work-life balance. You can download the PDF and take the quiz now or later at your convenience.

Let’s examine eight important actions and behaviors that can help you in your quest to achieve the elusive work-life balance.

1. Create a Vision for What You Would Like Your Life to Look Like

Ask yourself what you would like your life to look like both from a career perspective and a personal perspective and how you see these two major components integrating. Then define what you envision a typical, desirable day would look like beginning from the time you wake up until you call it a day. That day could have interaction with family members, time for exercising, eating healthy, of course time for work activities, personal chores, special events and some downtime to compose and reenergize yourself. Use this vision as a baseline to ensure that you steadfastly adopt actions and behaviors that move you towards your vision. Then define the priorities in your life that are important to support this vision—including those priorities that are non-negotiable except for emergencies; examples could be special family events, sleep and exercise. The bottom line is that in order to improve upon your work-life balance it is essential that you have a vision of what you would like that integration to look like. If and when you would like to create a vision, I have created a sample vision to give you an idea of what a vision could look like.

2. Set Your Priorities Each Day

At the start of each work day, create a to-do list that includes the identification of your top three priorities to focus on for the day. If you have timeframes available of 30 minutes or more, do not work the bottom items of your to-do list, focus instead on the top three. Your top three items are so important that they define your overall value, contributions and success in your job. Work off your top three priorities every 2-3 days and replace them with your next set of priorities. If your top three priorities may take weeks or months to resolve, then, within 2-3 days, put a detailed, trackable plan in place to deal with the priority. Then remove that top-three priority from your list and routinely track your new plan until it is complete.

If occasionally you experience a day that is so hectic with fire fights and please handles that you never get around to working on your top three priorities, that’s okay; you work in a complex, demanding environment. However, if you frequently have days where you do not focus on your top three priorities, then you are the problem and need to seek help to effectively manage your workload.

Advertisement
[widget id=”custom_html-68″]

If your personal life is as chaotic as your work life, consider creating the to-do list for non-work activities as well.

3. Track Your Time

For one week, keep track of where and with whom you spend your time during your waking hours both at work and in your personal life. Record in increments as small as 15 minutes. The objective is to identify time well spent that support your priorities and interests as well as time that—looking over the big picture—was not considered put to good use. This exercise is invaluable as you look for ways to fine tune your behaviors throughout each day. Experience shows that you will likely experience some “ah-ha” moments as you look more objectively into your routine behaviors.

4. Limit Time-Wasting Activities and People

This action will free you to spend more time on the important activities and people, and will likely provide you with additional time that you did not realize you had. Not only will your productivity benefit, the quality of your work and the satisfaction you get from your work likely will also increase. Many people spend too much time on things that don’t really matter. Time, arguably, is the most valuable commodity in life: It is the one thing you cannot buy more of. Therefore, don’t waste it.

The last tip we had discussed, “track your time,” can help here. Also, as your day unfolds get in the habit of consciously questioning if the time you are about to spend or the time you just spent is, indeed, an effective use of your time. After a while, this can become second nature and you will more effectively choose the areas where you dedicate your time.

5. Learn to Say “No”

Ensure that your commitments mostly support your priorities. Your inability or unwillingness to say “no” can easily allow you to lose control over your day and those things that matter most to you. If you need to buy some time to think about your final decision of whether or not to say “no,” then do so—even sleeping on it. Use whatever methods will help you better control where you commit your time. If you do not seize control over the commitments you make, your time will be surrendered to others… and you will not like the impact to you. You have far more control over your day and how you spend it than you may realize.

6. Minimize Time in Meetings

Minimize time in meetings, especially unstructured meetings. Most people spend a large portion of their time in meetings. Obviously some meetings are important for you to attend but many may not be providing you a sufficient return on your invested time. For starters, consider only attending meetings if they satisfy one or both of these conditions:1. Information you need to perform your job will be disclosed, or2. You have information that someone else needs to perform their job.

If you have information that someone else needs, consider turning that information over to the dependent person before the meeting starts and don’t attend the meeting. If you feel you must attend the meeting then do so only for the time necessary to disclose the information—say 5 minutes. Work with the meeting leader to determine the specific time when you should attend.

For meetings that you must attend, consider having a buddy who must also be in the meeting cover for you and afterwards inform you of what you need to know. And you reciprocate by covering for your buddy in a different meeting that you both also must attend.

7. Put Yourself First

Take care of yourself. Look out for yourself. Putting yourself first goes against what many of us learned growing up. But think about it: By putting yourself first, only then can you be your best and give your best to others. An example is on an airplane and the oxygen masks drop due to a potential emergency. You are directed to place the mask on yourself before helping someone in need next to you. You must make sure that you are in a position of strength before you can be your best for all that which comes your way and all those who may have a dependency on you.

Another example of putting yourself first is protecting your private time. Don’t be so quick to sacrifice your private time for other work and personal events. Your private time may be essential for catching your breath, recharging your energy and reaching a level of understanding and acceptance with yourself and all that going on around you. If you have serious work-life balance issues, not putting yourself first was likely a major cause of the dilemma you now find yourself embroiled in.

8. At the End of Your Day, Assess How Well Your Day Went

Pause and sit back to catch your breath. Then identify the actions you took that supported your quest for work-life balance. Give yourself some kudos for taking these actions. Also identify those actions that harmed your work-life balance. Imagine how your day could have been more productive and meaningful had you not engaged in the harmful actions. Ask yourself what you could or should have done differently so that you can change your behavior the next time a similar situation arises. See yourself incrementally growing stronger day to day, week to week.

Closing Thoughts

You get to define what work-life balance means to you. Balance is an individual thing and everyone must find their own. It’s not about what others think; it’s about what you desire for you. You achieve work-life balance by first defining the balance you most desire. Then you examine your current life and decide if that balance is being achieved. If it’s not, then, starting with the ideas presented in this article, you can put a plan in place that will deliberately move you into the desired direction. Then periodically revisit your work-life balance situation and adjust your actions and behaviors where and when needed.

Your work-life balance is something that can easily be put off for another day, another week, another year—but you already know that. Now is the time to seize the control over your life and to make it the life you most desire. It’s possible that this article could be the catalyst to change the rest of your life.
Now, become your imagined self!

From the Sponsor’s Desk – Lessons from Small Projects Are Scalable

Written by Drew Davison on July 19, 2017. Posted in Articles. 3 Comments on From the Sponsor’s Desk – Lessons from Small Projects Are Scalable

According to a 2012 Gartner study, “Small is beautiful — or at least small projects are easier to manage and execute.

The failure rate of large IT projects with budgets exceeding $1 million was found to be almost 50% higher than for projects with budgets below $350,000.” The survey was conducted to provide insights into IT project performance in organizations across North America, France, Germany and the United Kingdom.

A 2012 McKinsey & Company study in conjunction with the University of Oxford looking at 5,400 large scale IT projects (projects with initial budgets greater than $15M) found that 17 percent went so badly that they threatened the very existence of the company. On average, the study found large IT projects ran 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted.

And the problem isn’t just related to so-called “IT projects.” In a previous post, The Wonders of Wishful Thinking, we tackled the challenges of managing mergers and acquisitions. I included a quote from Roger L. Martin from a Harvard Business Review article: “M&A is a mug’s game, in which typically 70%–90% of acquisitions are abysmal failures.”

What’s puzzling to me is how organizations can continue to deliver successful, small projects yet stumble badly on large projects especially when the lessons from small projects are scalable! As we’ll see in the following case, the approaches that work on small undertakings are equally applicable to large scale projects, IT oriented or otherwise.

Thanks to R.A. for the details on this story.

The Situation

This large American-based worldwide technology organization was struggling with its sales performance. While sales were increasing in absolute terms, the rate of growth on a year by year basis was declining, and that decline had been accelerating over the last four years.

Senior management had looked at the issue and had brought in some consulting organizations to assess the problem. The findings included well-regarded and competitive product lines, good cost control, productive design, manufacturing and distribution practices and effective customer service. The primary problem most studies identified focused on sales staff productivity. That problem was compounded by the organization’s strategic reliance on the sales organization as the conduit for client satisfaction, retention, and growth.

The organization had hired a new VP of Sales six months prior. He was fully aware of the studies’ findings and conclusions. He understood the strategic significance of the sales force’s performance and capability. He recognized that improving sales staff productivity was his number one priority. So he launched a program to remedy the situation. He called it Ever Better, or EB for short.

The Goal

The VP of Sales established the following goals for his Ever-Better transformation program:

To increase sales numbers by 5% annually over the next five years

The scope of the initiative would include all management, sales and support staff within the Sales organization with assistance from the Information Services organization and external consultants as required.
The content would cover all policies, processes, practices, locations, and technologies
The direction and timing of the remedies would be determined through discussions with clients and then active engagement of all Sales Department personnel
Solutions would be delivered in small incremental releases on an office by office basis.
Success would be measured by annual sales growth, client satisfaction, retention and growth and sales force satisfaction, retention and growth.

The Sales VP established a budget of $2 million and a fourteen-month target to complete the changes. He believed that would give him a one-year payback, a necessity if he hoped to achieve his 5% annual sales growth goal.

Advertisement
[widget id=”custom_html-68″]

The Project

The Sales VP had worked with a project manager on a similar challenge in a previous job. They worked well together and delivered terrific results. The Project Manager was a straight shooter and outstanding leader, exactly what the Sales VP needed right now. So the Project Manager was offered the position. He accepted.

As soon as the Project Manager was on board, the Sales VP and Project Manager closeted themselves for two days to plan their approach, shown below:

Framework for Ever Better Transformation Program

The PM charged ahead and booked meetings with their client executives around the globe over the first few weeks. He followed that up, booking meetings with all their sales and support staff. He also developed a structured facilitation agenda for the meetings to get the most out of the time available. And then the meetings happened. It was a whirlwind of flights, hotels and meeting rooms, facilitations, note taking and feedback. After five weeks, they had covered 90% of their clients and 94% of their sales and support staff. The findings were illuminating:

From the clients:

Inconsistent follow-up to replenish inventory and address issues
Lack of information on new or enhanced products and services
Unreliable fulfillment of orders
Sales contacts were by product line. Sales staff lacked an overall view of clients’ dealings with the company.

From the sales and support staff:

Lack of an overall view of a client’s dealings with the company was often a source of embarrassment and ill will
Time-consuming process to access a client’s order history across products
Sales staff kept information on a client’s communications and so was not accessible by others
Announcements about new products and services varied by product line, some going directly to the clients, others to sales staff only and some to both

From the sales managers:

Very little information was available on individual sales staff plans and performance to manage and guide development
Organizing sales staff by product line made it very difficult to get comprehensive client views.

The Sales VP and PM saw four areas of opportunity to improve sales performance:

Align sales staff by customer, not product line, with appropriate adjustments to sales and service compensation and recognition programs
Provide sales staff with client views showing order history and client communications from all sources
Provide sales managers with comprehensive dashboards to plan and monitor performance by client, staff and product line
Improve new product introduction processes, so clients and sale staff received the information they needed in a coordinated and timely manner.

While the last item about product introductions was outside of the Ever-Better program scope, it was low hanging fruit that couldn’t be ignored. The Sales VP and PM met with executives in the product development organizations to apprise them of their findings and get their commitment to improving the process. They were met with enthusiastic responses and promised to revise and standardize their processes.

The Sales VP and PM continued to work the plan, organizing a talented group of business, IS and contract resource to develop the target architecture including:

organization changes to bring a client orientation to all sales activities
resulting process changes
new technology solutions to provide sales staff and managers with anywhere, anytime access to their information and functionality
new web functions for clients to review product specs and order online
interface changes and conversions from existing sales applications

The architecture group recommended two SaaS solutions to address the technology needs of the sales staff and managers. They were market proven and would allow the project to deliver quickly. They also accelerated and shaped the follow-on discussions about priorities and phasing and staging options.

Throughout these stages, the Project Manager organized and ran the day to day efforts. The Sales VP communicated and dialogued broadly with his staff, keeping them up-to-date on progress, soliciting feedback on plans and proposals. He engaged with his clients on plans and progress, in person and remotely. He kept his executive colleagues in the loop on a regular basis. Almost half of every day was committed to the Ever-Better program.

Initial implementations involved an office at a time and a subset of the planned functionality. In fact, the first implementation occurred in month five with a limited slice of functionality and barely satisfactory results. Pizza and beer with the Sales VP along with lots of laughs and rapid fixes left everyone feeling positive about the future.

That story was repeated across the sales organization and created a culture of openness and problem solving that paved the way for future iterations. Extra attention was given to the sales managers and staff and their clients. Facilitated feedback sessions highlighted successes and brought out opportunities to improve the introduction and implementation processes and the delivered solutions. Learnings and findings were applied to subsequent rollouts. And so, the Ever-Better program progressed through to completion.

The Results

The Ever-Better program was completed in sixteen months versus the planned fourteen months at the cost of $2.3 million, $300,000 over the original budget. The extra time and cost were due to expanding the scope to integrate product launches and enhancements into the program. Total sales increased by 4% in the first year, 9% in the second year and were trending well above the target 5% in the third year when I was given this case.

There were some challenges. Sales on a couple of product lines fell as the sales force was transitioning to a client centered organization. There were some resignations among the sales staff, also because of the client orientation. The problems were addressed expeditiously and the fixes included in future rollout practices.

Most impressively, client, sales management, and sales staff satisfaction levels all experienced double-digit gains each year to midway through the third year.

The Title of this post is “Lessons from Small Projects Are Scalable.” At $2.3 million, the Ever-Better program isn’t a small project. Costs through the first few implementations were only $450,000. The costs incurred after that were simply replicating and expanding a proven, tried and true solution. The foundation had been laid. What came after was simply building on and benefiting from a solid, comprehensive base. The lessons did scale remarkably well.

How a Great Leader Succeeded

There is no question the Sales VP owned this problem and this project. His influence was felt throughout, from the project’s goals and scope to the selection of the PM, the discussions with client executives, sales managers and staff and ongoing updates to all concerned. There are ten factors that help explain the project’s success:

Executive sponsorship – ownership, passion, promotion, enlightened leadership
Clarity of vision – end results, roadmap, priorities and context – relations to corporate mission, vision, goals, strategies, priorities, culture and core values
Small is beautiful – time, cost, scope, impact, phased and staged
Focus on results – benefits, practices, behaviors, attitudes
Understanding worth – realistic benefits, relevant budgets and timelines
Engagement – commit, socialize and celebrate with everyone affected
Talent – the right skills, the right attitudes, when needed, in the quantity required
Collaboration – active participation in problem-solving and solution development
Communication – up, down, sideways, in writing, in person, over social media
Measurement – overall sales, sales by product line, by client and satisfaction levels all around

So, be a Great Leader. Put these points on your checklist of things to consider on your next project so you too can successfully scale from small to large. And remember, use Project Pre-Check’s three building blocks covering the key stakeholder group (including the key stakeholder roles), the decision management process and Decision Framework best practices right up front, so you don’t overlook these key success factors.

Finally, thanks to everyone who has willingly shared their experiences for presentation in this blog. Everyone benefits. First-time contributors get a copy of one of my books. Readers get insights they can apply to their unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details, and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights.

Avoid the Top Three REAL Causes of Scope Creep

Written by Robin Goldsmith on June 5, 2017. Posted in Articles. 6 Comments on Avoid the Top Three REAL Causes of Scope Creep

Scope creep, changes to requirements after they presumably have been settled, is surely the biggest reason projects overrun budgets and schedules, yet still fail to deliver desired results.

This isn’t news. It’s been known for a long time. Lots of explanations and solutions have been offered over the same period, but scope continues to creep.

I find our scope creep dilemma is due largely to what I call “conventional we’s dumb” reflecting widespread but nonetheless mistaken understanding of scope creep’s REAL causes and the ineffective solutions which inevitably result.

For example, perhaps the most typical responses to scope creep are to blame change control procedures for not preventing changes and the project manager for “poorly managing the project.” Adding further procedural overhead mainly creates resistance, and a project manager who has been beaten up may learn how to hide things better but probably continues to have the same kinds of creep. Their supposedly better-managing successors also almost certainly suffer similar or worse creep. The blame game cycle repeats and projects persist in failing. Sound familiar?

Scope Creeps Because …

My analysis indicates that the overwhelming reason the scope creeps is that the scope was not defined correctly in the first place. Thus, the scope is not creeping, or at least not as probably presumed. Rather, what’s changing is awareness of what the scope should have been all along.

The negative impact of incorrectly-defined scope grows geometrically when the organization’s processes and procedures first fail to recognize this fundamental cause of creep, and then especially when they tend to impose all manner of counterproductive reactive behaviors, such as inquisitions to punish project managers and.often-mindless mechanical administrative restrictions on the changes they actually desperately need.

In Turn, Because …

I’ve found three main frequently-interrelated reasons why defined project scope so often is either wrong or at least not right.

1. Defined in Inappropriate Terms

Most projects I encounter have a one- or two-sentence scope statement which generally consists of objectives or desired benefits. Objectives indeed are essential for project success. In fact, success means achieving the objectives. However, scope defined in terms of objectives cannot help but creep because nobody knows what they’ll get. Each person has his idea of what will achieve the objectives, and there’s a good chance their idea doesn’t match someone else’s, but nobody recognizes it.

Alternatively, some project scope is defined in terms of tasks to be performed. Vendors who have succeeded in business use this method. Because the vendor can control the tasks they perform, defining project scope as tasks enables the vendor to be sure they can satisfy contractual commitments—regardless whether the client’s needs have been met. Ironically, if/when the client’s needs are not satisfied, it creates an opportunity for the vendor to propose follow-on work doing additional tasks which presumably will meet the client’s needs. If the vendor does the promised added tasks but still does not meet the client’s needs, round and round it can go again.

2. Defined (Often Dictated) Prematurely

I find that many projects are destined to fail because the scope is set, typically in concrete, prematurely. Scope definition is premature when it’s not based on adequate information. Many projects are initiated by executive pronouncements which too often dictate project triple constraints—scope, budget, and schedule–without sufficient understanding of what’s needed or what it will take to accomplish it. Executives tend to presume mistakenly that their position alone imbues them with the necessary knowledge. It doesn’t.

Some organizations have formal project initiation procedures to assure project decisions, in fact, are based on suitable information and reliable decision making. Such procedures usually are called “feasibility analysis” or something similar and typically include formal cost/benefit Return on Investment (ROI) financial analysis.

While these analyses can be done effectively, too often, they are all-form-and-no-content expensive window dressing that gives only the illusion of well-supported decision making. Cutting through the rigmarole frequently reveals only findings to support the result that the advocating executive wanted to dictate all along.

Organizations that consider themselves Agile may not be defining the scope explicitly at all. They may simply leave it up to the Product Owner to decide what goes into the backlog, which some may consider defining the scope. Also, Agile projects would seem highly unlikely to have formal project initiation procedures. Recognize though that these Agile actions actually may reflect informal, implicit decisions that are equally premature. Thus, the backlog may include only stories that fit the Product Owner’s possibly fuzzy impression of what is in scope; and that impression could constantly change, though perhaps without awareness or thoughtful consideration.

3. Predicated on Presumed Product

Especially, but by no means only, Agile projects generally define their project and thus its scope based on the product/system/software they expect the project to produce. That’s all well and good unless the product is not right—which happens far more frequently and to a far greater degree than ordinarily is recognized.

REAL Business Versus Product Requirements

There’s another even more important but seldom-recognized fundamental problem with focusing first on the product, and this problem is a major reason presumed products turn out to be wrong. Products do not themselves provide value.

A product provides value only to the extent that it satisfies what I call REAL Business Requirements—business deliverable whats that provide value when satisfied by some product/system/software how.

Creep largely occurs when the presumed product feature hows fail to satisfy the REAL Business Requirements whats, usually because the REAL Business Requirements whats have not been defined adequately, in turn typically because “conventional we’s dumb” mistakenly says the product features hows are the requirements.

Scope doesn’t creep nearly so much when the scope is defined as high-level REAL Business Requirements deliverable whats that provide value by achieving objectives when satisfied. Moreover, when the scope is defined in business terms everyone can understand reasonably the same, misunderstandings, miscommunications, and creep drop dramatically.

Recognize, though, following an appropriate model is only the starting point. It takes time for informed, skilled, integrated data discovery and analysis to identify the right REAL Business Requirements right. Often they are not evident or as presumed. As discovery and analysis proceed, the scope can and should adjust as understandings improve; but when done right, such adjustments will be far less and far less disruptive than conventional creep.

10 DOs that we DON’T in Project Management

Written by Bola Adesope on May 26, 2017. Posted in Articles. 2 Comments on 10 DOs that we DON’T in Project Management

I recently led a team on a four-week mini-project to conduct an independent research study on the art of project and program management across four sectors within the African market.

I must say that the result of the study is both interesting and surprising.

The study uncovered many actions by project managers that don’t align with the best practices project management. I have compiled the top ten “DOs that we DON’T.”

1. Project Charter

The Project Charter according to PMI is the document that among other things announces the existence of a new project or project phase. The project charter identifies the project manager and sponsor and authorizes the project manager to commit the resources of the organization to project activities. Best practices indicate that projects should not start or commence without a Project Charter approved and signed by the sponsor, but I found out that 98% of projects have no project charter. Lack of formal approval for the project is saddening and begs the question, “On whose authority are you running the project?”

The Sponsor might have the time and competence to write the project charter, but the responsibility is delegated to write the project charter to the Project Manager in some cases. Either approach achieves the best practice outcome of having a formally signed project charter.

2. Project Governance Structure

As a best practice, having a clear project governance structure identifies the responsibilities of decision-makers, escalation paths for critical issues and risks, and change control. You can understand how dumbfounded I was, after analyzing the result of our study to find that over 90% of projects do not have a Governance Structure.

Most Projects had no Governance Structure, Change Control Board or Steering Committee. Who then provides direction for the project? It is hard enough to get people committed to a course. Not having a leadership and governance structure will only kill the project.

3. Physical Sign-offs

People often forget things. Desires and needs change for a project because of so many different things happening on inside or outside of the project. Best practice teaches us to always obtain physical sign-offs on deliverables such as Design Concept, Requirements Document, Project Plan, Change Request, and other critical project management documents. Surprisingly, many projects used verbal approval even though historically verbal approval has been shown to be less effective than a physical sign-offs.

4. Proper and Adequate Scope

Project scope is the foundation of project planning. It informs all sponsors and stakeholders of the boundaries for the project. It includes deliverables, features, and final products. Our study revealed that many projects do not have an adequate and proper scope document. Even in the Agile methodology, there are user stories which outline the scope of the sprint and combined with the Product and Sprint Backlogs that detail capabilities that remain to be delivered. The lack of a specific Project Scope Document often resulted in scope creep which at the end of the project led to budget overages, unapproved product/deliverables, and schedule delays. Allowing an incomplete or missing Project Scope document to exist without challenging it is setting up the project for failure and akin to digging the project’s grave.

5. Project Management Plan

A Project Management Plan is like a manual, blueprint, and compass for managing the project. When asked for the Project Management Plan, a high percentage of the PM practitioners responded with a project schedule developed using Microsoft Project, Primavera or Microsoft Excel. A project schedule only speaks to timelines, tasks and resource assignments. A project schedule does not include a communications plan, risk management plan or other critical planning documents the govern the project, and its processes. A project management plan does not have to be bulky, but it must capture the approach towards managing all the components (scope, cost, communication, risk and issues, quality, resources, stakeholders, change, and integration) on the project. Lots of practitioners did not create a project management plan for their projects.

6. Risk Register Update

A risk register or risk log is similar to the project management plan in that it is a living document that is continually updated. Although few practitioners managed to create a risk register or risk log, they did not update it regularly. Good practice is to have an agenda item at every project meeting to review the risk register. It baffles me how the risk register becomes a one-off document that is created once and abandoned considering the highly unstable project environments.

7. Verbal and Written Communication

Best practice Project Management recommends that we explore and plan for both verbal and written communication with a strong preference for written communications. Our research indicated lots of practitioners do either and not both. Of interest was a category of people that responded by saying they usually utilize verbal communication via telephone calls or hallway conversations but never followed up those discussions in writing with an email. If you have spoken to a stakeholder and a decision was on a project, it is best practice to send an email after the verbal conversation to recap the decision.

Most people send emails without asking for acknowledgment, or without sending an acknowledgment. Communication on projects and in life is a two-way process. When sending emails with some information, always ask for acknowledgment and feedback. When you receive an email, endeavor to send receipt acknowledgment.

8. Deliverable Review

The lack of Deliverable Reviews is particularly worrisome. I recently completed a strategic project where an outsourced tech-related component was sent to a vendor for the component construction. I lost count of the number of times the vendor indicated the component was completed only to find on review many errors and defects. Moreover, at those times I was thinking to myself like “Didn’t these guys review these features before sending out communication?” You can imagine how embarrassing it would be for your client to point out a seemingly obvious defect out to you on your project. Unfortunately, most practitioners do not conduct adequate reviews (or testing if you will) on accepting deliverables before communicating to clients. Keeping error away from customers is a good practice to increase the trust in the project’s ability to deliver with quality.

9. Lessons Learned

As a best practice, the Project Manager conducts a Lessons Learned session at the end of every project. Expectations are a Lesson Learned session will identify what went well, what did go so well, and identify recommendations for the next project team. In our research, over 95% of practitioners did not conduct Lessons Learned sessions talk less of developing lessons learned document. “Those who fail to learn from history are doomed to repeat it” clearly defines the purpose of Lessons Learned.

10. Project Closure

There are three potential conditions for closing a project:

The project objectives have been met.
The project objectives cannot be met.
The project is no longer needed.

The Project Manager has little or no control over the second and third instances. No matter the conditions for closure, the project must still go through the closure process even though many practitioners in our research did not properly close a prematurely terminated project as stated in conditions 2 and 3 above.

Bonus: Project Celebrations

Celebrating project milestones is an important team building activity. Do not skip the planning of a project celebration. Take the time to plan for project celebrations. In our research, most project teams did not celebrate after a successful project leaving the team feeling undervalued. Gather the team, have a drink, go to the club or have a party and celebrate!

In Conclusion

The objective of this write-up is not to expose bad practices but rather to awaken us and remind us of the best practices that we as Project Managers forget. Let me know your thoughts in the comments below. Are there best practices missing? What DOs and DON’Ts do you recommend?

From the Sponsor’s Desk – Slicing and Dicing for Success

Written by Drew Davison on May 25, 2017. Posted in Articles. 4 Comments on From the Sponsor’s Desk – Slicing and Dicing for Success

Change is all around us these days. Disruptive competition is the norm.

Organizations are frequently challenged to launch changes that are outside of their comfort zones, at odds with their cultures and beyond their skills and capabilities. So what should one do? Try slicing and dicing for success.

This case provides an interesting example of one company’s response to competitive pressures that were threatening its livelihood and longevity. It managed to implement an essential service in the face of long odds by applying some well-known, well-proven practices you are probably already familiar with.
Thanks to J.B. for the details on this story.

The Situation

This manufacturer and wholesaler made and sourced a variety of housewares and related products primarily for the domestic market. They had some regional warehouses to provide products to their retailing customers, either through pickup or local delivery.

Over the past five years, the company’s performance had been lagging. It was still making a decent profit, but it was not growing much, and the shareowners were getting restless. Senior management agreed to bring in a consultant to review their strategic plan and operating performance and get some recommendation to improve profitability.

The consultant examined the company’s operations and performance and their prospects going forward. He gave good marks to customer service, product quality, and operational effectiveness. Even marketing and distribution functions received good grades, with one glaring exception: Internet services. The consultant found seven web sites, one for each of their product lines. His assessment:

They were mostly brochure ware
They offered no or minimal e-commerce functionality
There was no cross lines linking
Each site had a different look and feel
It was difficult to update existing information and add and revise new products
The sites were based on outdated, unsupported technology
There was no tie-in to local or regional inventories
There was no tie in to customer buying habits and purchasing records

Essentially, the consultant discovered the company’s web services and infrastructure were afterthoughts, something which came in last when developing strategy and plans and delivering products and services. The company’s web offerings were not competitive. The company’s sales were not growing because the competition was beating them on the web services front.

The consultant recommended a complete replacement of the seven current web sites with a new, integrated offering based on current, up-to-date technologies. He suggested that such an offering could boost earnings by 30% annually. He indicated that failure to take action would put the company at an even greater competitive disadvantage and accelerate the company’s flagging fortunes.

The consultant also identified what he felt was a significant risk standing in the way of a successful web services upgrade – corporate culture. The business and IT groups were used to smaller, siloed, tactical projects, usually less than six months in duration. They used a typical waterfall approach and had limited project management capability beyond that. For the web services upgrade to make an immediate and lasting impact on corporate results, the consultant identified five essential requirements:

The ability to assemble and manage cross-organizational teams
The need to accelerate decision-making within the product lines and across the enterprise
The use of rapid development and delivery practices, preferably including agile methods
The development of a web services architecture to ensure a cohesive framework offering a superior user experience
The need for a secure, high performance web services infrastructure to host the new offerings.

The company’s executives reviewed the consultant’s finding and recommendation and decided to act. The CEO charged the CIO with making it happen. The CIO accepted the mandate.

The Goal

The CEO’s goal was to increase the company’s earnings by 30% annually through the implementation of the consultant’s recommendations. On the advice of the consultant the CEO also set a target of eighteen months for full implementation with a budget maximum of $2.5 million, excluding capital expenditures for infrastructure.

The Project

The CIO knew his organization had never handled anything this big and this visible. He reviewed his in-house project management talent and concluded none of them had the skills and experience to do the job. He tapped into his industry contacts to find a PM who would be able to handle the challenge and received a number of resumes. After screenings, interviews and reference checks, the CIO made his selection, Diane, a contract PM. Diane had fifteen years of project management experience including a number of multi-million dollar, enterprise-wide undertakings. She also had four recent web-related projects to her credit. Previous employers raved about her direct, no-nonsense approach, superb collaboration talents and exemplary leadership skills. The CIO offered her the job. She accepted.

Even before she officially started the job, Diane knew enough about the obstacles facing her to make some demands of the CIO:

Set up one hour meetings with each of the key executives to discuss their expectations, priorities, issues and concerns. The meetings had to happen during her first week on the job.
Start freeing up contiguous space for the forty or so business and technology staff needed for the project, along with meeting and break-out rooms and the necessary technology.
Pull together an IT web services assessment team to start building the selection criteria and a list of potential candidates
Start a candidate search for a user experience lead, an agile development lead and a web services lead. These three positions would be vital to the realization of the projects goals.

When Diane arrived on the Monday of her first week, she found progress on her requests well underway, including the scheduled meetings with the key executives. In these sessions, she asked each executive a series of questions. She also asked them if they were ready to serve on her key stakeholder committee, which customers should participate in the project and what they thought of the current web services. She received some interesting feedback.

Expectations and priorities were all over the map. The CEO and two of the other executives she interviewed saw no reason to participate in her committee. Five of the seven saw no reason for customers to participate. Four of the seven had never checked or used the company’s current web offerings, even after the damning report from the consultant. At the end of the week, she met with the CIO and CEO. She reviewed her findings and presented her demands; all seven of the executives, including the CEO needed to participate actively and representatives from at least two clients needed to be included. Failing that, Diane stated she saw no hope for the project’s success and would not continue. The CEO and CIO agreed to her demands.

With the CEO’s backing, Diane penned a one-page key stakeholder committee charter for the CEO to send out covering mandate, roles and responsibilities and assignments. She also booked committee meetings every second week for the first three months. She then met with each of the executives again, reviewed the CEO’s message and their vital role in the project, listened to their concerns and committed to touch base on a regular basis. In fact, this approach was Diane’s secret sauce – frequent contact and dialogue to keep each executive in sync and smiling throughout the course of the project.

Diane then pulled together an initial Web Service delivery plan. It was more of an approach framework than a plan but it served to move the dialogue with the executives forward. It emphasized a couple of points that she needed the executives to embrace:

the primacy of the web services infrastructure to enable the rest of the business function delivery,
the necessity of a high-level architecture to describe the target enterprise environment and guide the development plan,
the dependence on short-term iterations to move them forward,
frequent planning and prioritization exercises to ensure the project accelerated business value delivery.

The approach called for an initial web services infrastructure delivery by the end of month three and the first function delivery by the end of month four. With a few tweaks, the executives bought in.

With the CIO’s help, Diane then pulled together the Web Services Architecture group with senior leaders from IT Architecture, Application Development, Operations, Security, the business and functional groups and Internal Audit. The mandate of the group was to identify and agree on the key web services infrastructure elements and their relationships to each other as well as the potential impact on business processes, corporate functions and delivery practices. She also wanted them to identify potential opportunities for agile practices. Diane selected an Application Development manager to lead the group. The CIO and three other executives had identified him as a trusted and capable facilitator.

The group met in an intensive four-day session to hash out the initial model with comings and goings of additional expertise to cement the consensus.

Again, Diane shared the model with each executive, explained each element and passed on any issues or concerns to the Architecture group to refine as needed. The executives bought in.

While the planning and architecture work was progressing, Diane oversaw the other priority tasks including facilities, specialty recruiting and the initial prioritization exercise. One of the key decisions during this stage came from a review of the target architecture by the newly contracted web services lead. He suggested they restrict their search for new technology platforms to outsourced providers only. That would take months off the delivery plan and ensure fully supported current state solutions going forward. After an accelerated review and vetting with the Architecture group, prospective vendors, and the executive team, the company selected an outsourcing provider to build and manage a turnkey in-house environment. The in-house solution had a major advantage at the time, providing superior performance and security interacting with the company’s back-end systems.

The user experience and agile leads worked their magic as well, starting as soon as they were in place. The user experience lead formed her UI team with subject matter experts from the business and selected customer organizations, software, infrastructure and testing staff. The team used the planned three iterations to deliver the full web interface the product line teams required. The agile lead also worked with the UI team to help it become familiar with and apply agile practices. By the end of the third iteration, the members of the UI team had the new agile way down pat.

As the PM formed the new product line teams, she gave each the choice of learning and applying agile practices or operating in a more traditional way, but still within the established time boxes. The UX and agile leads transitioned their efforts to help the new teams get up to speed quickly. In addition, as the UI team wound down its work, the team members were moved to the product line teams to provide and reinforce the UX and agile practice knowledge.

The Results

The project was declared complete after almost two years and a cost of $2.8 million. While the project took longer and cost more than originally allocated, the executive team approved every dime and day along the way. And they did it with big, broad smiles on their faces. Earnings were up 20% after year one and in excess of 40% at the end of the second year.

Diane used her secret sauce of executive and stakeholder engagement to keep everyone informed, involved and satisfied. The project executed over seventy iterations, supporting the core infrastructure, core interfaces and bridges and all the line of business functionality. At the beginning of the project, less than half of the teams chose to learn and use agile practices. By the end of the first year, all the teams were agile.

Perhaps the project’s most significant impact was on the corporate culture. By pushing the executives into the prioritization and decision-making exercise at the project’s start, the collective mindset was transformed from parochial to enterprise. In fact, the first product line iteration selected was a “Company Specials” service on the new web site that would be used by all product lines.

How a Great Leader Succeeded

This project could have easily been just another one on that long list of failed ventures. Yet the organization made a successful and dramatic shift from a product line focus with small, tactical projects to a broad-ranging enterprise solution. How did they do it? There were seven factors that contributed to their success:

It’s a business project – The company’s executives got the ball rolling by hiring the consultant to address their concerns about business growth. The consultant kept the emphasis on the business with his findings and recommendations. It could have easily morphed into a typical “IT project” when the CEO tossed accountability to the CIO. Fortunately, he hired Diane as PM. She made sure the project stayed in the business’s court.
Culture watch – The consultant’s observation about the company’s culture and limited capability to run an enterprise wide program was very timely. Fortunately, the CIO and his PM took the necessary steps to shift and shape a new cultural viewpoint. Remember Peter Drucker’s sage saying – “Culture eats strategy for breakfast”. Fortunately, this company’s strategy managed to avoid being eaten.
Skills are paramount – The right skills at the right time turned out to be the game changer. Diane had the right skills for the time. So did the UX and agile leads. They knew what they had to do and how to do it. They were the force multipliers. They helped the organization move with them.
Priorities need to be clear to everyone – The iterative priority setting cycle was a wonderfully effective trap. Once the executives had a taste, they couldn’t get enough. Once they got involved, they had no choice but to embrace an enterprise view.
Think big, do small – The initial draft plan and target architecture established the big picture for all involved. That allowed the slicing and dicing that followed, to incrementally deliver to the priorities and to change the priorities as needed.
Agile practices work – Diane’s decision to allow the product teams to self-select agile was a stroke of genius. She built organizational knowledge and expertise with the UI iterations that was visible to all. Staff gained confidence in the agile practices and that rubbed off, creating a groundswell of support.
Communication is the tie that binds – Diane’s “special sauce”, touching base with executives and stakeholders, having a conversation rather than sending a report, or in addition to a report, created a rapport and level of trust that yielded honest, straight-forward understanding. Diane’s approach made everyone feel special.

It is always nice to tell a happy story. This is one such. The seven success factors described above are well known but often forgotten. Please don’t forget them anymore. Be a Great Leader. Put these points on your checklist of things to consider on your next project so you too can achieve great results. Moreover, remember, use Project Pre-Check’s three building blocks covering the key stakeholder group (including the key stakeholder roles), the decision management process and Decision Framework best practices right up front, so you do not overlook these key success factors.

Finally, thanks to everyone who has willingly shared their experiences for presentation in this blog. Everyone benefits. First-time contributors get a copy of one of my books. Readers get insights they can apply to their unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details, and we will chat. I will write it up and, when you are happy with the results, Project Times will post it so others can learn from your insights.