Scope--mastering the fuzzy constraint
Time, scope, and cost are known as the “triple constraints” of project management. Time and cost are relatively easy to understand because they can be easily quantified. Scope, on the other hand, is fuzzy—usually expressed in qualitative terms that leave room for interpretation and misunderstanding. Consequently, it's often the biggest source of conflicts in a project. This paper demonstrates that the key to understanding scope is recognizing that it is inherently multidimensional. There is no one simple measure to capture scope. The paper also questions some of the traditional assumptions about scope change—particularly the view that changes in scope that affect time and cost should be avoided. A project's ability to change could be its most significant advantage. The tension between these two perspectives is at the heart of the shift to more adaptive project management methodologies. This paper will help project managers achieve a more sophisticated—and more effective—appreciation of how to deal with defining and managing scope in their projects.
In one of the earliest books on project management, John Stanley Baumgartner (1963) wrote that, “Fundamentally, the…customer wants to know just three things during the life of a project:
- Will deliveries be on time?
- Will the final cost be within the amount contemplated?
- Will the product meet the required performance and reliability standards?” (Baumgartner, 1963, p. 31).
These “three things” have come to be known as the “triple constraints” or the “project management triangle”: time, cost, and scope. As stated in the PMBOK® Guide—Third Edition (Project Management Institute [PMI], 2004), “The relationship among these factors is such that if any one of the three factors changes, at least one other factor is likely to be affected” (p. 8). Or, as it's been put more succinctly: “Better. Faster. Cheaper. Pick any two.”
Of the three factors, two are easy to identify and easy to grasp because they are easy to quantify. For example, a project needs to deliver a product within one year. If the team is able to meet that deadline, then the project is on time. If it's one day late, it's over time. Cost is equally easy to understand. If a project's budget is $100,000 and the final cost is $90,000, it's under cost. If the final cost is $110,000, it's over cost. In any of these cases, the “state” of the project as reflected in time and cost is clear.
But what does it mean for a project to be under, over, or within scope? Scope is a qualitative constraint—that much is generally accepted. But it's rarely, if ever, just one constraint. Instead, it's usually a combination of constraints. Some may be relatively well-recognized and objective. Others may be highly subjective. And some may not even be explicitly stated or even understood by all stakeholders. How can a project manager ever hope to manage scope if it's so difficult to pin down?
What Makes Scope “Fuzzy?”
For something so basic to the practice of project management, the term “scope” turns out to lack a consistent definition. The PMBOK® Guide—Fourth Edition defines scope as, “The sum of the products, services, and results to be provided as a project” (PMI, 2008, p. 440). In other words, scope is the output of the project. But one can easily find other sources that define scope as the work of the project.
Here, for example, are five definitions of scope taken from recent books on project management:
- The extent of work that must be performed to complete a project (Biafore, 2011, p. 413).
- The definition of what will be produced by the project for the customer (Charvat, 2002, p. 225).
- All the required work, and only the required work, to create the project deliverable (Luckey & Phillips, 2006, p. 16).
- The definition of what will be produced by the project for the customer (Martin & Tate, 2001, p. 252).
- The boundary defining the area in which a project or stage has to operate (Wren, 2003, p. 19).
Three key aspects of scope emerge across these definitions:
- Output or deliverables
The first two are explicitly recognized in the PMBOK® Guide—Fourth Edition, which notes:
In the project context, the term scope can refer to:
- Product scope. The features and functions that characterize a product, service, or result or
- Project scope. The work that needs to be accomplished to deliver a product, service, or result within the specified features and functions. (PMI, 2008, p. 103)
The third—boundaries—can be seen as derived from the combination of the first two. Without some concept of boundaries, one cannot identify if an activity or requirement is “in scope” or “out of scope.”
Separating scope into these dimensions, however, does not resolve the problem of subjectivity. A project team may, for example, propose to prepare three prototypes to refine the customer's requirements and reduce production risks. The customer may reject this proposal as out of scope in both dimensions. Because the prototypes are expendable and will not be considered finished products, the customer may refuse to consider them as deliverables. And if he perceives that prototyping delays final production and consumes resources that could be better used, he may reject the activity as outside the acceptable extent of project work.
This example illustrates the fuzzy nature of scope in project management. I use the word fuzzy not just because it's commonly used to describe situations that are fundamentally ambiguous or confused, but also because of its use in the highly specialized mathematical discipline of fuzzy logic. Fuzzy logic provides principles for dealing with problems that are approximate rather than exact—with the relationship between fuzzy sets. Fuzzy logic offers an effective model for understanding the definition of scope in a project.
As first defined by Lofti Zadeh, a fuzzy set “is a class of objects with a continuum of grades of membership” (Zadeh, 1965, p. 338). To illustrate this concept, Zadeh offers the example “the class of tall men.” Most of us would agree than a man 7 feet tall is definitely in the class of tall men. The same for a man 6 feet 9 inches tall. But what about a man who's 6 feet tall? Or one who's 5 feet 10 inches? What makes this set fuzzy is that there is no universally accepted definition of “tall” or of the measurement that divides the “tall” from the “not tall.” This same situation applies to definitions of project scope.
In the prototyping example, the project team considers prototyping to be part of the class of “work within the project's scope” while the customer does not. Unlike the classes “costs within the project's budget” and “time within the project's schedule,” there is no clear boundary that enables either party to say—on an objective and quantifiable basis—what is within the class of “project scope.” In fact, like the glass that's half empty or half full, the definition of project scope often depends entirely on one's perspective. Which is exactly why differing perspectives on what and what is not within scope can so often be the root of conflicts within a project.
In the worst cases, the subjective nature of project scope combines with imprecise expectations of product scope to create what is known as the “bring me a rock” game. This expression is used to capture the problem of satisfying imprecise customer expectations:
Customer: “Bring me a rock.”
Project manager goes forth, finds a rock, and brings it back to the customer.
Customer: “I don't like that one. Bring me another rock.”
Project manager goes forth, finds another rock, and brings it back to the customer.
Customer: “I don't like that one. Bring me another rock.”
And so on, ad infinitum. In the “bring me a rock” game, the class of “rocks acceptable to the customer' is so fuzzy as to encompass both all rocks in existence and none of them.
The Multiple Dimensions of Scope
The risk of imprecise—and worse, unstated—customer expectations and requirements leading to a “bring me a rock” situation should not be used as an excuse, however, to give up hope and conclude that all things are relative and nothing can be said with certainty. One need not abandon all hope when entering the domain of scope management.
No project's scope can ever be entirely free of fuzziness—free from subjectivity and imperfect definitions—as long as human beings are involved. On the other hand, it's also highly improbably that any project will ever survive initiation if its scope is entirely vague, undefined, and subject to unpredictable expectations. And in many cases, there are at least a few elements of project scope that can be clearly identified and accepted by all parties.
A basic task during project initiation, in fact, is to nail down as many elements of a project's scope as possible. This can be done through the statement of project scope. The PMBOK® Guide—Fourth Edition recommends that a statement of a project's scope address the following elements as a minimum:
- Description of the product(s);
- Boundaries—an explicit statement of what is out of scope for the project;
- Acceptance criteria;
- Constraints—the things that limit the project team's options: at a minimum, budget (cost) and schedule (time); and
- Assumptions (PMI, 2008, p. 115).
In my opinion, these are just the starting points. Other elements of a project's scope that can be determined with relative certainty and confidence include:
- How many copies of each deliverable are required?
- Where will the project install or deliver its deliverables?
- Functional requirements
- What are the requirements for how deliverables will perform or be used?
- Non-functional requirements
- How reliable, maintainable, available, or secure must deliverables be?
- Use cases/modes of operation
- How is the capability expected to be used? Will it be used in a normal office environment or will it have to withstand heat, cold, wet, shock, rough handling, or other harsh conditions?
- Are there regulatory requirements regarding aspects such as safety, ingredients, production, import/export, or financial accountability?
- Intended users
- Who will use the project's outputs? Are they considered experts or novices? Are they expected to be trained, to already know how to use it, or to “just figure it out”?
- If the project has to acquire some or all of its deliverables or services on a contractual basis, are there constraints on how these can be procured? This is an almost universal constraint on projects involving publicly funded procurements.
- Are there restrictions on information, materials, or people involved in the project or its deliverables?
- How much visibility does the customer expect to have as the project work is being carried out? How should status be reported, and how often? Are there stage gates or milestones at which the customer expects to decide if work will proceed or the project stopped?
- Look and feel/appearance
- Do any of the deliverables need to comply with special requirements about how they look, such as an approved color scheme, document layout, or man-machine interface standards?
This list is hardly exhaustive or exclusive, but merely intended to suggest that there are many angles from which the “fuzziness” of a project's scope can be reduced.
Some of these aspects relate to product scope, as defined above in the PMBOK® Guide—Fourth Edition. Best practice standards, such as IEEE Standard 1233, The Guide for Developing System Requirements Specifications, can be useful in conducting a thorough and structured process of capturing and documenting such requirements. Identifying required deliverables through a product breakdown structure can also bound the level of uncertainty and subjectivity about a project's outputs.
Others relate to the scope of work—what in a contractual context would be referred to as the statement of work. Here a work breakdown structure, combined with the relevant constraints on performance (such as those associated with public procurements or regulatory compliance) can help to better define and set expectations about what work will be performed as part of the project's execution and about how that work will be done.
In addition, it can be invaluable to capture how these aspects interrelate. Are any of these requirements more important than others? Is there a preferred order or precedence in which the customer wants them to be addressed or delivered? A MoSCoW assessment—breaking down the various requirements based on whether the customers consider them Must Haves, Should Haves, Could Haves, or Won't Haves—can also aid in determining how to best direct project resources to meet expectations. It can be equally important to capture the negative aspects of a project's scope, such as the consequences if one or more deliverables cannot be delivered on time or to the required specification.
By probing the customer's requirements and expectations from as many angles as possible, a project team can significantly reduce the number of uncertain elements of project scope and reduce the potential variability of these elements. It does not guarantee that conflicts over project scope will not occur, but it can help isolate the potential sources of these conflicts.
Two Perspectives on Scope Change
According to the traditional approach to project management, scope is something to be controlled. Once the plan is approved, changes to scope should be minimized. As one text on project management puts it, “One of the most complicated challenges a project must deal with is keeping the project scope contained to the level that was originally defined in the project initiation phase and that satisfies the project objectives as originally defined—i.e., avoiding ‘scope creep’” (Keyes, 2009, p. 28). Given the nature of the “triple constraint,” one writer observes, “changes or additions to the scope…usually result in time and cost increases” (Nicholas, 2004). In this view, “scope creep” is seen as the cancer of project management: highly undesirable and often fatal in its consequences.
This is also the perspective reflected in earned value management (EVM), which translates the project plan into quantitative and measurable terms. According to EVM theory, a project's cost performance index (CPI), defined as the ratio between its earned value and its actual cost (CPI = EV/AC), is a key indicator of a project's performance. A CPI of 1.0 means that the cost of completing the work is right on plan. A CPI that deviates from this mark—whether higher or lower—means that work is either costing more than planned or that resources are being underused and tied up from supporting other tasks or other projects unnecessarily.
In simple terms, this can be seen as the “ready, aim, fire” model of project planning and execution. In project initiation and scope definition (the “ready, aim” phases), the project plan is developed. Then, once the plan is approved, what matters most is to execute (“fire”) according to the plan. Cost overruns, schedule delays, and “scope creep” are all deviations from this plan—and, therefore, uniformly negative consequences.
The pervasiveness of this viewpoint can be illustrated by the following definitions of “scope creep,” taken from a sample of project management texts:
- Unplanned changes to the project scope (Luckey & Phillips, 2006, p. 17).
- Unintentional expansion of the project's boundaries (Kleim & Ludin, 1998, p. 32).
- Burdensome growth or enhancements of project requirements that increase project budgets and schedules (Nicholas, 2004, p. 126).
- The tendency of the scope of a project to expand once it has started (Gray & Larson, 2006, p. 562).
- What happens when project requirements are changed without the discipline of change control. (Frame, 2003, p. 205).
- A progressive increase in scope as the project continues (Brandon, 2006, p. 401).
In the first four definitions, “scope creep” is rather like the invasion of a deadly virus into a healthy body, something to be fought. In the fifth, what makes “scope creep” undesirable is not the change but the lack of control. Only the last is free of any implication that there is something undesirable about the change: To Brandon, “scope creep” is simply a phenomenon, with no suggestion of positive or negative consequences.
There are several fundamental problems with this approach, problems that undermine the ability of project teams to effectively manage project scope. First and foremost, it presumes that changes to a project plan generally stem from internal sources—from a weakness in the plan itself, such as an unrealistic estimate of cost, duration, or risk; or from a deficiency in the team's execution of the plan, such as their failure to complete a task within the allotted time. To use the “ready, aim, fire” analogy, the project fails to hit the target due to poor aiming or improper firing or both.
But change is actually more likely to come from some factor outside the project. There is, after all, more of the world outside the project's scope than within it. The “ready, aim, fire” model works only if the world outside the project remains relatively static and stable. The longer the duration of a project and the larger its scope, the higher the probability that one or more external factors will affect the project's execution. Indeed, the longer the duration of any project, the lower the probability that it can possibly be executed according to plan, whether due to external or internal factors.
True, increases in project scope will usually increase project costs and extend the project schedule. But what is wrong with that? If the most important objective for an organization is that a particular project is completed within a set amount of time or a fixed budget, then it is inevitable that scope must be seen and managed as a dependent variable. But not all projects need to be considered zero-sum games, where scope is somehow in a competition with time and cost. There are plenty of cases where a customer is quite ready to accept that increases in scope require more time and money.
The crucial question that must be answered to determine how to approach a project's scope is simple: Should change be managed or avoided? There are times when the “ready, aim, fire” approach is justified—for example, when safety, security, or time to market overrides all other concerns. Or when the project's duration is relatively short, its contingency budget small, and it can be said with confidence that the plan is accurate and unlikely to need any changes. In such a case, scope change should be minimized and avoided.
But what if the project's ability to adapt to changes—with proper controls, of course—is considered more important than sticking to the budget and schedule set with the initial project plan? This is exactly the capability that agile, rapid application development, spiral development, and other adaptive methodologies are meant to foster. In contrast to the “ready, aim, fire” approach of predictive project planning and proscriptive project execution, adaptive projects take a “ready, fire, aim” approach. Rather like a heat-seeking missile, an adaptive project team adjusts its course to home in on the project's objective as requirements, constraints, and opportunities are better understood.
An adaptive methodology is not a prerequisite to a responsive approach to scope changes, however. What matters most is a broader perspective on the relationship between scope changes and the reasons an organization has undertaken a project in the first place. Scope changes don't spring forth full grown from the head of Zeus. They can be traced to specific sources. True, there are times when the source is some deficiency in the project: poorly understood requirements; inaccurate estimates; incompetence; the undue influence of a particularly vocal user; whims; hidden agendas.
More often, though, the source is outside the project and tied to one or more factors of crucial concern to the organization: changes in the market; changes in the business environment; changes in organizational strategy; or unexpected successes or failures in related projects or activities. For projects that involve work or deliverables for which there are few or no precedents, the source may simply be the project team's access to information not available earlier in the project. As Linda Hayes (2001) wrote, what is characterized as scope creep is often nothing more than, “the inevitable realization that requirements are living, growing things that are discovered instead of defined” (p. 48).
Ironically—given the rather mechanistic approach of the traditional “ready, aim, fire” approach to project management—the tendency to avoid scope changes actually ignores a fundamental principle of mechanics. Newton's third law of motion holds that, “To every action there is always an equal and opposite reaction.” Changes that a project team determines are out of scope do not simply disappear if they are rejected. Their rejection produces some equal and opposite reaction. Not incorporating an additional feature in a software program, for example, may force its users to find a less productive manual work-around.
Indeed, the failure of a project to accommodate a change in scope can have far more serious consequences for the organization as a whole than if the change had been accepted—even if the change increased the project's budget and extended its schedule. The ability of a project to adapt to such changes can make a crucial difference in its ultimate value to the organization. After all, the project's objectives are subordinate to those of the organization—not vice-versa. Therefore, it is crucial for the project team to understand at the very start of a project: which is more important? Avoiding change or managing it?
Of the three elements of the “triple constraint”—time, cost, and scope—scope is by far the most subjective and most challenging to manage. Like a fuzzy set, the components of a project's scope often do not have clear boundaries that enable objective decisions about whether something is “in” or “out” of scope. Breaking down a project's scope into as many dimensions as possible can reduce the amount of uncertainty—and the resulting level of risk—in its scope definition.
Even with these measures, however, effective project scope management is, in the author's view, handicapped by the traditional predictive approach to project management, which treats changes in scope as generally undesirable. It is far more likely that changes in scope are linked to changes outside the project that involve considerations that far outweigh the consequences for the project itself. And failing to accommodate these changes within the project can lead to far worse results for the organization. For these reasons, scope management—more than any other project management function—demands that project teams develop the capacity to consider scope changes from the perspective of their significance for the organization as a whole.
Baumgartner, J. S. (1963). Project management. Homewood, IL: Richard D. Irwin.
Biafore, B. (2011). Successful project management: Applying best practices and real-world techniques with Microsoft® Project. Sebastopol, CA: O'Reilly Media, Inc.
Brandon, D. (2006). Project management for modern information systems. Hershey, PA: IRM Press.
Charvat, J. (2002). Project management nation: Tools, techniques, and goals for the new and practicing IT project manager. New York, NY: John Wiley & Sons, Inc.
Frame, J. (2003). Managing projects in organizations. San Francisco, CA: Jossey-Bass.
Gray, C., & Larson, E. (2006). Project management: The managerial process. New York, NY: McGraw-Hill Irwin.
Hayes, L. (2001). Six myths about managing software development in the new millennium. In P. Tinnirello, (Ed.), New directions in project management. Boca Raton, FL: Auerbach Publications.
Keyes, J. (2009). Leading IT projects: The IT manager's guide. Boca Raton, FL: CRC Press.
Kleim, R., & Ludin, I. (1998). Project management practitioner's handbook. New York, NY: AMACOM Books.
Luckey, T., & Phillips, J. (2006). Software project management for dummies®. Hoboken, NJ: Wiley Publishing, Inc.
Martin, P., & Tate, K. (2001). Getting started in project management. New York, NY: John Wiley & Sons, Inc.
Nicholas, J. (2004). Project management for business and engineering: Principles and practice (2nd ed.). Oxford, UK: Elsevier Butterworth–Heinemann.
Project management triangle. (2011, April 9). In Wikipedia, the free encyclopedia. Retrieved from http://en.wikipedia.org/wiki/Project_management_triangle
Project Management Institute. (2004). A guide to the project management body of knowledge (PMBOK® Guide) (3rd ed.). Newtown Square, PA: Project Management Institute.
Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK® Guide) (4th ed.). Newtown Square, PA: Project Management Institute.
Wren, A. (2003).The project management A–Z: A compendium of project management techniques and how to use them. Aldershot, UK: Gower Publishing Limited.
Zadeh, L. (1965). Fuzzy sets. Information and Control, 8(3), 338–353.
© 2012, Brad Bigelow
Originally published as a part of 2012 PMI Global Congress Proceedings – Marseille, France