9 Parts of a Scope Management Plan

Scope issues are the #1 reason for project failure. Today more than ever, it’s imperative that all projects need a scope management plan. Scope management refers to the process of identifying and controlling the total resources that are involved in a project.

It is important that scope be defined exactly. Too little, and you will have to answer to the stakeholders. But too much, and you will meet the wrath of your bosses.

A good scope management plan will have the following sections:

1. Requirements
2. Stakeholders
3. Scope Statement
4. Work Breakdown Structure (WBS)
5. WBS Dictionary
6. Roles and Responsibilities
7. Deliverables
8. Sponsor Acceptance
9. Scope Control

Requirements

A proper scope identification process will allow for a requirements identification step. This is where you contact the stakeholders, meet with them if necessary, and identify and prioritize all of the external requirements the project must meet. Make sure you don’t miss anything. I run an engineering company and I’ve seen things missed all the time that seem obvious after they come to light, but are not so obvious at the outset.

The Project Management Body of Knowledge (PMBOK) includes the creation of a Requirements Traceability Matrix. Essentially, it is a tracking chart whereby the requirements from various stakeholders are given a sign-off at different stages throughout the project life cycle. For example, a land owner near a new road site is informed of the project at the conception stage, once the options under consideration have been tabled, and finally at the finished design stage. The matrix ensures the project team get the land owners sign off at each stage.

Scope Statement

Every project needs a scope statement. This is not negotiable. If you can’t put the scope of the project in writing, you shouldn’t have a project. Sometimes the scope is destined to change, but you must be able to identify it at any point in time. Here’s an example of a scope statement:

The scope statement is an important part of the project management plan.

Work Breakdown Structure

Called WBS for short, the work breakdown structure itemizes each individual work item that make up the project. Each resource should be included, particularly man-hours, equipment, tools, and contractor costs.

It can be graphical or tabular, and can be structured in various ways:

1. Project phases
2. Project deliverables
3. Subprojects

The WBS is an integral part of the project schedule and cost, thus care should be taken in developing it.

WBS Dictionary

In PMBOK terms, a WBS Dictionary supports the Work Breakdown Structure.  It itemizes the following things for each work item:

1. Identification number/code
2. Description of work
3. Responsible organization or individual

This is the minimum amount of information. Other items might include start date, deadline, budget, client, milestone, or other resources required in carrying out the work item.

Roles and Responsibilities

Each part of the scope should be connected to the task lead, be it a manager, technical expert, junior technologist, or any other person on the project team. For example, design might be the responsibility of the design engineer, and drafting the responsibility of the draftspersion, and so forth.

Although all roles and responsibilities should generally by known at the project outset, responsibilities can change throughout the project, particularly if the project scope changes (What? Scope change? Never!) I can accept that there are times when planning does not allow every role and responsibility to be expressely defined at the project outset, and this is okay but the project managers should make sure that enough planning has gone into the roles and responsibilities at any given time throughout the project.

Deliverables

In the engineering industry where I come from, I don’t think I’ve ever seen a project without a physical deliverable such as a report, tender, design, or physical building. I can imagine projects where the project outcome is the improvement of a process, or a redesigned product, but clearly there wouldn’t be a project if there wasn’t deliverables. All deliverables should be identified as part of the scope. All of the other project activities revolve around the production of the deliverables.

Stakeholder Acceptance

In the PMBOK, acceptance of the deliverables is a centralized part of the scope definition process. Deliverables should be identified and the work breakdown structure itemized, but the process isn’t done until the receiver of the deliverable (project sponsor, client, etc.) has seen what they will get and approved it. Now I don’t mean receive the deliverable, I mean approve what the deliverable will look like before the work to produce it takes place.

In the case of a land development, the surrounding landowners are major stakeholders. They normally receive a scope statement at the outset of the project, which merely indicates that the developer wants to develop the land. Second, they get another deliverable stating the options under consideration, and finally, the finished design. At each step of the process, their input is received.

It’s a common occurrence that an owner wants something, let’s say a new bridge, and in their mind everything involved in a new bridge is included in the project. Yet the consultant who manages the project deals with many variables that are unknown and/or changing, and thinks in terms of all the things which pop up which they couldn’t anticipate in the original project inception. Let’s say a concrete plant has a malfunction and several components need to be returned, increasing the consultant’s inspection time.  In the owner’s mind, it’s all part of building a bridge, but in the project manager’s mind, it’s outside the scope.

Scope acceptance documents should be included in the scope management plan.

Scope Control

Identifying the scope to a minute precision is a noble activity and worthy of the utmost of a project manager’s respect, but unless there is a scope control process in place there could still be storm clouds on the horizon. Scope creep is a toxic parasite that will eat your project, and career, alive. It refers to that slow change in the project scope that nobody really talks about because nobody wants to deal with the addition of small, minor things that certain stakeholders want to sneak in.

Procedures should be in place to inspect and examine the scope of the project at regular intervals, and important milestones. Also, since most projects have some sort of scope change during their life span, procedures should be in place to allow for efficient change management and communication.

Related posts:

Create a Scope Management Plan Project Charter vs. Scope Statement Components of a Scope Management Plan Project Scope Management according to the PMBOK Project Scope Management according to the PMBOK 10 Parts of a Communications Management Plan