Micromanage? Not Me!

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

Do You Micromanage Your Team?

None of us like to think we micromanage. But it’s often a challenge not to micromanage your project team. Here are some common assumptions of PM’s who micromanage:

  1. You’re the project manager and that means you’re the expert on everything about the project…so you need to make all the decisions
  2. Your project team members want to goof off and do the least work required…so you frequently check that they are working
  3. You are the only one who cares about quality…so you thoroughly check their deliverables.

Are these assumptions correct? No, they’re dead wrong. Believing those assumptions will lead you to micromanage your team.  It’s easy to fall into that trap.  You’re the guru and can quickly solve all the problems for the team. Why take the risk of trusting the team members to make good decisions?  You can make better ones very easily. But think about the consequences. The micromanagement style hurts morale and it causes your team members to take no responsibility for anything. That will haunt you when you move up to larger projects. So it’s critical that you never micromanage your team.  Project Manager Skills Main Page

Don’t Micromanage: Lead

The better approach is being a project leader. This is very difficult for people who believe any of the assumptions listed above. Here’s how a leader differs from a micromanager. The leader holds their team members accountable for producing end results; the project deliverables. The leader clearly defines the deliverable by setting acceptance criteria.  For an experienced performer, the leader allows that team member to figure out how to produce the deliverable and helps only when needed. The leader gives this team member a lot of freedom and decision-making authority. For an inexperienced team member, the leader will sit down with them and work out the details of how to produce the deliverable. The leader will check the work more often until the team member demonstrates an understanding of their task. Then the leader gives the new team member a bit more freedom. The leader will also allow team members to take part in setting of the time and duration estimates. That encourages commitment to “hitting the numbers.”

Leading is difficult because you need to keep your hands off the team member while they’re working out their assignment. However, here are the benefits of trusting your team members:

  •  their commitment to the project and
  • their responsibility for producing good work on time.

Micromanage: An Example

Let’s look at how the sponsor spots a micromanager.

“Me, micromanage?” The PM scoffed as the executive looked over the 68-page Gantt chart with 1,279 tasks for a 3-week project.

The executive ran a finger down the column of task durations. “Yes, this is the work of a micromanager. I see a lot of one-hour meetings and three-hour tasks on this schedule. The only thing you missed was scheduling restroom breaks. People don’t like being managed this tightly. Do you estimate the work at that level of detail and then track actuals?”

The PM looked out the window hoping for a tornado or an earthquake. “Well, we are just a little behind in posting the actuals and doing our variance analysis. Some people are a little too busy to report status on 20-25 tasks each week.”

The PM smiled and said, “I guess I’m just a bear for detail. I like to really pin everything down. Anyway, our 5-hour status meetings are good for team-building. And I really know where we stand after those sessions. Best of all, we use the meetings to hone in on what we think we’re trying to achieve. Everyone’s ideas are welcome.”

“Oh really! Flexibility on the project’s objective is just great when you’re spending $2 million of the company’s money,” the executive replied sarcastically.

The PM responded, “Well maybe it’s just me, but I think that ‘delighting the customer’ and ‘providing world class service’ are a bit vague as objectives.”

The executive ignored that snide comment and said, “Exactly how far behind are you in tracking things?”

“Six months, give or take.”

The executive glared at the PM and said, “Do you realize that I spend hours talking to people and reading status reports about new functionalities, endless training courses and wondrous new processes? But I have no inkling of what your project is actually achieving for the business.”Micromanage

“Well we’re trying to detail that with…….”

This is not a pretty story. We often hear about PMs building these monstrous project plans but never using them to actually track and report project performance. Worst of all, the executives who sponsor these projects have no idea what the project will actually achieve for the organization.

Micromanage: A Solution

There is a simple solution to the micromanage problem. You can’t make up for lack of clear and measurable objectives with a long laundry list of activities. You can’t view the project plan as a “To Do” list of all the tasks the team will complete. When you micromanage at this level, it’s impossible to track progress. Instead, you must drive the project toward a business-relevant outcome. Then your project plan and work breakdown structure (WBS) become tools for planning and tracking the project’s measurable achievements. These are at a higher level than micro-tasks in a “To Do” list.

The benefits come not only in clear objectives and scope control, but also in the quality of the assignments you make to the team members. The plan and WBS tell each team member what they must deliver, not the details of how to deliver it. You let them use their knowledge, experience and creativity to decide how they will meet their objectives. You’ll have a more dedicated and committed team when you don’t micromanage them.

Read more about the problems that micromanagement creates.

Our project management courses and certifications for organizations and individuals teach you a step-by-step process that makes you a leader, not a micromanager.

Project Team Ground Rules

Project team ground rules are a necessity. Almost all project teams have frequent meetings and even more frequent communication in various forms. If the project manager doesn’t set ground rules for these meetings and communications, a significant amount of time is lost. Together, the project manager and team identify and formulate the ground rules that members of the team should follow when they interact. These rules cover video conferences, in person-meetings and telephone conferences. The ground rules can cover a wide range of team member and project manager behavior.ground rules

Project Team Ground Rules: Examples

The ground rules may include the “completed staff work” concept. That approach to meetings aims at substantially reducing the amount of time the team members waste when people at the meeting are not ready to discuss the topics. The completed staff work concept is based on an agenda. Anybody can add an item to the agenda. The only requirement is that they distribute materials to all the team members before the meeting. That allows everyone to come ready to discuss the issue. Another rule is that you cannot raise an issue at the meeting that was not on the agenda with preparatory materials distributed. These rules help avoid bad decisions being made when people have not had time to thoroughly consider the issues.

Other ground rules may deal with interpersonal conflict. As an example, a ground rule may prohibit discussing work issues on previous projects. Other rules may bar personal criticisms, (“you’re very stubborn”) versus criticizing behavior (“you would not listen to my side of the problem”).

It is very easy to get carried away with too many ground rules. You don’t want people to have to consult a lengthy document to decide how to handle an interpersonal situation. The ground rules should fit on one side of one piece of paper. Remember, the goal is to avoid wasting time in meetings or making bad decisions because people are  unprepared or rushed to make a decision.

Project Team Ground Rules: Project Meeting Scenario

A status report meeting I participated in some months ago lasted 2 hours. Approximately 20 people attended, including the project team, test leaders, team leaders, PMO staff, etc. The meeting had many elements that are considered best practices. They included the following:

  • all attendees sent the PM their issues before the meeting
  • the agenda was distributed before the meeting
  • no other issues were brought up in the meeting

Long story short, it went something like this. Each person went through the status report covering their work stream, what they did, what they were going to do, issues, risks, decisions to be made, etc. I noticed that after the first 30 minutes, some of the attendees lost interest. After one hour, most were either checking their phone or chatting about something with the person next to them. You can imagine how the situation was after 2 hours.

I share this example to make the point that following what are considered best practices does not mean you are efficient or effective. In the above example, if you calculate 20 people * 2 Hrs = 40 Hrs (40/8 =5PD) of effort for a single status meeting.  One meeting a week adds up to 260PD a year, which is a significant effort.

Project Team Ground Rules: The 30 Minute Meeting

Below is an approach that has worked for me. I call it the 30 minute meeting.

  1. Schedule important meetings early in the day. A meeting is a pit-stop (as in Formula One racing) where all the team members must get the overall picture. It must be kept short and to the point.
  2. The core of a status meeting is the status report. Prepare it beforehand. I like to prepare a presentation vs. a written document.
  3. A picture (or better a chart) shows no more than 1,000 words. The PM must give the bigger picture, showing all relevant charts in perspective. That includes the actual, planned, and forecast.
  4. All topics that are on track don’t need to be discussed one by one. They are only referenced in the status report (preferably in a chart). Include all the details in the appendix for the people who want to read it on their own time.
  5. Deal with topics that need bilateral attention outside the meeting. Time is precious so nobody is allowed to waste it. The PM must ensure the status meeting is not a place for everyone to dump their issues and problems.
  6. Keep it short and keep it clean. Be brave to exclude from the meeting all less relevant content. A short and to the point meeting is too important to be sacrificed for side topics.

Finally, a PM needs to keep the right balance of management overhead and actual work product in their meeting ground rules. My rule of thumb for overhead is not to exceed 10% of the total efforts. This approach to status report meetings works for me. It leaves the team energized, their attention sharp through the entire meeting and minimizes the management overhead.

Get free articles and videos like this every week

Failed Projects

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

“This project has to succeed; it’s critical to our organization. We can’t have a failed project!” You have probably heard this a hundred times during your career. Yet many organizations have lots of failed projects. Sometimes they’re as high as 70%.  The failure rate for projects sponsored by certain executives are even higher because they have no idea how to sponsor a project. Sometimes failed projects are delivering so little value to the organization that the executives stop work on them. But that’s pretty rare because often there is too much political and financial capital invested to admit failure.  So the failed project continues even when it is so out of control that no one can find a way to salvage it.

Most organizations don’t learn from their project failures so they have one failed project after another. In those organizations, 70% of the projects fail to deliver the scope for anywhere near the planned cost. Every project failure should lead to a detailed investigation of what went wrong. Organization must circulate that information to executives and project managers. Unfortunately, very often the failures are hidden and there is no investigation into what went wrong. Enterprise Project Management Main Page

Here are the three causes we often find in our review of clients’ failed projects.

Failed Projects: A Vague Scope Statement

Lots of projects have weak scope definitions. But on failed projects, the scope is so vague that it establishes few limitations on what is included in the project. So scope creep is rampant. People at all levels in all functional areas add new features to the project every week. Here are some examples of additions: new software that the IT department wouldn’t give them; new equipment that didn’t meet the capital approval process; other “goodies” that are good ideas but don’t create value for the project. Project Failure Warning Signs

The scope has to define specific deliverables the project must produce. That scope of the project must be approved before any work starts. The scope statement itself must include quantified acceptance criteria. These are metrics that can be objectively measured. As an example, a customer service improvement project might have a scope of “Less than 3% of the customers have to call back about the same problem.” That metric gives the executives, the sponsor and the project manager a tool to judge whether user requirements and change requests are necessary to produce the deliverable.

Failed Projects: Lack of Data in Planning and Tracking

Another characteristic of failed projects is project plans without data. They don’t have estimates of the hours of work required for the tasks and deliverables. Instead, the sponsor plucks a completion date that sounds good out of the sky. Cost estimates are also missing except for general wild guesses. As a result, people who are completing tasks or purchasing items have no constraints on the time or money they spend. This is bad enough during planning but it is disastrous when it comes to tracking actual results. Team members’ status reports don’t give the number of hours and dollars they have spent on their task and an estimate of the hours and dollars required to complete their tasks. Instead they give a subjective estimate like “I’m in greenlight status.” This doesn’t give the sponsor or project manager any ability to decide where the project’s problems are or even if they exist. Project Rescue

Failed Projects: No Accountability for Results

Finally, failed projects have little or no personal accountability for results. Some team members are working on a specific task. Others are part of a more general effort involving the entire project team. But few team members are held accountable for producing a specific deliverable, by a certain date, for a specified number of hours or dollars. As a result, it is impossible to identify who should solve a problem on a task.

Failed Projects: Summary

Here are the characteristics that all failed projects have in common:

  • They take place in organizations that have no standard project processes
  • The scope of these projects are vague
  • There are no standard planning, tracking and reporting processes
  • All projects are ad hoc. Each project manager makes up the rules about how to manage their project
  • No one is held accountable for delivering results

Organizations won’t change their project management processes until the pain from failed projects is too great to ignore.

Learn how to use project management best practices and avoid failures in our online project management basics courses. You work privately with an expert project manager. You control the schedule and pace and have as many phone calls and live video conferences with your instructor as you wish.  Take a look at the course in your specialty.

[button link=”” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=”00000000″]Consulting Projects[/button]

Project Plan Blunder #2 – Turf Wars

A project sponsor is meeting with the department managers who are her subordinates. She’s called them together to tell them their company is receiving terrible publicity. Their horrid customer service has made the front page of the local paper. She needs them to create a project plan to improve their customer service.

The sponsor explains that they need an integrated effort. Each of the four departments needs to cooperate with the others to bring about a significant improvement in the company’s customer service. When the project manager suggests that people in the various departments will work on tasks he assigns them, all hell breaks loose. The turf wars are intense. None of the managers accept the idea that people can work effectively on a cross-functional team. The project sponsor makes more speeches about the need for cooperation. The project manager tries to explain that isolated efforts in each department will not bring about the strategic improvement that the company needs.

Project Plans and Turf Wars

Project plan turf wars happen in many organizations.  When political battles exist between departments, the warring sides often suggest separate projects in each of the departments. They think that eliminates the need for cross-functional cooperation. But that never works. It also doesn’t work if there is a separate project manager in each department with the overall project manager coordinating all their efforts.  The idea of separate projects and project managers sounds good to people caught in inter-departmental conflicts. But successful project managers know that the way to succeed in cross-functional projects is not to subdivide them. That’s the easy step to take. It allows them to avoid solving the basic conflicts that exist.

Let’s look at the video and see how the project manager and sponsor do with their project plan. What would you do to end these turf wars and give the project some chance of succeeding?

Project Planning Blunders: Stakeholder Turf Wars

Top Down Project Plan

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

Creating the project plan is the first step in every project. The best practice is a Top Down Project Plan. To be successful as a project manager, you always need a project plan but length is not important. An excellent project plan of one page works well. The important thing about the project plan is the thinking that goes into it.   Project Planning Main Page

Top Down Project Plan: A Best Practice 

The top down planning technique means we begin the planning process by knowing the result the customer or boss wants from the project. Part defining the result is spelling out the specific measurable criteria we (and the sponsor) will use to decide if the project succeeded. It can be something simple like, “Employees can get the supplies they need from the supply room in less than two minutes.” What’s important about that kind of definition is that it tells people what they’re going to get from the project.  As importantly, it tells them what they are not going to get. If there are managers who think employees should get their supplies in one minute, we need to clarify their expectations before we start work.

The project result is at the top of the project planning pyramid. We start there and then break it down into smaller pieces until we get to the level of team member assignments that are deliverables. We now have a pyramid with the overall project result at the top and smaller deliverables below. That hierarchy is our work breakdown structure (WBS). It’s the spine of the project. We add flesh to it by assigning people to the deliverables. Then we work with them to estimate the time and effort to produce the deliverables. One important piece is that we define every deliverable with measured acceptance criteria.  That way the boss knows what the project will deliver. And everybody working on the project knows precisely what he or she has to do. Everyone knows this before we start work.

The top down project plan needs to communicate several important things to the team and everyone who’s affected by the project. As we just discussed, we need to define what the project is going to deliver to the organization. Part of that definition is to spell out the specific measurable criteria we (and the sponsor) will use to decide if the project is a success. The measure of success can be something simple like, “Employees can get the supplies they need from the supply room in less than two minutes.” What’s important about that kind of definition is that it tells people what they’re going to get from the project.  As importantly, it tells them what they are not going to get. If there are managers who think employees should get their supplies in one minute, we need to clarify their expectations before we start work.

Second, the top down project plan also needs to communicate what resources we need to produce the planned result. How much time and money do we need? We also need to explain what authority we need to manage the project. We might ask for the authority to assign work directly to the project team members, even if they work in another department. Other items we might address are the risks the project faces and the help we need from management to defend the project from those risks.

Remember, this top down project plan can be short; one page. We project managers get into trouble when we write so much detail that no one reads it. When that happens, we can’t manage our stakeholders’ expectations for what they’re going to get and what they must invest to get it. Small Project Plan Techniques

Project Plan: The Wrong Way

The wrong way to do a project plan is to start by identifying the first task we’re going to do, then the second, then the third and so on. This “to do” list approach is easy and doesn’t need much thinking. But it has some downfalls. When we use this approach, we tend to include a lot of good ideas. But we don’t limit our plan to what we absolutely must do to deliver the result the boss wants. Since we don’t know exactly what the boss wants, we can’t decide how to deliver it. That results in doing many things that aren’t necessary. We also waste a lot of time and resources adding things to the project later on. These are vital things that we discovered too late. The “to do” list approach to project planning is faster but we wind up with projects that take longer and cost more than they should.

Top Down Project Plan: How To Do It

You may have managed projects for years using “seat of your pants” techniques. And you may have had some success.  Long-term success, however, requires you to use project planning best practices. Those are the skills needed to consistently deliver the scope on time and within budget. For small projects at an entry-level, a five-step method is enough. Here are the steps:top down project plan

  1. Planning – focused on a clear scope and a deliverable-oriented project plan and work breakdown structure (WBS). You also plan how you’re are going to do the next four steps.
  2. Scheduling and assigning work – create a schedule with project software so you can stay on top of your project’s progress. Assign work to your team members and give them a crystal-clear understanding of what you expect before they even start work.
  3. Estimating how much work it will take to produce each deliverable. It’s always best if the team member who’s going to do the work takes part in this estimating process. It’s more accurate and you get their commitment.
  4. Tracking progress against the plan and spotting variances – use project management software and status data from your team to spot problems early. This avoids unpleasant surprises late in the project.
  5. Designing corrective action and reporting status – design corrective action when you find problems. Then you clearly report the problems and propose solution options to the project sponsor.

You can learn this top down planning process in our online project management courses. You will be able to use these techniques so your projects finish on time and within budget. You’ll work privately with an expert project manager who is your coach and instructor. You may have as many phone calls and live video conferences as you wish. You begin when you wish and work on it at your pace and as your schedule allows. Take a look at the courses in your specialty.

[button link=”” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=”00000000″]Consulting Projects[/button]

Get free articles and videos like this every week

Dysfunctional Project Team – Video

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com

When you inherit a project from another project manager (whether your successor was fired or somehow managed to escape to another project), you have to watch for the danger signs of a dysfunctional team. There are consistent early warning signs of a problem team.

Dysfunctional Project Team: Warning Signs

Early in your tenure as the new project manager, a stream of people from your project team  may warn you about other team members. The offenses include a laundry list of “sins,” such as: treachery, bad behavior, low productivity, poor quality work and disruptive behavior. These people may say they’re coming to warn you. But what they’re trying to do is stab  fellow team members in the back.
Another kind of behavior can come from the more experienced and senior members of the project team. They may suggest that other team members have already badmouthed you to the company’s senior management.
You need to be careful not to overreact to any of these situations. Most of the information is untrue. And it certainly is not intended to help you.

Dysfunctional Project Team: The PM’s Focus

What you have to focus on is the progress being made on the project’s plan. That includes determining how well each of your team members is doing with their assignment. While you’re reviewing that, you also need to confirm the project scope with senior management. You must “take the temperature” of your key stakeholders to avoid surprises from them. Now you’re ready to tackle your dysfunctional project team.

Watch a project manager in action video about a project manager who inherits a dysfunctional team. See the steps he takes to make them productive and to finish the project on time and within budget. He meets with each team member individually and then with the entire group. He uses a variety of motivational techniques to turn the dysfunctional  group into a productive team. Leading Teams Main Page

How To Manage a Dysfunctional Team - Video

Project Due Dates – How to Screw Up a Project Plan

project plan
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

Watch this video of a common way to screw up a project plan. Is it familiar?

Pretend Project Due Dates

The sponsor plucks a project due date out of the sky. Then the tells the stakeholders they’re accountable for meeting that date. No one believes this pretend due date is realistic. They back into the due dates for their deliverables but they aren’t committed to them.  Watch the managers faces in this video and see how much commitment they have to the dates.  These people know they are going to fail before they even start work.  They’re all trying to figure out  how they will throw something together by the due date. They know they’ll then spend months fixing it.

Project Planning Blunders: Due Dates

Realistic Project Due Dates

The way a project manager and sponsor should set the project due date is by calculating the amount of work that each task requires. An effective technique is to let the team members take part in estimating the number of hours worth of work their task will take. Then you convert the number of work hours into the task’s duration. The duration is also based on each team member’s availability to work on their project task. Main Project Planning Page

When you use that technique to develop your task duration estimates, you gain a significant number benefits. First, the team members have a reasonable amount of commitment to the due date because they participated in setting it. Second, you and sponsor can accurately track progress. You can measure the number of hours worked versus the estimated hours. That gives you an exact idea of the percentage of work completed and the percentage of work remaining. With that information, you can calculate when the work will be done. The third benefit is that the team members are not held accountable for finishing their task by a certain date. They are accountable for finishing within a certain number of hours worth of work.

You can learn the best practices for planning projects with realistic due dates in our project management basics courses. Take a look at the basics course in your specialty.

[button link=”” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=”00000000″]Consulting Projects[/button]

Get free articles and videos like this every week

Project Scope

The Project Scope for larger, complex projects must include the “reach” of the project. “Reach” states how far the project reaches out in defining its overall deliverable. Let’s look at an example of what I mean by Project Scope “Reach.”  Let’s say your boss calls you into their office and talks about a project to fix the supply room. The boss says, “The supplies are a mess and we need to get them straightened out.”

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

Many project managers would just say, “Okay!” and get to work cleaning up the supply room. But a well-trained project manager would ask the sponsor about the acceptance criteria they will use to judge if the project is a success. In answer to the question about acceptance criteria, the boss might say, “I want all the supplies on the shelves in order by UPC (universal product code).”  The project manager might nod their understanding and begin work because the desired result is now clear. Project Phases Main Page

A project manager with even more training will say to the boss, “Just so I understand the big picture, why do you want the supplies on the shelves in the UPC order?”  The boss frowns and says, “So our employees can get the supplies they need faster.” This project manager replies, “Then maybe we ought to reach a little further with the scope and aim at improving the speed of supply retrieval.  The project acceptance criteria might be something like, ‘90% of employees can find their supply in less than 2 minutes.’ If we just put the supplies on the shelves in UPC order, I’m concerned that we might not have an impact on how long it takes employees to find their supplies.”

Project Scope – Not Reaching Far Enough

Problems result when the Project Scope doesn’t reach far enough. The team can meet the smaller scope but have no impact on the larger problem that initiated the project. Asking the boss a polite question about reach, as our project manager did in the example, is always a good technique. It lets you understand more about the real problem the boss is trying to solve. That’s the key to being an outstanding project manager.

Project managers who ask these Project Scope Reach questions do a number of things for themselves and the organization. The sponsor begins to see the project manager as a strategic thinker, not just a supervisor who runs the project team. The sponsor avoids initiating projects that aren’t likely to give any business benefit to the organization, no matter how well the PM manages the effort. The PM gets the opportunity to run projects that deliver more significant benefits to the organization.

A “best practice” for a project manager during the project initiation phase is to first think about the scope the sponsor mentioned. Next, think about scopes with larger reach and more business benefits to the organization. Then if the opportunity arises, the project manager can have that strategic reach discussion with the sponsor.

We often see the organizational impact of projects with a reach that is too small. These are the real project disasters. The organization launches what is the same project every year to solve a problem that prior projects failed to solve. Although there are many contributing factors, executives often plan these projects without consideration of alternatives to the Project Scope Reach.

Some projects do not reach beyond the boundaries of the sub-unit where the team members work. Other projects reach out and measure their success in the customers’ eyes. If the reach of a project is incorrect for the organization’s business situation, top management will not be satisfied with the project and its manager. This is no simple issue. The thinking process is as complex as the factors that you must consider.

Project Scope – Reaching Too Far 

Sometimes the planning process can yield a Project Scope that reaches too far. It brings in too many variables and risks that are beyond the control of the sponsor and project manager. As an example, let’s say the company’s  customers are dissatisfied with their customer service. An executive may talk to you about a project to cut customer telephone hold time. That is one thing about which the customers complain. Defining acceptance criteria for a 5% reduction in hold time is relatively straightforward. You can use data from your phone system to measure if you reached that Project Scope.

However, if you are a savvy project manager thinking about this project, you might wonder if a reduction in hold time is going to solve the customer dissatisfaction problem. You might look at the data and see that customers are also upset about needing to call back repeatedly to resolve the same problem. That is a somewhat larger Project Scope Reach and a potentially more significant problem to solve. You could define a deliverable like, “Less than 1% of customers have to call back about the same problem.” Again, you can use your internal phone system to measure if you delivered that business result.

To reach even further, you might think about an alternative Project Scope of measuring success through the customers’ eyes. A simple measure of the overall customer satisfaction might be “60% of the customers who have called in, rate the service as excellent.” The project to deliver that business result might include both the hold time and the accuracy/completeness of the answers customers receive.

Keep in mind that when you define a Project Scope that reaches to the customer, you add factors over which you have no control. As an example, if other companies that your customers use are also instituting service improvement projects, you may find that your improvements are insufficient when compared to other organizations. There are other sorts of external influences that can affect your ability to produce the deliverables of a Project Scope with a big reach. You need to identify these risks and make a realistic assessment of how much they could affect youProject Scoper ability to deliver the Project Scope the sponsor has set.

Let’s investigate the typical process that organizations use for conceiving projects. Then we’ll explore the Project Scope reach techniques.

Project Scope – Conceiving Projects 

Most organizations have a new “Holy Grail”project every three years or so. Organizations that are more schizophrenic have a new Holy Grail every six months. The Holy Grail might be improving customer service, reducing costs or headcount, gaining market share or launching a particular new product. Perceptive sponsors and project managers know that linking their new project to the current Holy Grail project is the easy path to project approval and lavish funding. Therefore, organizations see many project proposals that talk about how they will contribute to, help or give functionality to the current Holy Grail project.

The organization usually approves dozens of these projects. Executives hope that somehow this mess of uncoordinated projects will deliver the Holy Grail they seek. If the Holy Grail is to improve customer service, projects for new customer service systems, improved training, more/better new hires, enhanced compensation systems and customer-oriented re-structuring emerge from every department. Each project justifies itself by singing about the Holy Grail of customer service. Their Project Scope reach is merely to “install the new customer service system,” “conduct the training,” “make better hiring decisions,” and so on. No one actually practices strategic project planning. That is, they don’t conceive a Project Scope whose goal is to improve customer service.

Project Scope – Strategic Project Planning

None of the project managers or sponsors in the above example justified their project by saying, “Today, 31% of our customers rate our service as outstanding. When we complete our project, 75% of our customers will rate our service as outstanding.” This Project Scope, the measure of success, has a big reach. It is an example of strategic project planning. It spans departmental boundaries and reaches out to define its success through the eyes of the organization’s customers. Projects with a big Project Scope Reach are difficult to manage. They touch on many people’s turf. They require the PM to integrate the efforts of the “geeks” from IT with the “flakes” from Sales and the “drones” from Operations. And most shocking of all, strategic project planning may even require that people talk to their customers to find out what they actually want. What a novel approach!

The other challenges of defining a larger Project Scope Reach are “controlability” and the amount of organizational change you have to manage. First, if you pick a deliverable that is too big, you buy into a host of external variables that may not be within your control. Second, strategic planning of large Project Scope Reach projects usually entails significant degrees of organizational change. That’s a high-risk element. So you have to balance three ideas:

1.) Scope reaches out far enough to deliver a strategically significant result

2.) Don’t include an unacceptable level of uncontrollable factors and

3.) Avoid so much organizational change that there is no chance of success.

It’s much easier to talk in vague terms about “delighting” the customer, providing required functionality, enhancing employee skills and streamlining delivery systems. Everyone agrees that projects with these mushy deliverables will deliver no strategic value. However, since they promised nothing measurable, the organization can’t identify success or failure. Sadly, organizations often don’t measure anything except how the project’s actual duration and budget compared to the plan.

Project Scope – Summary

When organizations and their executives finally tire of funding dozens or hundreds of projects that never deliver strategic results, they begin to seek projects and project managers whose efforts reach into and affect the outside world. However, the question is how do they weed out the weak and identify the strong, highly focused projects?

Organizations must insist that project managers and sponsors engage in the conceptual thinking required for strategic Project Scope planning. That means planning projects based on the end result they will deliver, that is their measure of success. This is much more difficult than merely planning the activities the project will include. When organizations adopt this approach they can clearly define the Project Scope to deliver projects that change performance as measured by the outside world.  The Project Scope reach lets them focus projects on measured results, subdivide these measures of success into clear assignments, and hold the PM and team members accountable for their delivery.

You can learn these techniques in our online courses where you work 1-to-1 with your instructor. We offer courses for people who manage IT, construction, healthcare, general business and consulting projects.

Get free articles and videos like this every week


Project Plan Blunder Too Much Detail

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

By far the most frequent Project Plan Blunder is Too Much Detail. Why does this happen?  Don’t the executives and stakeholders understand that the Project Plan is a strategic level plan? They should focus on the project goals, not on the details. They may understand that, but getting into the details is too powerful for many people to avoid.  Main Project Planning Page

There are other reasons why stakeholders dive into the details when planning a project. Some decision-makers are uncomfortable committing to exactly what they want the project to produce. It’s easier and safer to talk about the details of the wood paneling in the conference rooms or the data fields in a new accounts payable system.  If they specify precisely what they want the project to deliver, aligned with the strategic goals of the organization, they’re committed to that result. And those commitments are hard to back out of.

Project Plan Blunder – Too Much Detail by the Sponsor

The project manager has to prevent the sponsor from committing this Project Plan Blunder by falling into the details. That’s a difficult challenge because the sponsor usually outranks the project manager by multiple levels of rank and authority. Most of the stakeholders do as well. So the best way for the project manager to gain control is to work with the statement of work (SOW) that the sponsor generated.  That document defines the project scope and deliverables as well as the acceptance criteria the sponsor will use to measure the project’s success. It defines the project at a very high level. It encourages project planning that starts from the top-level and moves down through the supporting deliverables. We call this process top-down planning.

Project Plan Blunder – Too Much Detail: the Project Manager Role

The project manager needs to control the planning process. It must start with everyone understanding the scope of the project. The scope is the largest deliverable in the project plan.  Then the project manager must lead the group through breaking down the scope into the major deliverables that support it. They are the achievements that are necessary to get from where the organization/department/system etc. is now to where it must be to deliver what the sponsor wants.

When explaining how planning with high-level deliverables works, I like to use an analogy of crossing a river by jumping from rock to rock. The deliverable that the sponsor wants (the scope) is reaching the river’s far shore. The project manager starts from this end result and works backwards. He/she asks the planning group, “What is the last rock we must stand on before we can jump to the far shore?” “That is the last major deliverable we need to produce in the project.”

Then the project manager backs up and says, “What is the rock we must stand on before we can jump to the last one?” “What rock must we reach before the last one?” The process goes on, moving backwards and identifying each “rock” (high-level deliverable) that must be reached until they are at the starting point. That starting point is where they are now in the project. And each rock is a step  toward the goal.

This is how the project manager keeps the planning group’s thinking at a high level. Focusing on the major rocks (deliverables), prevents them from sinking into the river (details). Those details are more comfortable for many people to talk about. They also let the sponsor avoid defining what the project must deliver and committing to it.

Watch a video of this typical project planning blunder of too much detail.

Project Planning Blunders: Too Much Detail

To learn more about how to plan projects the right way, consider our online project management courses. You work privately with an expert project manager who is your coach and instructor. You may begin when you wish and work on the course at your pace and as your schedule allows. You and your instructor have as many phone calls and live video conferences as you wish. Take a look at the courses in your specialty.

[button link=”” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=”00000000″]Consulting Projects[/button]