4.6. Managing the Scope

Time, 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 labour, 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. However 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.

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 remodelling 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

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.”

Opinions vary on exactly what a scope statement should include, but at the very least it should contain the following:

• A brief justification of the project’s purpose, including a summary of the business needs the project will address.
• An explanation of the project’s goals.
• Acceptance criteria specify the conditions the product or service must satisfy before the customer will accept the deliverables.
• Deliverables are “the quantifiable goods or services that will be provided upon the completion of a project. Deliverables can be tangible or intangible parts of the development process, and they are often specified functions or characteristics of the project” (Bloomenthal, n.d., para. 1.).
• An explanation of anything excluded from the project—in other words, an explanation of what is out of scope for the project. This list should be “as detailed as is necessary to define the project boundaries to all stakeholders” (Feldsher, 2016, para. 11).
• Constraints, such as budget and schedule.
• Assumptions, including anything you currently believe to be true about the project. It’s also helpful to include ideas “about how you will address uncertain information as you conceive, plan, and perform your project” (Portny n.d., 2018).
• An explanation of any new or unusual technology you plan to use throughout the project. This is not a typical part of a scope statement, but “it’s likely that stakeholders will appreciate the transparency and feel more comfortable with the project moving forward” (Feldsher, 2016, para. 13).

Practical Tips

• 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 complete 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 centre 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.

“3. Project Initiation, Scope, and Structure” from Technical Project Management in Living and Geometric Order, 3rd edition by Jeffrey Russell, Wayne Pferdehirt and John Nelson  is licensed under a Creative Commons Attribution 4.0 International License.