Project Scope Management: What Are We Making?
Prevent Project Disaster
This article is an overview of a very large topic, Project Scope Management. In fact, whole books have been written on scope management. This overview can orient your further studies on scope management, which is crucial to project success.
Scope Management is Crucial for Project Success
Most projects fail, and for many reasons. But the truly disastrous project failures are failures of scope management. Scope is the definition of the project's purpose and goal. So, if that is poorly defined, we either get nothing at all (goal not delivered), or we get a result that doesn't do what we want, or we get two parts that don't work together, because half of the project team had one idea, and the other half had another idea. We deliver the front end of a donkey and the rear end of a horse, and end up looking like a horse's rear end.
Prevent Scope Creep
Even if the product and its purpose are well-defined at the beginning, customers have a notorious habit of getting new ideas and expecting more and more. If we ignore them, they will start dreaming, and expect us to fulfill their dreams. When we deliver what we promised - much less than what they dreamed - they will not be satisfied. It doesn't matter if we give them exactly what they asked for. People get upset when they don't get what they expect. Worse, if we do listen to them, we keep adding features that they request. But that takes far longer than the original schedule, and far more money than is in the original budget. As a result, we have nothing to deliver at the end of the project. The customer is out of time and money, and we have nothing useful to show for all of our work. We call this monster scope creep, meaning that, even though we defined scope at the beginning, more and more features, more and more bells and whistles, crept into the scope, adding to the project plan until it collapsed from its own weight.
According to the Project Management Institute, 64% of all projects fail to deliver satisfaction on their original schedule and budget. And the biggest cause of these failures is poor scope definition, or if we got the scope defined well at the beginning, scope creep.
The good news is that if we define scope clearly and manage scope creep, we're on our way to success!
I've trained over 4,000 project managers and led dozens of projects. Let me show you how to define scope and manage scope creep before your project gets overwhelmed!
What's stopping your projects?
Which of these scope management problems has happened to you?
When is Next Tuesday?
Whenever I teach a class on scope definition and clarity of communications, I ask for a show of hands on this question. Say I'm teaching on Thursday. I ask, "Raise your hand if you think next Tuesday is 5 days from now." About half the people in the room raise their hands. Then I ask, "Raise your hand if you think next Tuesday is 12 days from now." The other half of the people in the room raise their hands.
This demonstrates that plain English is not a precise language. For some, "next Tuesday" is the one coming up five days away. For others, "next Tuesday" is after "this Tuesday," so it's twelve days away.
When the students see that, whatever way they think, half the people in the room think differently, they begin to see the value of clear precise, written definitions. Such definitions go a long way to eliminating costly misunderstandings, and also prevent mistakes that disappoint our customers.
Agreeing on the Scope of Your Project
Working with the customer, the team, and all the stakeholders to agree on the deliverable of the project and its function and purpose is not easy. For example, a corporate web site is:
- an expression of the corporate image, according to senior executives
- a source of exposure to legal liability, according to corporate counsel
- a tool for bringing in new revenue, according to the marketing department
- another cost item to maintain, according to finance
- an opportunity to solve some hiring problems and get good prospective employees, according to human resources
- a maintenance job, according to the IT department
- a project to finish, according to the web development team
The key here is that everyone is right. Successful scope management requires being able to understand everyone's perspective, see what they need and what they have to offer, and put it all into one plan and one definition.
Getting on the Same Page
Everyone affected by a project has his or her own perspective, and his or her own language, as well. How does the executive "corporate image" translate into marketing's "effective landing page," and the IT department's "no 404 Page Not Found" messages. Architecture is the ability to see one thing in multiple views, multiple perspectives, and multiple languages. As project managers, we must also be architects, able to see the project from all perspectives and address all concerns.
As we put together the initial definition of the project, the scope statement, we have to make sure that everyone understands the purpose and the goal. They might have different terms for the same thing; that's okay. But if two people have completely different pictures of what is being made, we've got a problem. And we can't be vague about it. We can't declare "We're making a gray mammal," and have the corporate team expect an elephant while the Chief Financial Officer has only agreed to pay for a mouse.
Agreeing on Scope
Once we're on the same page, we work with each stakeholder to define what we are making, and why. We are still operating at a high level here. But we are going back and forth, clarifying, defining, and getting a better and better picture of what we are making.
As we said above, customers are not happy when they don't get what they expect. To ensure we understand and manage their expectations, we cannot leave the project scope statement in vague, plain English terms. It must be defined with engineering precision, and it must also be explained in ordinary language as well. It also helps to use diagrams, and, when possible, develop mock-ups and prototypes so our customers and stakeholders can actually see, or see a picture of, what they will be getting. For the importance of precise language, see the sidebar, When is next Tuesday?
The Steps of Scope Management
The Project Management Institute defines four processes that make up Scope Management:
- Scope Planning is laying out our plan for managing scope on this particular project. If our projects are fairly similar to one another, then this is done once for all projects, and we follow a standard methodology.
- Scope Definition is the process of creating our first statement of what we are making on this project, including its nature, function, and purpose. The resulting Scope Definition Statement is the core concept from which the entire project is planned.
- Work Breakdown Structuring (WBS) is a process of defining all the details of what we are making, creating a complete and precise definition of the project scope.
The PMI offers a fancy name for creating a high level scope definition first and a detailed WBS later. They call it progressive elaboration.
Questions That Define the Rest of the Project
Clear scope definition is essential to planning and defining all other aspects of the project. Proper definition of each of the other eight areas of project management relies on a solid, clear definition of scope. If you are not clear on the nine areas of project management, you might want to read The Nine Areas of Project Management, and Why They Matter.
Inclusions and Exclusions
An excellent tool for defining scope and preventing scope creep is to include both a definition of what we are making, that is a list of inclusions, and also a list of what people have asked for that we are not making, that is, a list of exclusions. There are two reasons for doing this.
First of all, people tend to remember that they are going to get whatever they want, even if you say "no." We can manage this natural human tendency by writing down what we agreed, and showing it to them, and getting them to sign on to it. Then, later in the project, when they remember that they asked for it, and think they will get it, we can show them, sorry, no, it was always excluded from the scope, the agreement of what we are making.
For example, let's say that I'm building a web site for a company in South Florida, where there are three popular languages: English, Spanish, and Haitian Creole. During initial scope definition, we agree that the site will be in English and Spanish, but that translating it into Haitian Creole is not cost-effective at this time. We write down "The web site will not be translated into Haitian Creole this year. If demand from the Creole community increases, this may be affordable next year."
Then, when the site is being tested, a manager comes and says, "but I couldn't read the site in Creole. What happened?" We bring out the scope statement, and show him that Creole was excluded for now.
The second reason is simply for clarity. Defining exclusions increases clarity about what we are doing and gives us a tool for managing scope creep later in the project. For example, suppose one of the purposes of a web site in our scope statement is to "improve customer support." As part of that, someone suggested online chat, but we chose not to do it. If we don't write "online chat" down on the exclusion list, someone may suggest it again later. But if we write it down, then everyone is clear: We're not implementing online chat. That saves a lot of time having the same discussion over and over again.
Creating the Work Breakdown Structure (WBS)
Work Breakdown Structuring begins when the Scope Statement is approved by all stakeholders. It is a process of creating a very careful, detailed, hierarchical list of all the project components.
For example, let's say that we're building an airplane. Our initial description looks like this:
- one fuselage
- one cockpit
- one cabin
- two wings
- one tail assembly
- flight controls
- electronics for navigation and other purposes
Each of those major components becomes a heading for a list of smaller component. A wing includes:
- wing body
- fuel tanks
- fuel lines
Ultimately, this is detailed out to a complete list of parts. For a commercial jet, that can be over 1 million parts!
Creating the Rest of the Project Plan
Once we have a WBS, it is possible to create the rest of the detailed project plan. We can create accurate time and cost estimates. We can complete plans to manage the other six areas of project management as well: quality, risk, human resources, communications, procurement, and integration.
For example, the WBS is a list of what we are making. From that, we ask how we will make each component. That generates the Activity List, which is a key component of time estimation. Also, when we know what we are making, we can ask, "What could go wrong?" and that is the starting point for risk planning. And asking "what makes it good?" is the beginning of quality planning.
Managing Scope During the Project
Once the WBS is approved, we complete the rest of the project plan. Once the entire plan is approved, we launch the work. Now, our job is to complete the project. Or, in project management terms, we are going to deliver the specified scope with acceptable quality on time and within budget, no matter what happens.
Doing this calls for work, which is called execution. But it also calls for tracking that work and correcting course, if necessary. Those are called tracking and control. It's just like driving down the highway. If all you do is drive, you'll miss your exit, and be late. Or you'll go too slow and be late, or you'll speed and get a ticket. To drive well, we have to watch where we are, how fast we're going, whether we're running out of gas, and what other drivers are doing on the road. It's the same on a project. And we accomplish that with Earned Value Analysis, managing scope creep, and managing all nine areas of the project.
Earned Value Analysis
Earned Value Analysis (EVA) begins with tracking scope, time, and cost. In plain English: What have we completed, how much time did it take, and how much money did we spend? Once we have those figures, we put them through some equations. The equations are proportional: They ask how much scope we've completed in relation to time spent and money spent. Those results answer the question: If we keep going at this rate, will we finish before we run out of time and money? If so, all good. If not, then we've got to figure out why we're running slow, or spending too much money, and take care of the problem.
Managing Scope Creep
Earned value analysis measures progress on our committed goal, the specified scope. But what if the customer gets a great idea, and wants it added to the project? What if an engineer thinks of a better feature, and he wants it added? What if some senior executive quits, and is replaced by a new boss, and she wants something totally different?
These problems come up all the time. As I said above, scope creep arises from human nature. What we must do is be aware of it and address any proposed changes to the project before they become assumptions, features, or demands.
In short, don't let anyone move the goal posts. If someone wants to change the scope, we calculate the cost of project change and the extra time it will take. Then we negotiate: We prefer no changes, but we will make a change to the scope if the project receives an extension of the deadline and extra funds, so that we can deliver the new, increased scope, which is more than was specified, and therefore more than was budgeted or put on the schedule.
In plain English: If you want more stuff, it's gonna take longer and cost more money. That's called the Iron Triangle of Scope, Time, and Cost.
Managing All Nine Areas
There is one more thing we can do to ensure that we deliver project results and delight the customer. Note what I said above, deliver results "with acceptable quality . . . no matter what happens." This points out the fact that we must manage more than scope, time, and cost. It is essential to manage all nine areas of project management throughout the project, from beginning to end. Project Quality Management ensures acceptable - or excellent - results. Project Risk Management ensures success no matter what happens. For an explanation of all nine areas, and why they matter, please read The Nine Areas of Project Management and Why They Matter.
Delivering What You Promised
If we keep working on the project to build the product, service, or result we defined in the scope statement, then one day - a day before the money and time run out, I hope - we are ready to deliver.
Or, we think we're ready to deliver. But are we really sure? And what does the customer think. Let's take a look at the steps we follow to make sure we deliver the right thing to the customer, and finish up well.
Verification and Validation
Verification is a process internal to the project, where we check what we've created against the scope statement, the WBS, and other relevant documents. We ensure, as best we can, that what we have done meets or exceeds all customer requirements. And, if we did approve a change of scope to the project, we include those changes in our deliverable, as well. To put it simply, we're comparing what we are going to deliver to the plan, and making sure it's all good to go. It is important that this is not only a thing we are delivering. Whatever we deliver has to work for the customer, that is, it has to meet functional requirements, as well as physical ones. So, before we deliver, we want to be able to say, "Here it is, and it works!"
But will the customer agree? That question is answered by the Validation process. We can't do validation ourselves. It is usually done by the customer, as they check out and sign off on delivery of the project results. But there are two other possibilities:
- If we are delivering something large, or complicated, or something that needs to meet demanding requirements, we will probably want to arrange for validation well before the delivery date. This gives the project team time to adjust or fix anything that doesn't meet customer requirements.
- If there is a dispute about whether our project is delivering the results the customer signed up for, they can request an Independent Verification & Validation (IV&V), where an outside contractor comes in to define the gaps between what we are delivering and what the customer wants, and recommend solutions.
Normally, though, no IV&V is needed. We deliver project results, which may include installation, setup, and training, depending on whether those were included in the project scope statement. The customer kicks the tires, so to speak, and is either satisfied or requests a few small changes, which we make. And then the project is complete - almost.
Our last steps include making sure everyone gets paid and signing off on contracts and such, It should also include a meeting purely for customer service, to ensure that they are delighted with our work. The end of a project can be the beginning of a long, healthy relationship with a customer.