A couple of months ago, a renowned online platform for project managers—Project-Management.com—published a story about the top 10 causes of project failure. Just scanning this text, you won’t find anything about project scope management. Yet when you read it thoroughly, you’ll see that factors described by the author are very much connected to defining and controlling the project’s scope. Poor preparation was deemed the number 1 cause of failure, followed by inadequate documentation and tracking. The list is closed by disregarding project warning signs. We’re mentioning these because this blog post is meant to help you reduce or eliminate these dangers by means of effectively managing the scope of the project.

Read on to see that scope management starts with preparation and is inextricably linked to proper documentation and monitoring project’s progress. What about project warning signs? You’ll see that one of the more ominous signs is the scope creep. Fortunately, successful scope management can help you avoid it.

Let’s start by defining the most important terms we’ll use in this guide:

What is project scope management in project management?

Project scope management is the process that allows you to ensure that the project includes all the work required, and only the work required (source: PMBOK® Guide, 6th edition).

In order to fully understand project scope management, you need to know what the project scope is. In short, it’s the work required to output all of that project’s requirements (i.e., to deliver a product successfully). It’s slightly wider than the product scope definition: a product scope details the features and functions of a product.

How can you benefit from effective project scope management?

Arguably the main benefit of scope management is that it helps you to deliver projects successfully—you know what needs to be done (and what doesn’t), so you can manage your team with more confidence. Other benefits of this process include:

  • with scope statement and a work breakdown structure in place, it’s much easier to schedule the work needed to deliver the project,
  • strategic resource management possible when you know the scope of the project,
  • you can prevent or mitigate scope creep (a situation when project’s scope grows dynamically and uncontrollably),
  • it gives you a chance to establish good standards of communication and project management early on in the project lifecycle,
  • knowing the scope of the project, you can better assess its current progress and your team’s performance.

Steps to consider in scope management:

The steps listed below are based on the Project Management Body of Knowledge (PMBOK®). Make sure to check out their instruction if you’re looking for a comprehensive scope management plan. Below, you’ll find a scope management process that should enable you to implement it for your upcoming project.

Create a plan

Effective scope management should start with you preparing upfront. Even before you collect requirements, and draft the scope for your project, plan how you’re going to go about it. Identify the main stakeholders and people who will have something to say about this project’s scope. Meet with your team and establish how the process of creating the scope will look like. It would help if you also thought about possible changes to your project’s scope. Of course, at this point, you’re not likely to know what can change, but you can determine what happens if changes occur.

Collect all of the decisions you make here in the scope management plan. It will be your guiding document for conducting the rest of the process.

Gather requirements and define the scope

It’s time to collect project requirements: things that have to be done in order to achieve your project’s goals. It’s not as simple as just going to your client and asking how do you want the end-product to look and behave like? Gathering requirements is a discovery process, as the stakeholders might not even know at this point which particular features should be included in their product (especially if you’re tasked with managing a software development-related project. )

Granted, your clients may not have the exact vision of the end-product, but they are probably aware of the business objectives that this project should achieve. You can create a series of workshops and interviews to uncover users’ needs and, as a result, establish the requirements.

Yet another way of gathering data-driven requirements is conducting a series of tests with prototypes in order to see which features and functions receive the most positive reaction from the target audience.

You can also do some benchmarking to compare your potential requirements with the industry’s best practices.

Once you end up with a list of different requirements (features and functions, business objectives, processes needed to deliver a product, acceptance criteria), you can try to define the scope. Keep in mind that usually, not all of the elements you initially gather end up in the final project scope.

Defining project scope means creating the so-called scope statement document. A scope statement is where you document the scope of the project consisting of:

  • project deliverables,
  • the work required to complete these deliverables,
  • potential constraints,
  • acceptance criteria.
TIP: It might be a good idea to document the exclusions in the scope statement as well (we will not include X and Y in the project scope). They will be helpful when you have to manage expectations and negotiate changes to the scope later on.

Create a work breakdown structure (WBS)

This step will help you to visualize the scope better and break it down into smaller elements. The work breakdown structure is a hierarchical framework of deliverables that correspond with the project’s output. Traditionally, the WBS is describing what and not how, so you should focus on deliverables instead of activities (e.g., payment rather than design/develop/test the payment path). Another way to think about it is that WBS describes “what the client will receive,” not “what actions will be done by the project team.” Some project managers, however, treat it more like a breakdown of tasks and subtasks, which also is a helpful document.

Why should you bother with creating a WBS in the first place? First of all, it’s easier to create a schedule when you see the deliverables broken down into smaller bits. You can also create and allocate tasks more comfortably, having the WBS on which you can rely. 

Finally, such a hierarchical structure makes it faster to grasp the project scope, especially if one’s a visual thinker. Not sure if you identify as such? Check our guide Sketchnoting for Project Managers to see how you can benefit from visual thinking in project management.

Validate the scope and control it during the project lifecycle

You have the project scope statement and the WBS, so you know what should be included in the project. Now, you need the stakeholders to validate and sign off the scope. Review it to see if there are any ambiguities and try to finalize it before the project work begins. This way, you can reduce the chances of the scope creep.

When the project is going on, you have to control the scope. Monitor what’s been done vs. what was supposed to be done. During that process, you will probably find the following tools useful:

Compare project reports with the scope and the project management schedule to see if the timeline, workload, tasks completed, etc. align with your estimates.

The process of managing the scope of your project might seem complicated, especially given the amount of preparation that goes into it. Once you give it a try, however, you’ll see that the documents you create very early in the process (scope management plan and project scope statement) will help you tremendously further down the line and enable you to deliver the product or service your team is working on.

Related posts