Coloring Inside the Lines: Scope Management in Project Planning

Coloring Inside the Lines: Scope Management in Project Planning

As too many project managers have learned, the “just” request is the kiss of death.

“Can you just do me a quick favor?”

“Can you just make a small change here?”

Because no request is ever “just.” You agree to change the font on a webpage or retouch some trim on a remodel and next, you’re adjusting the entire website, or re-painting an entire wall. And before you know it, you’re engaged in a timely and expensive side-project where nothing is documented and none of the time is billable.

As a project manager, your aim is to identify what your client wants, and deliver it. It’s that simple.

But without vigilant scope management, the process goes more like this: You present the final deliverable, and the client says something is missing. So you go back to look at the scope statement and change orders, but the language is vague and mushy. Or there aren’t any documents at all. It’s a huge mess and nobody wants to clean it up.

No doubt about it, scope management is hard. It’s not easy to capture all of the requirements, to bend and flow through a project as the expectations change. As any project manager can attest, it’s one of the hardest aspects of managing a project.

But not managing scope isn’t an option.

That’s why a plan is required. And a plan is only as good as the tools, processes and documents that make it up.

That is what this post is about. It’s going to cover how to manage scope in project management, so that you can deliver a project that’s brilliant and scintillating…without scribbling outside the lines.

The Six Processes in Scope Management

Scope is as fundamental to a project as the budget and timeline. The Project Management Glossary defines it as: “Everything a project is supposed to accomplish in order to be deemed successful.”

Scope management is a responsibility that begins at Stage 1 and continues all the way until the client signs off for the final deliverable. Here are the six key stages to successfully managing scope from the beginning of a project to the end.

Step 1: Determine How to Manage Scope

There’s more than one way to skin a cat, and there’s more than one way to manage scope.

From how to collect requirements, to what to include in the scope statement, to how to process change orders, it’s important to get your bearings at the start.

These processes needn’t be developed from scratch with each go-around. Once a reliable system is developed, it can be utilized on projects again and again.

Step 2: Collect Requirement From the Customer

A project’s requirements directly determine its scope. Essentially, they summarize everything that’s needed to bring a project to completion.

And so making every effort to gather requirements thoroughly ensures that the project’s scope is accurately understood from the start. In order for this process to run smoothly, some project managers even have a requirement management plan.

Determine the requirements by communicating with the customer and key stakeholders.

Sometimes, a MoSCoW meeting with all stakeholders helps to quickly identify

a project’s high requirements and exclusions. At other times, a workshop for writing user stories is the solution.

Whatever the method, the objective is to include the contribution of every stakeholder, and capture a complete summary of the project’s requirements from the start.

Step 3: Define Scope

Once all the requirements are gathered, it’s time to define the scope. This entails decomposing each requirement and identifying all the steps needed to complete it. It means asking questions around who needs to be hired, and what equipment and materials are needed.

This is the stage for writing the project scope statement, which spells out all of the project’s assumptions, constraints, and exclusions. This statement is covered in more detail later in this post.

Step 4: Create a Work Breakdown Structure

A work breakdown structure (WBS) is a visual representation of all the work needed to meet a project’s requirements. It’s hierarchical, and lists the project objective at the top, then breaks the work into increasingly smaller packages at levels 2, 3 and 4.

To create a WBS, place the central deliverables into the second tier, and decompose them into smaller work packages, until it’s possible to make accurate estimates around the resources required for each.

Although a WBS isn’t chronological, it’s an excellent visual representation of a project’s entire work package.

This step marks the end of the planning stages for scope management. The additional two processes monitor and control scope throughout the project.

Step 5: Customer Evaluates Deliverables

Throughout a project, the customer inspects and reviews work, and signs off if the deliverable meets expectations.

Presenting the client with deliverables every two to three weeks allows the team to receive feedback and to understand if the project is on track.

At times, it’s necessary for a team to change direction in order to meet the client’s needs. Ongoing communication with the client makes it easier to pivot. If the team instead waits and presents deliverables at the end of a project, it may be too late to make changes.

When a scope document has clearly outlined requirements, it’s easy to tell if the change is a defect or a change request.

Step 6: Monitor Scope

Communicate with the team, ideally in daily scrum meetings, to monitor work and ensure that everyone is working toward fulfilling requirements.

Monitoring scope looks out for signs of gold-plating, which is the addition of non-authorized “extras” added onto requirements. It also prevents scope creep by encouraging the use of correct procedures when making changes to scope.

These are the central processes to managing scope throughout a project. Many of the processes occur in the planning stage, as a clear understanding of requirements and scope from the start allows a project to run smoothly.

The Project Scope Statement

The project scope statement creates a narrative around a project. It defines what the project will produce, and how. It’s completed as a final step in the planning process, after requirements have been gathered.

The Project Management Glossary defines a project scope statement as a statement that “details what a project is meant to achieve and describes the deliverables expected. It forms the basis of measurable objectives by which the success of a project will be assessed. Project scope statements are typically part of project plans.”

The scope statement, ultimately, is for the customer. It’s important to write it in a language that all the stakeholders understand, so overly technical jargon isn’t necessary. A sign off from the client indicates that everyone is on the same page.

A scope document provides a project with several key benefits. First of all, it makes scope adjustments easier later on. Secondly, it creates a paper trail for easy reference, should any confusion arise. Finally, it provides critical input for creating the work breakdown structure, the risk management plan, and the procurement document.

Let’s look at the seven key sections of a scope statement.

1. Justification of a Project

The justification for the project clarifies the business purpose a project seeks to solve.

For example, if the project is to build an online store for a retail outlet, the justification would say how the online store aims to generate additional sales for the company, and serve as a marketing platform for its brick and mortar location.

2. Scope

This is the portion of the scope statement that needs the most care and attention.

Defining the scope means summarizing all of the characteristics, traits or functionality that need to be produced. It combines the requirements of all of the stakeholders, and additionally breaks down all the steps required in meeting each requirement.

3. Acceptance Criteria

The acceptance criteria outlines what the final product must look like. It clarifies the number of defects a final deliverable can have, and is an opportunity to provide a realistic description of what the final product is expected to do.

4. Deliverables

The deliverables section summarizes everything that’s handed onto the client, whether tangible or intangible.

It may include scope and schedule documents such as the work breakdown structure and the project schedule.

It also outlines the project deliverables. If the project is to design a website, then this section breaks down every page to be included in the site, along with its functionality.

5. Project Exclusions

This section clarifies what won’t be included in the final deliverable.
Oftentimes, stakeholders are in disagreement over the requirements to include in a project. This section of the scope document clarifies all of the agreements that stakeholders come to before executing the project.

It precludes a scenario where a team creates false expectations. Rather, it clearly states any criteria that the project won’t meet.

6. Constraints

This section outlines any key constraints in a project, most especially the budget and the timeline.

Depending on the nature of the project, it also includes any condition that might impact the completion of a project, such as weather or resource scarcity.

7. Assumptions

This section states any assumptions around the completion of a project. For example, in a construction project, an assumption may be that the team is able to obtain the permits necessary to begin the project.

These seven sections cover the central areas of a scope document. Although the document may cover your back, it’s more of an agreement than a contract. The client signs off on it to ensure that the team and client are on the same page.

Once you’ve created a successful framework for a scope document, it’s easy to use over and over again.

Three Tips to Manage Change in Projects

Although increasing scope “as a favor” isn’t really a favor at all, the compulsion to add little extras creeps up nevertheless.

The practice of gold-plating seeks to remedy deficiencies in deliverables by augmenting the project somewhere else. But ultimately this leads to a dangerous area where scope increases without any documentation. It exposes the project to unplanned risk, and increases the budget and timeline as well.

At the same time, changes will occur in every project, guaranteed. It’s even a good thing, some would argue. This is the philosophy behind the agile principle that welcomes change, even late in development. It’s not a sign that the project manager hasn’t done his or her job, or that the scope statement isn’t comprehensive.

Rather, in order to deliver on the client’s requests, project managers will almost always pivot away from the initial requirements. But these changes are clearly communicated and documented.

The decision to make changes is entirely in the realm of the client. The project manager’s job is to monitor the change to everyone’s satisfaction. To this end, here are three tips to managing change in projects.

1. Communicate With the Team

New team members may not appreciate the danger of doing small favors for the client. Keep steady ongoing daily communication with the team to ensure everyone is on track to fulfill requirements, and nothing else.

2. Ask the Five Questions

When the client comes to you with a change request, ask questions to understand the who, what, where, when and why behind the request. This clarifies the purpose of the change.

With a full understanding of the change, it’s possible to write a change order and increase the scope.

3. Have a System in Place

Many changes to scope are pretty minor. And so it’s not necessary to follow a complicated change process every time. However, every change must be documented, as it impacts other aspects of the project, including the timeline and the budget.

When you have an easy system at hand, it increases the likelihood that everyone follows the protocol around scope increase. A long process that no one understands may well mean that you’ll have some scope creep on your hands.

You won’t regret having everything documented. At any point, the client may approach with a concern about the deliverable, and this way you can point to a written statement clarifying all of the changes they requested, along with the reason.

Scope creep is like a weed. It starts out very small, but it spreads quickly and then it’s too late to stop. These steps ensure that change is managed and scope increase is documented.

The Line You Don’t Cross

As many project managers have learned the hard way, when anyone asks if you’d “just” do a little something extra for them, you Just. Say. No.

Uncontrolled scope cream benefits no one. Just like the name suggests, it can come out of nowhere, but before you know it you’re dealing with a mess.

However, scope change isn’t bad in itself. It actually occurs in almost every project. Scope management is the process of ensuring that scope is clarified accurately at the beginning, then carefully monitored through a project. It stops scope creep before it even starts.

Although scope management is one of the hardest skills for project managers, fortunately there’s several tools at hand to help. Once you discover the templates and methods that work for you, it won’t be a problem at all!