The Project Scope Statement is defined by the project sponsor. The project manager must ask the right questions to get the sponsor to clearly state the end result they want the project to deliver. It must be stated in measurable terms as acceptance criteria. Those criteria are the real definition of what the sponsor wants and how they will measure if the project is a success. Project Scope
Executives who are not used to project managers asking questions may resent it. But a successful project manager responds to the sponsor’s objections with a reasonable statement like, “I can’t deliver the business end result you want if I don’t know precisely what it is.”
Executives may not like that push back. But it is worth a bit of early executive dissatisfaction because it helps you define a measured business result for the project scope rather than a list of ever-changing requirements.
Project Scope Statement: The Sponsor’s Role
Another reason why the Project Scope Statement definition is not easy to get is because too many sponsors don’t know how to properly play their role in the project. During project planning, the sponsor’s role is to define the project in a statement of work (SOW), prove its value to the organization in a business case and define the scope statement. After they have completed those requirements, the sponsor’s role and their level of involvement declines. Then it consists of approving plans and any changes to those plans as well as accepting or rejecting project deliverables. Project Phases Main Page
In too many organizations, the project sponsor role is poorly played. Instead of defining the Project Scope Statement that will drive the project to a successful end, many sponsors do destructive things. Some play cat and mouse games with the project manager, refusing to commit to exactly what they want. They may do this because they don’t actually know what business result they want the project to deliver. So they are unable to define the scope. Or they are vague because they want to be able to avoid blame if the project fails. They can say, “That’s not what I wanted the project to deliver.”
Either way, this behavior dooms the project to failure. It drifts from one goal to another while the project manager and team members try to figure out what the sponsor really wants. They often find out a month before the due date (which the sponsor has arbitrarily set). That sets off the “end of project panic” which is also caused by sponsors who don’t know their proper role. The PM and team frantically try to produce something close to what the sponsor now says he/she wants. It’s not a surprise that what the team produces has no value. So they will spend the next six months trying to fix it. Bad sponsors leave a trail of these project failures in their wake. That’s how you can spot them… and, hopefully, avoid managing their projects. Project Scope
You can learn these techniques for defining the project scope statement in our customized, online courses. You work individually with your instructor and have as many phone calls and video conferences as you need. The Project Management Basics course, #101, teaches you a step-by-step process and how to use MS Project® software to make your job easier.
At the beginning, when you and Dick talk to design your program and what you want to learn, you will select case studies that fit the kind of projects you want to manage. Chose you course and then select the which specialty case study from business, or marketing, or construction, or healthcare, or consulting. That way your case studies and project plans, schedules and presentations will fit your desired specialty.
You can produce an excellent project plan that can fit on one side of one piece of paper and take less than an hour to create. It will be suitable for 90% of the projects that most organization do. The key to making this work is for you and the project sponsor to play your roles properly. The project sponsor (that’s the boss, executive or customer who wants the project done) has to define the business result that the project must produce. That business result is the scope of the project and it has to be a metric. The scope must have acceptance criteria that define success in objective, measurable terms. If the sponsor prefers to “plan as we go,” and “stay flexible so we can adjust,” they are not fulfilling their role on the project. It would be foolish to start work on the project without knowing where you need to be at the end. Main Project Planning Page
Your role as the project manager is to get the sponsor to tell you the acceptance criteria-type of scope definition. Then you and the sponsor break the scope down into the major deliverables the project has to produce. These deliverables the stepping stones for how the project will move from where it is now to the end result the sponsor defined. You are not doing your job if you start work before you have a clearly defined scope with major deliverables. Let’s look at the steps you need to follow.
Project Plan Step 1 – Defining the Scope
Defining the scope involves gaining agreement on the metric that the sponsor (the boss, executive or customer) will use to measure the end result of the project. Sponsor who have a successful track record for initiating projects know that you (the project manager) need a clear definition of the project scope that includes a success metric. If the sponsor doesn’t know how to play his or her role, anonymously send them a link to this article. You don’t want your project to fail because the sponsor has a failing record on their projects.
Once you have that success metric, you can create the project plans and schedules rather easily. The difficulty comes when people try to skip this first step or when the sponsor doesn’t know how (or is unwilling) to define the project’s success. Without that scope metric, the rest of the project pieces are useless. Here’s an example of a small project to illustrate how this is done.
A project manager gets a phone call from a project sponsor who says, “I’d like you to run a project for me to deal with our problems getting office supplies out of the warehouse.”
The project manager goes to the sponsor’s office and during the discussion, asks open-ended questions aimed at defining the scope. It’s very possible that the sponsor has started the conversation about the project without having a clear picture of the end result they want. The project manager has to ask questions which help the sponsor define the project’s end result. The project manager asks how performance of the warehouse will be different after the project is complete. The sponsor says, “We can’t run out of supplies so often; we have to reduce the number of these stock-outs. And it shouldn’t take people as long to find what they need.” The project manager should follow up with questions like, “How often do we run out of supplies now? What’s an acceptable number of stock-outs each month?” The project manager might also ask, “How long does it currently take to find supply items and how long should it take?”
That’s a good example of the project manager asking polite and respectful questions in an attempt to get the sponsor to be specific about the project’s scope. Let’s say the sponsor says people should be able to find the supply they want in less than 120 seconds 90% of the time. That is a crystal clear metric or acceptance criteria for the project scope.
Project Plan Step 2 – Breaking Down the Scope into Major Deliverables
With the scope defined as a metric which the warehouse project must produce, the project manager will work with the sponsor to break that scope into 4 to 7 major, high-level deliverables. They will lead from where the warehouse performance is now to the end result the sponsor wants. The PM may talk to people in the warehouse to find out why it to take so long for people to find the supplies they need. The PM may also ask the warehouse staff for their ideas about how to reduce the time needed to get a supply. The project manager may come back to the sponsor with some suggestions based on this fact-finding process. They may suggest the following high-level deliverables:
1. Increase the lighting in the warehouse to an average of 65 lumens
2. Track the location of all supply items with 95% accuracy on a commercial PC inventory system. The system cost should not exceed $500.
3. Discard any supply items in the inventory that have not been used in the last four years.
4. Redesign the inventory layout so the most frequently utilized supplies can be retrieved in less than 30 seconds.
5. Distribute new procedures for using the supply warehouse to all employees.
Each of those high-level deliverables has an acceptance criteria that can be objectively measured. The project manager reviews the deliverables with the project sponsor. The sponsor may change or adjust any of the deliverable’s metrics to fit his/her assessment of the situation. When the sponsor signs off on the scope and the high-level deliverables that will lead to it, the project manager has a strong start on the project plan and can move on to the planning details. The key point here is that the sponsor and project manager worked top-down; starting from the end result down to the contributing deliverables that will help them get there.
Project Plan Step 3 – Breaking Down the Major Deliverables
The next step is for the project manager to continue to break down those major deliverables into smaller deliverables. The lowest level of deliverables should be suitable for assigning to an individual. These assignments should also be measured deliverables so the team members know what is expected of them (what they must produce) before they start work. These deliverables will become tasks in the work breakdown structure (WBS). They are also the basis for estimating the amount of work, cost and duration of each deliverable.
Project Plan Step 4 – Estimating
Once this breakdown into smaller deliverables is complete, the project manager has an assignment for each team member. The next step is to meet with the people accountable for producing each of those deliverables. Each of the tasks (the lowest level deliverables in the work breakdown structure) will have an estimate of the amount of work and the duration. The project manager engages the team members in this estimation process. Involving each team member in this part of the process produces more accurate estimates. The team members also become more committed to producing their deliverables in the estimated amount of time. The PM will enter this data into project management software to create the schedule and budget. Using project management software saves project managers a great deal of time. Software options include Microsoft Project and several low cost or free scheduling applications that are available on the web. Any of those are suitable, especially for a small project.The project manager will track each task’s actual work and duration against the plan.
Project Plan Step 5 – Final Approval By the Sponsor
The last step in developing the project plan is to secure the sponsor’s final approval on the project scope, major deliverables, budget and the planned duration of the work. With that approval, the project plan is finished and the project manager can begin work.
At the beginning of your course, when you and Dick talk to design your program and what you want to learn, you will select case studies that fit the kind of projects you want to manage. Chose you course and then select the which specialty case study from business, or marketing, or construction, or healthcare, or consulting. That way your case studies and project plans, schedules and presentations will fit your desired specialty.
First we’ll talk about what Scope Creep is and then we’ll talk about how to avoid it. Scope creep is the addition of new features and functions after the original project plan has been approved. These additions to the project scope are approved without any compensating adjustment to the project budget or schedule. It is the number one cause of project failure. Some organizations are plagued by scope creep on every project because their project managers don’t do a good job of defining the scope or engaging the project sponsor in scope control. These actions should be done early in the project. If not, the projects (and project managers) have a limited opportunity for success. Trying to fight every change to a project doesn’t work either. Even if the stakeholder or customer doesn’t “ram the change down your throat,” they are still unhappy with the project and the project manager. Project Scope Creep Main Page
How To Avoid Scope Creep: Planning Is The First Line of Defense
The battle against scope creep starts during project planning. You and the project sponsor need to lay a foundation where you can fend off additions to the project that are not necessary to achieve its scope. Every good idea that is proposed by a stakeholder or one of your team members must first be tested to see if it’s necessary to achieve the project scope. That means that the scope of the project needs to be defined in unambiguous measurable terms. We need a scope statement like, “less than 5% of the customers spend more than 20 seconds on hold.” Then when someone proposes a good idea, you politely say, “Please tell me why we need to include that task to achieve our goal of ‘less than 5% of the customer spend more than 20 seconds on hold.’ It seems to me the tasks we have planned will get us to that end result.”
With a measurable scope and deliverables, you have a better ability to fend off scope creep additions to the project without making the stakeholders angry. So you must spend a great deal of time defining the scope in measurable terms rather than falling prey to the “start work fast” mandate. That often prevents the development of a clear scope definition. And without that clear definition, you may start fast but you’ll finish late because of all the scope creep that is loaded onto the project. The deliverables in the project must also be defined in measurable terms. They form the first line of defense against scope creep. You need to convince your sponsor that it’s worth spending time to define the deliverables because they help you avoid scope creep.
How To Avoid Scope Creep: Trade-offs Are The Second Line of Defense
Rather than trying to fight every change, you will be more successful handling scope creep when you are able to quantify trade-offs every time a stakeholder asks for a change in the project. You shouldn’t tell them you can’t do something they want. Instead you should say, “Of course we can make that change. Let’s talk about what it will cost and how much it will change the duration of the project. We can also discuss how much it will change the resources we need on the project team.” Then you calculate the numbers that clearly communicate the impact of the requested change on the project.
Remember there is no such thing as a free lunch. Every change has an impact on the project cost, schedule, quality, risks or resource requirements. After reviewing your estimated impact numbers, the stakeholder making the request may decide not to pursue it. Or you may follow the organization’s change management protocol and send the data to the project sponsor to make a decision. Either way, you are better able to manage the stakeholders than if you try to fight all changes. You also need to be disciplined in maintaining the stakeholders’ expectation that any change to the project will increase the schedule and duration. Here’s an example. A stakeholder says to you, “I’ve got a tiny little change I want to make to the curriculum for the service representatives’ training class. This is so small I hate to bother you with it. I want to add about four hours to the class and give them information on the best way to deal with people who are having marital problems. With the skyrocketing divorce rate, I’m sure a lot of our customers fall into that category. This change is really nothing; maybe a few minutes of preparation for the trainer and a couple of hours of additional class time. Can you just add that for me?”
The short answer is no, you can’t just add that. It’s not that this scope change is so terribly damaging. Rather, it’s the expectation it creates in the stakeholder’s mind. If you “just squeeze in this one,” next week you’ll get a change request that is just a little bit larger and hurts the schedule and budget a little bit more. You must begin to control the stakeholders’ expectations for making changes during the presentation of the project plan. And you must continue that control every week until the project is complete. There is never a free change to the project you can “just squeeze in.”
You can learn these skills in our basic and advanced project management courses. Take a look at the courses in your specialty.
At the beginning, when you and Dick talk to design your program and what you want to learn, you will select case studies that fit the kind of projects you want to manage. Chose you course and then select the which specialty case study from business, or marketing, or construction, or healthcare, or consulting. That way your case studies and project plans, schedules and presentations will fit your desired specialty.
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.”
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 your 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.
What is scope creep? It is a parasite which, if the project manager and sponsor let it flourish, busts budgets and overruns schedules. It doesn’t attack the project once, it attacks dozens or hundreds of times. In each of these attacks, a good idea is added to the project that increases the amount of work to be done as well as the deliverables that must be produced. However, the approved schedule and budget are not increased to accommodate these additions. Every individual scope creep attack seems innocent but it is not. Scope Control
What is Scope Creep?: A Good Idea to Add to the Project
Let’s look at a common situation. A project stakeholder says, “Hey there, project manager. I think it would be a good idea if we added foreign language training to the class we’re going to give our customer service reps. I was thinking Laotian and Vietnamese; a lot of customers speak those languages.”
Now the project manager can go one of two ways. First, she might say, “Well that is a good idea. But it’s not in the budget and the customer service reps don’t need those language skills to hit our project’s scope. I’ll write up an analysis of the additional cost of that language training and how much it will delay our completion date. I’ll be happy to go over it with you before we go talk to the project sponsor. But to be honest, I’m going to recommend that the sponsor not approve that addition. The schedule and budget are very tight so there’s just no room.”
That approach often works and the stakeholder says, “Okay forget about it”
What is Scope Creep When There’s No Crystal-Clear Scope?
The project manager is stuck if there is not a good scope definition. She says, “No we can’t make any changes to the project at this point. It’s just too late. It’s a good idea but I’m sorry.”
The stakeholder says, “Oh I’m sure you can squeeze it in. You’ve got all these people working on the project.”
The project manager replies, “I’m sorry but I can’t. The schedule is just too tight.”
The stakeholder scoffs at the project manager and says, “All right, I’ll just go see your boss. He obviously has a better perspective on things than you do.”
If the project sponsor reacts in the customary way, he will tell the project manager, “Oh come on, you’ve got plenty of slack in the schedule. Go ahead and add it. We need to keep the stakeholders happy.”
How Does Scope Creep Begin?
The project manager adds the foreign language training to the project but, most importantly, doesn’t receive any approval for finishing later than planned or spending more budget than originally approved. Without some support from the project sponsor, it’s unlikely that the project manager will continue to battle with the stakeholders over the “good ideas” they want to add to the project. Eventually, it’s just easier to add them even though the project manager knows they will make the project finish late and over budget. On some projects there are scope changes every week, or even several times a week.
But the project stakeholders are not the only source of scope creep. The project team may add their own “good ideas” to their tasks without the project manager knowing about it. If a more elegant technical solution occurs to the system developers doing a task, they may just add the new features. This source of scope creep can be even more costly than the additional tasks stakeholders want to add. If the project manager has not done a good job of clearly defining the deliverables the team members have to produce, the door to team members’ scope creep is wide open. Once team members and stakeholders understand that they can add to the scope of the project or their task, the volume of scope creep increases. Some project managers think if they approve just the first couple of requests scope creep will go away. Feeding a shark doesn’t make it go away either.
Reporting Scope Creep Variances to Schedule and Budget
The project manager’s next, and possibly last, opportunity to stop scope creep is in the status reports. The project manager gets up and says, “I am forecasting a three-week delay on the project completion date and a $22,000 overrun on the budget as a result of scope changes that have been approved over the last couple of weeks.”
This strategy of reporting schedule and budget variances brings the scope creep into the light of day. It may possibly get the attention of senior management and other stakeholders. On the other hand, it may make the project sponsor very angry because he knows he approved those changes. In that situation, it’s not unusual for the project sponsor to demand that any mention of approved changes be removed from the status reports. That’s a serious ethical issue for the organization. Reporting the schedule and budget impacts of scope creep publicly and quantifying the impact of these approved scope changes may be the only way to tamp down scope creep.
One of the ways that people try to end scope creep is by saying things like, “There will be no changes to this project plan or schedule.” Dramatic statements like that never work. The additions to the project scope will start immediately after those words are spoken (and often by the executive or sponsor who said them). What that person meant was that no one besides them could make any changes to the project scope.
Trying to prohibit all changes to the project is fruitless and actually has very adverse consequences. Changes will be made to every project. The challenge is to avoid scope creep which adds things to the project without any additional budget or duration.
You learn all of those skills in our project management basics courses. Take a look at the basics course in your specialty.
The project due date trap occurs when the boss will only talk about the project’s due date. They want a commitment to that date without defining what they want the project to deliver.
This project due date trap is deadly for a project manager. What draws you into this trap is fear of the boss’ anger. You are certain that your career will be over if you don’t commit to their due date. So you don’t even ask some reasonable questions. Project Planning Main Page
Experienced project managers have learned how to deal with the executives who set the project due date trap. They have learned that a project manager won’t be fired for refusing to commit to a due date. But a project manager could be fired for failing to hit a due date or budget they have committed to meet The first step is getting the sponsor to clearly define the project scope. The scope includes the major deliverables the project must produce and their acceptance criteria. Without that information, the project manager cannot estimate a realistic due date and commit to it. So the project is doomed.
Project Planning Blunders - Plucking Due Dates Out of the Sky
Project Due Date Don’ts
The wrong way to do project planning is to start by identifying the first task you’re going to do on the project, then the second, then the third and so on. This “to do” list approach is easy because it doesn’t require much thinking. But it has major downfalls. Project managers who use this approach tend to include a lot of good, but unnecessary, requirements. They don’t limit the plan to include only what they must do to deliver the result the boss wants. So they waste lots of time and resources. And since they don’t know exactly what the boss wants, they can’t decide what to do to deliver it. They end up adding things to the project later on that they suddenly discover are vital. This “to do” list approach to project planning gets off to a fast start but ends up with projects that take longer and cost more than they should.
Project Best Practices
Long-term success requires that you learn project management best practices. Those are the skills you need to deliver the project scope on time and within budget. For small projects, a five-step methodology is enough. Here are the steps:
Project planning – focus on a clear scope and a deliverable-oriented project plan. Create the work breakdown structure by working from the scope statement down to individual team member assignments. Clearly define the deliverables that are required to reach the project’s end result.
Assigning work to the project team – focus on giving them a crystal-clear understanding of what you expect them to produce before they start work. The deliverables must be measurable.
Estimating – focus on how much work it will take to produce each deliverable. It’s always best to have the team member who is going to do the work take part in this estimating process.
Tracking progress against the plan and spotting variances – use project management software and status data from your team members to stay on top of your project. Anticipate problems when they are small and before they impact the entire project.
Designing corrective action and reporting status – design corrective action when you find problems. Clearly report problems and solution options to the project sponsor for their approval.
Learning a simple methodology like this will help you be successful on the vast majority of projects most organizations do.
When project managers handle project change control badly, it irritates stakeholders and cause overruns on budget and duration. Fighting all changes doesn’t work and neither does accepting all of them. We’ll discuss the mistakes project managers make on change orders. Then we’ll review a methodology for doing it the right way.
On many projects, the project manager faces a never-ending stream of additions and changes. These begin five minutes after the sponsor approves the project plan and continue until five minutes before they accept the last deliverable. Watch this video of a typical change control process.
Walking out to the company parking lot, you ran into the executive who was the sponsor on your current project. The sponsor said, “The project is really coming along well but I do need to add a couple of things.” They handed you a page from a yellow notepad with 35 items on it. You knew it was time to exercise project change control. But the sponsor continued, “These items are really vital to what we’re trying to achieve on our project.” How to Manage Change Order Requests
You looked down at the paper and replied “We couldn’t possibly make any additions at this point. The due date and budget are in danger now. If we keep adding things we’ll be way over.”
The sponsor said, “But these are critical! Without these additions, this whole project will certainly fail.”
You responded, “I think the project will contribute a great deal even without these items.”
The sponsor disagreed, “These were really part of the original requirements. You must have missed them.”
You replied, “I’m sorry but these items were definitely not on the original list of requirements you signed.”
The sponsor grew re-faced and retorted, ”These were part of the business plan for customer service. I don’t care what was on that long list of technical mumbo jumbo you designed. It was just geek talk that none of us understood!” Scope Change Video
You looked back down at the list and tried to calm the sponsor by saying, “Anyway, these seem to have limited business value.”
The sponsor barked, “I’m the one running this operation and I know what’s necessary. And the items on the list are essential if we’re going to maintain competitive levels of customer satisfaction.”
You took a deep breath, “We will be late if we add anything.”
The sponsor took a breath, smiled and said, “These items really won’t take much work. So they should only hurt the schedule or the budget a little. I know you can squeeze them in.”
You frowned, “That is not the case. We will have overruns. They won’t be my fault because these items were never in the approved requirements.”
The sponsor snapped, “If you won’t add these items to the project schedule, I’m going to bump this problem up the line to the VP.”
Project Change Control with Several Endings…All Bad
1. In the first ending, you said, “OK your satisfaction is my goal. We will figure out a way to squeeze these in and not finish too late. But these must be the last changes we make or we’ll have a disaster! “
The sponsor gave his solemn promise, “Absolutely! These are the last changes.” (If you’re naive enough to believe that, you can forget about project change control.)
The next week the yellow sheet of paper had 47 additions, the project finished 3 months late and you took the blame.
2. In the second ending you refused to add the additional requirements. Five hours later your boss called and angrily said, “The senior VP just chewed me out about my project managers not being responsive to our management team. Why are you stirring up trouble with your sponsor? We need his support!”
You started to explain about the changes to scope and the boss interrupted saying, “Add the damn changes…just get these people off my back.” You started to agree just as the boss slammed the phone in your ear.
The next week the yellow sheet of paper had 47 additions, the project finished 3 months late and you were blamed.
3. In the third ending, the boss listened as you said, “I’m trying to be customer-oriented but those changes could set us back a couple of months and cost lots of money.”
The boss said, “Give me a memo on exactly how much later and how much more it will cost so I can show the vice president.”
You thought for a long moment and said, “Well, it’ll take quite a bit of time to put that together.”
The boss grunted in exasperation and said, “I need something to show the vice president today. So you’d better just add the changes they want and have everybody work harder. Use your leadership skills.”
The next week the yellow sheet of paper had 47 additions, the project finished 3 months late and you were blamed for not exercising project change control.
Why Does Bad Project Change Control Happen Over and Over Again?
It happens because project managers lack the tools to exercise project change control. One key to project change control success is project planning that develops quantifiable acceptance criteria for the project scope and each major deliverable. These are not technical specs but measured business outcomes in the customer/user ’s organization. Those acceptance criteria with metrics are the foundation of project change control. That kind of scope definition lets you win the argument about whether changes are necessary for project success. That type of scope metric makes the argument about what was and what was not included go away. Everybody knows what was originally included. Then you aren’t arguing the merits of a change or whether it’s a good or bad idea (you will always lose those). Instead, you are discussing whether or not you can achieve the scope without including the change.
The second key to successful scope and project change control is using a software tool that allows you to quickly quantify the impact of a change. You can use the software to quickly estimate, and then model, exactly what effect a change will have on the project’s cost and duration. With this modeling capability, the conversation with your customer/user is quite different. Let’s see how it goes using both these tools for project change control.
Project Change Control the Right Way
The customer stepped into the your cubicle and said, “The project is really coming along well but I need to add a couple of things.” They handed you a page from a yellow notepad with 35 items on it and then continued, “These items are really vital to what we’re trying to achieve on our project.”
You looked down at the paper and said, “These are great ideas. OK, let’s quantify the added work and the added time.” The customer’s first item was additional training for customer service reps so they could discuss three new products with customers. You said, “We would have to change the training achievement from “Customer reps can answer questions about 37 products accurately 90% of the time,” to ’40 products.’ I’ll ask the trainer to give me an estimate of the hours required for the change.” You called the trainer who gave you a rough estimate of 12 additional hours of prep time on the new products and 15 additional hours of class time.
While you were writing, the customer said, “It should only take a few more minutes. Anyway, I thought these new products were in the original specs.”
You pulled out the plan for the deliverables and said, “No, here is the trainer’s work package we used for the estimate. It has 37 products.”
The customer agreed the new product training was not covered in the original project scope and plan.
You commented, “If you want to eliminate three of the original products, it would be a wash.”
The customer responded, “No, we need all 40.”
You said, “The trainer says that will add 27 hours of their time and the class itself will be longer for the attendees. You opened the project schedule on your PC and entered the additional hours. Then you leaned back and said, “As you can see, these changes would add 7 days to the project duration and would increase our costs by more than $16,000.”
The customer was surprised at the cost and said, “But these are necessary. They are good and worthwhile additions.”
You smiled and said, “I’m sure they are very good ideas or you wouldn’t have brought them to me. But our question has to be; can we hit our project’s measured achievement of, “Customer reps can answer questions about 37 products accurately 90% of the time” without them? They clearly expand the project scope and I will need to add extra time and money to accomplish what you want. That’s how project change control works.”
The customer said, “Well, I want you to include these items in the project or I will escalate the problem to the senior VP.”
You smiled again and said, “That’s appropriate because in our project change control process, it is the senior VP’s role to approve changes of this size. We have the data now so let’s go speak to the VP. We’ll ask if she is willing to expand the scope and add the cost and duration of your change. But I’ll be honest with you. I don’t think we need any of these changes to hit the original scope we committed to for this project. It’s nothing personal. I’m just trying to exercise project change control.”
A Consistent Project Change Control Methodology
You need the right tools to do project change control correctly and that means a consistent methodology. The methodology begins with the initial planning of the project and gives the you tools and processes to identify the measured business achievements the customer/user wants the project to produce. This is not just the technical specifications. The project change control methodology guides you step-by-step through the development of a dynamic schedule and budget. Those tools allow you to quickly calculate the impact of a change order so you can exercise project change control. This methodology is also used in status reporting. You do the same modeling to calculate the impact of the corrective actions that are needed to solve variances.
You can learn a methodology to effectively manage project change control in our Project Management Basics course. It is private online training where you have as many video conferences and phone calls with your instructor as you need.
We all know how projects should be initiated. After a thorough planning process in which the crystal clear scope is laid out and everyone agrees on a sound plan, all team members go to work and “just” execute the plan. So much for the theory. Enterprise Project Management Main Page
In reality, however, project failure rates are high. Projects often do not get initiated the right way and you must launch a recovery of a failing project. Perhaps someone else did the planning and you are assigned to take over the execution phase. Or someone else didn’t get the project done right and you have been asked to fix it. In any case, I hope that this post will get you on your way to successfully manage whatever someone throws at you. Project Failure
The first and most important task for you in taking over an already planned or already running project is to understand the project’s scope. If you don’t know where the ship should go, you won’t be able to steer it. This is especially important when you are asked to take over a project. You must understand the scope and if you can’t find a solid scope statement, remember that it is never to late to compile one. If you don’t understand the scope, chances are you are not alone. Without a solid scope, you will have a hard time finishing what someone else started. I found it most useful to actually draw a picture that shows what is and what is not in the scope. Make sure that at least you and the sponsor are crystal clear about what you have to deliver. Project Rescue
Second, try to find the project charter and the stakeholder register. The project charter should tell you why you do what you do and what your boundaries are as a project manager. This is very important because you will have to maneuver your project around many obstacles and it is always good to know what the boundaries are. The stakeholder register is important because it lets you get in touch with the people who are most important to the project.
Third, introduce yourself to the major stakeholders and the project team. Make sure they have the same understanding of the project scope that you have. Get the project team together and for an update on the current status. This is also a good time to go over the project plan with the team. You might wonder why you should go over the project plan so late in the game. Well if you know the scope, it will be easier for you to spot weaknesses in the plan, especially if you go over the plan with the team.
Last but not least, if you identify a major weakness, you should address it. You don’t have to re-invent the wheel, but you should point out what want to do differently. Project Catastrophes
So here is the bottom line: don’t be shy to take up the challenge of rescuing a failing project. However, I urge you to start with the scope. Your job as the project manager is to keep the big picture in mind. If you have to take over a project to turn it around, you will find that most often the project failed because of scope creep or other scope related issues. Tackle the scope first, all other things will fall into place.