What could be more basic to the practice of project management than an understanding of scope? Scope determines the project’s boundaries: what’s in, what’s out. Everyone seems to understand that a scope change will usually affect both cost and schedule.
When a project fails in whole or in part, poorly defined or poorly understood scope is almost always identified as a key contributor. But while everyone seems to agree on the importance of scope, there is substantially less agreement on what it is and still less on where to find it.
What is scope?
In searching both the web and the printed project management literature, I found three schools of thought:
School #1 says that scope is defined by the description of the product-of-the-project. Most of the advocates for this position seemed to represent project roles involved with deciding what these specifications should be, e.g., business owners, project sponsors, architects, and designers.
School #2 maintains that scope is defined by the work breakdown structure (WBS). Most of those in favor of this perspective seemed to be involved with actually creating the product-of-the-project, e.g., construction contractors, system implementers, and the like.
School #3, probably founded by a middle child, thinks that scope includes both the specifications and the work. Most of these folks seemed to come from disciplines such as Information Technology (IT) and New Product Development (NDP) where specification and delivery are done within the same organization.
I take a slightly different approach. I do not use scope without a modifier. I distinguish between product-scope and work-scope (both always with a hyphen). Let's start with product-scope which I define as “the characteristics of the product-of-the-project.” The product-of-the-project may be tangible (an airplane), intangible (a new organization structure), or semi-tangible (a software application). The characteristics may be visible to the customer (the tile on the floor of the kitchen) or hidden (the database engine that supports a recordkeeping system).
And where is product-scope documented?
The answer here is non-intuitive: you will find your product-scope in different documents based on where you are in your project lifecycle (PLC).
Let’s take a look at a simple example. Over dinner one evening, your significant other comments that the décor in the living room is looking somewhat tatty. Thus begins a discovery process targeted at understanding the problem. Was this an innocent comment that can safely be ignored? Or was it the opening salvo in a campaign to purchase a new residence? After a few careful questions, you determine that the problem is the wallpaper. The faded floral pattern hung by the previous residents is having a negative impact on your partner’s quality of life.
So you now know that you have a project, but the product-scope is as yet unknown: you need more information. What width and pattern of paper will be used? Will you need to line the walls first? Is this actually a redecorating project that will include the purchase of new furniture, repainted woodwork, and a new ceiling? Or is it a simple wallpapering project?
In asking these questions, you are trying to discover more about the characteristics of the product-of-the-project: you are trying to discover your product-scope. You will sit down with your client (in this case, your significant other), document the answers to your questions, and the documented answers will provide an initial, high-level definition of product-scope. You might call this document a conceptual design, preliminary requirements, a feasibility study, or even research results. But whatever term is used, the first step of every project will always be about trying to discover and document the product-scope for that project.
Actually, there is one exception to this rule. Sometimes a project is really a subproject that involves one or more phases of someone else’s project. For example, a “construction project” is really the construction phase of a facility development project. With most subprojects, the project team will be given a description of the product-scope that was developed as part of the parent project.
Discover, design, deliver
As you move through your PLC, you will eventually transition from discovering to designing the product-scope, and then to delivering the product-scope. For your wallpapering project, both design and delivery are reasonably straightforward, so you should be able to make do with just one phase for each:
Design phase. Here, you will define the product-scope in more detail by specifying what pattern wallpaper to use, what color paint for the woodwork, and so on. You will have a new definition of product-scope contained in a “detail design” document that replaces the earlier definition of product-scope.
Delivery phase. This would be your only delivery phase as the paper gets hung and the woodwork gets painted. Your final delivered product-scope (the characteristics of the redecorated room) should match the contents of your detail design as modified to reflect any changes approved by your client.
If you plan to wallpaper a great number of rooms, you may want to provide some consistency in how you go about each project by formalizing your PLC. You might have separate phases within the discovery process for feasibility and requirements. You might specify that the decision about using pre-pasted or plain paper should be part of discovery, or you might leave that until a later design phase in order to provide your client with more flexibility. You might decide to split delivery into three phases: set-up, papering, and clean-up.
If the product-of-the-project is more difficult to define than wallpapering (e.g., commercial software, new drug development, major defense systems), you may need multiple discovery and design phases, but in every case, a well-defined PLC will tell you how to go about it. Each phase-end deliverable should provide a more detailed description of your product-scope.
There is no one right answer for how to define the phases of a PLC or for what should be included in each. On the other hand, similar projects will generally have similar phases and similar phase names. For example, if you’re dealing with software, you are likely to have one PLC for development projects, a second for upgrades of existing applications, and a third for purchased software. If you’re doing agile software development, life is somewhat simpler since each iteration serves as a de facto PLC phase that includes discovery, design, and delivery.
To summarize: the first key to finding out where your product-scope is located is to recognize that the document that contains it changes as you move through each phase of your PLC. The second key is to name the early phases of your PLC after the documents that you will create as you discover and design your product-scope. Finally, it also means that naming your phases after your project management activities (initiation, planning, execution, control, closing) will only work for a single phase subproject when someone else is defining the product-scope for you.
The other kind of scope
Many of you may have noticed that I haven’t made any mention of how product-scope gets discovered, designed, and delivered. I refer to the “how” as work-scope, and I define work-scope as “the actions that must be taken to discover, define, and deliver product-scope.” Determining how is just as important as determining the characteristics of the product-of-the-project. In fact, most of the tools and techniques of project management are focused on how:
Developing a WBS is about determining which actions need to be taken.
Preparing a schedule is about deciding when these actions will be taken.
Estimating is about figuring out how much it will cost to take these actions.
Identifying risks is about predicting what other the actions might be needed.
Measuring performance is about analyzing how well the work is going.
In addition, if you look back at the alternative definitions of scope, you will find that School #2 has (using my definitions) equated scope with work-scope, and that School #3 is treating scope as inclusive of both product-scope and work-scope. Although this approach can be effective for single-phase subprojects, it makes it almost impossible to manage either product-scope or work-scope effectively on any other kind of project.
Benefits of differentiating product-scope and work-scope
First and foremost, using a project lifecycle that is product-scope-oriented (discover-design-deliver, subdivided as necessary) rather than work-scope-oriented (initiate, plan, execute, control, and close) focuses the attention of the project manager and the team where it belongs: on the product-of-the-project. A product-scope-oriented PLC also provides a better structure for program and portfolio management decisions:
Reviews at the end of each phase should result in cancellation of poorly conceived projects before the organization has become too psychologically invested in them.
Phase-by-phase budgets, schedules, and resource requirements will always be more accurate and reliable than premature guesstimates.
Second, differentiating product-scope and work-scope provides greater clarity around what changes are scope changes. Quite simply, any change to the characteristics of the product-of-the-project represents a product-scope change. While most people understand the implications of a change to a documented characteristic (e.g., deciding to use a different wallpaper pattern after the paper has already been purchased), this usage makes it clear that changes to undocumented characteristics (e.g., choosing paper that requires a liner) are also product-scope changes.
In addition, recognizing the difference between product-scope and work-scope makes it easier to explain to your customer, client, or sponsor why the cost of two similar changes can be so different: it is because of the impact on the work-scope. Despite the better communication, there is still a need for clear and agreed change control practices to define who is responsible for the cost of any changes.
Finally, a product-scope-oriented PLC highlights the need for adjustments in your project management approach based on where you are in the lifecycle. Early phases need more iteration and more recognition of uncertainty. Later phases need a more task-oriented approach. Project managers who do best in the early phases should also be your prime candidates for promotion to program management ... but that’s a subject for a future article.