5.10. Managing the Scope

Time (schedule), cost, and scope are known as the triple constraints of project management. It’s not possible to change one without changing at least one of the others. If the project takes twice as long as expected to complete, then the cost will almost certainly go up. On the other hand, a decision to cut costs, perhaps by using less experienced labor, could lead to a work slowdown, extending the schedule. Such a decision might also result in a change to the project’s scope, perhaps in the form of a lower quality product.

The initiation phase is too early in the project to nail down precise details about time and cost, but it is a good time to think long and hard about scope, which is “all of the work that needs to be done to provide the product or service your project is delivering” (Martinez, n.d.). In this early stage, you and the project stakeholders might do some blue sky thinking about what your project could possibly achieve, without regard to the constraints of time, cost, and scope. But before too long you’ll need to zero in on a definition of the project’s scope, formalizing it as a scope statement, using the information currently available to you.

Except for the simplest projects, any scope definition will almost certainly evolve as you learn more about the project and the customer’s needs. The term scope evolution refers to changes that all stakeholders agree on, and that are accompanied by corresponding changes in budget and schedule. Scope evolution is a natural result of the kind of learning that goes on as a project unfolds. This includes learning that arises from fresh insights into the needs of the end user, new regulations, or upheaval in the marketplace. As long as all stakeholders agree on the scope changes (and the associated changes to the budget and schedule), scope evolution ensures that customers actually get what they want out of the project. The more you talk with the client and learn about their needs, the more you will be able to refine the scope.

Indeed, one of the main jobs of a project manager is managing scope evolution. But different types of projects will involve varying amounts of scope evolution. For example, if you’re working on a project related to satisfying a specific environmental regulation, the initial definition of the project’s scope might be clear, requiring little refinement as the project unfolds, as long as the regulation itself is not altered. But if you are working on a product designed to satisfy a brand-new market demand, you might need to refine the scope continually to ensure that you satisfy your customers’ needs.

Perhaps the most common cause of scope evolution is a change in the context in which a project is planned and executed. Alterations in market forces, changing demographics, new or more vigorous competition, and technological advancements can all change a project’s context, forcing you to rethink its scope. This potential for changing contexts means that no two projects are the same. You might think Project B is nearly identical to Project A, but then a sudden shift in context can change everything. As shown in Figure 5-5, context is largely defined by the organizational, social, and political structures in which a project occurs.

Scope evolution is managed change. It is an approved alteration to the project scope that occurs as the project participants learn more about the project. It results in an official change in the project scope, and therefore to the project budget or schedule, as agreed to by all project participants. This kind of managed change is a natural and rational result of the kind of learning that goes on throughout the course of a project. It is a conscious choice necessitated by new information forcing you to reconsider project essentials in order to achieve the intended project value.

Scope creep is unmanaged change. It is caused by uncontrolled changes to the project scope. Such changes might add value from the customer’s perspective, but the time, money, and resources consumed by the change of scope lead to additional overruns. Scope creep tends to happen bit by bit because no one is paying close attention to the project’s scope. For example, in a kitchen remodeling project intended to replace countertops and cabinets, deciding at the last minute to replace all appliances might be an example of scope creep.

Creating a Clear Scope Statement (interchangeable with Project Charter)

The key to managing scope is a carefully crafted scope statement, which should be clear and precise. The details of how you plan to carry out a project may be vague at first, but what you want to achieve should be perfectly clear. Vagueness can lead to small changes to the project’s scope, which in turn lead to other changes, until the original project is no longer recognizable.

Writing a scope statement, the document that defines the project’s scope, is a major part of the initiation phase. However, according to Brad Bigelow (2012, p. 1) in an article for the Project Management Institute, it is “usually expressed in qualitative terms that leave room for interpretation and misunderstanding. Consequently, it’s often the biggest source of conflicts in a project”.

To avoid such problems, experienced project managers put a lot of effort into learning what should and shouldn’t be included in the project, and then articulating these boundaries as clearly as possible in the form of a scope statement. According to Bigelow (2012, p. 2), this work is essential to ensuring a project’s success: “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 improbable that any project will ever survive initiation if its scope is entirely vague, undefined, and subject to unpredictable expectations”.

If the scope is poorly defined, then what is or isn’t within the project scope is reduced to a matter of perspective. Not surprisingly, these “different perspectives…can often be the root of conflicts within a project” Bigelow (2012, p. 2). Bigelow describes a project in which the team and the customer see things very differently:

When the scope is poorly defined, satisfying the customer can grow increasingly difficult, with the team going off and creating what it thinks the customer wants, only to be told, “No, that’s not it.”

Practical

• Engage all stakeholders: Your goal is to keep people meaningfully engaged in your project. You don’t want stakeholders showing up for ceremonial appearances at project meetings. Instead, you want them seriously focused on the prospects for project success.
• Outcome clarity: Ask your customer to define success right at the beginning. Then, working with the customer and other stakeholders, define how success will be measured.
• Use a common vocabulary: At the beginning of any project, go to your end-customers and learn their vocabulary. Make sure you understand the terms that are important to them and what such terms mean to them. Whenever possible, use your customer’s vocabulary, not yours. Also, strive to speak in plain English whenever you can, and avoid techno-speak.
• Create a glossary of terms: On projects with a lot of complex jargon, consider creating a glossary of terms. Then publish it in a way that makes it accessible to all stakeholders, updating it as needed. Here’s an example of one such glossary: “COSO Framework. “
• Identify what you don’t know: When you start a project, there are always things you don’t know. The key is to know that you don’t know them. The more you strive to recognize this, the better you will be at predicting those unknowns and making provisions for them.
• Have key team members sign major project documents: Research shows that the act of signing a document makes people much more committed to delivering on the promises described in the document. Consider asking the entire project team to sign the project charter and scope documents. This simple act can serve as a powerful inducement to completing the project successfully.
• Proactive concurrency: In the early stages, avoid the trap of plotting one thing after another, in a linear fashion. Instead, start fast, doing as many things as you can concurrently, as quickly as you can. This will give you a sense of whether or not the scope, budget, resources, and schedule are all in relatively close alignment at the macro scale. If you find they are not, report that to management right away.
• Permanent urgency: In the living order in which all modern projects unfold, permanent urgency is the new law of nature. In the traditional, geometric order form of project management, you could assume that you would have sufficient time and resources to do things in a linear, step-by-step manner. But in the modern world, that’s rarely the case. Get used to an element of urgency in all projects. Try not to let this paralyze you and your team. Instead, let a sense of urgency spur you on to more agile, alert, and flexible project management techniques.
• Post the project documents prominently: Putting important documents front and center helps a team stay focused, especially if you have everyone sign them first. It also encourages the team to update them when necessary.
• Plan for errors: You and your team will almost certainly make mistakes, especially in the early stages of a project. Therefore, you should plan for that. Keep thinking ahead to what might go wrong, and how you could correct course.