Author: Jeff Sullivan

There are few things that can derail a project faster than poor scope management.

Fail to define the scope clearly and you can find yourself dealing with a bloated project that exhausts your resources and depletes your budget.

Poor scoping is nearly a universal problem in project management. In PMI’s 2018 Pulse of the Profession survey, 52% of reviewed projects experienced uncontrolled changes to the project scope.

Part of the problem is the imprecise nature of project scoping. Projects are perpetually changing entities. What you set out to create and what you finally deliver can be vastly different. Given these demands, scoping projects requires not just knowledge, but also intuition and experience.

One way to avoid these issues is to follow the 7 golden rules of project scoping that I’ve covered below:

1. Use the WBS to Define the Scope

One of the more common mistakes in project management is to define the scope based on the scope statement. Despite the misleading moniker, the scope statement is too high-level and open-ended to be a good guide for the project scope. It can give you an overall idea of what to create, but it doesn’t tell you anything about the actual deliverables.

Get around this problem by defining your scope as per the WBS (Work Breakdown Structure). The WBS, as you would know, defines the “what” of the project, i.e. all the deliverables you need to reach 100% completion.

Using the WBS to define the scope gives you a better understanding of what you need to create. Since it is deliverables-focused, any request or change that ends up in a new deliverable can be tagged as “out of scope”.

2. Develop a Clear Process for Capturing Requirements

In the course of a large project, it is common for change requests to come in from different stakeholders. Some of these requests are well-defined with detailed requirements. Some other requests might not be as clear in their goals.

This lack of clarity often leads to scope issues. If your project team isn’t sure what to create (and what not to) for every request, it is inevitable that they’ll end up going out of scope.

Solve this problem by developing a clear process for capturing requirements. No matter where the request comes from, it should adhere to the guidelines in your requirements documentation. This will ensure that there is consistency and clarity across all requests.

3. Involve Project Sponsors in Scope Planning

There is a common belief that defining the scope is entirely the project manager’s responsibility. This causes them to interpret the scope as per their own experience and best practices. Sponsors are either isolated from the planning process or involved too late to leave an impact.

A better tactic is to take a consultative approach to scope planning. Get sponsors and stakeholders involved. Ask for their feedback, key needs, and business goals.

Here are two concrete steps you can take to get sponsors involved:

• Get sponsors to create their own project charter. This should include their project vision and business needs. Compare it against your charter to see if there is any misalignment in the project’s scope.
• Ask sponsors for any high-level features that are not in scope. Knowing what you don’t have to do can often be more illuminating than knowing what you have to do.

4. Create Change-Focused Communication Plans

Absent stakeholders not only slow down project progress, they also cause scope management issues. If stakeholders aren’t involved, a lot of decision-making is either delayed or becomes the responsibility of the project team.

Conversely, if the project team wants to expand the project’s scope to accommodate a key feature, there is no one on the client side to sign-off. They might end up adding features that could have been avoided if the stakeholder was more communicative.

Keeping stakeholders engaged is a universal problem in projects, of course. But one way you can help is to create change-focused communication plans. Don’t send busy stakeholders 10-page documents with a list of change requests. Rather, change your communication pattern to fit

the stakeholder’s needs.

You should know the following about the stakeholder:

• What kind of communication channel he/she prefers
• Whether he/she likes crisp summaries or deep details for change requests
• Alternate communication channels and contact numbers

Your goal should be to make it as easy as possible for the stakeholder to figure out the next steps on a change request.

---

---

5. Don’t Capture All Requirements in One Go

Even the smallest of change requests can have complex requirements. Collecting all these requirements in one go makes you more likely to miss some critical information.

The solution? Capture requirements in three “layers”:

• Scoping layer: Use this to identify the scope of the request and its impact on the project.
• Expanded layer: Dive into further details. Gauge the impact of the change on any dependent tasks and deliverables.
• Details layer: Bring in an expert to figure out the feasibility of the change request, how long it will take to effect, and resource requirements.

Think of this as a collaborative team effort. Don’t capture all requirements by yourself. Rather, get expert team members involved to ensure that you have all the right information to pull it off.

6. Break Complex Projects into Sub-Projects

When you’re scoping a large project, it is easy for things to get a bit too overwhelming. You can miss track of deliverables, skip critical information, and gloss over feedback from sponsors.

If you’ve ever been in that situation, consider breaking the project into smaller sub-projects.

Smaller projects are nimbler and less overwhelming. Since their deadlines are tighter, there is lesser room for large scope deviations. Further, you wrap up smaller projects faster. This keeps your team motivated and energized – something that can easily lag in a slow, complex undertaking,

But the biggest reason to break complex projects into smaller parts is that it helps get stakeholders involved. Different stakeholders can take over individual parts of the project. Since decision-making is more distributed instead of centralized, there are fewer chances that a stakeholder will go missing.

7. Practice Better Scope Monitoring

Last, but not the least, always monitor the project closely for any scope deviations. Keep track of “small requests” that eat away entire weeks, or project teams “gold plating” deliverables to please clients. A lot of this can easily happen in a large project if there isn’t enough oversight.

Always keep one eye on your baseline as you manage the project.

Conclusion

Scope management is one of the more important jobs you’ll do as a project manager. A project that routinely goes out of scope is a project that’s destined to fail. By closely monitoring the scope, involving sponsors in scope planning, and using the WBS, you can make sure that your projects finish on time and within budget.