Scope management, or rather the lack of it, is one of the biggest reasons for project failure. Correctly defining what is and is not included in the project is absolutely foundational to good project management. I’ve seen many projects go south even though they had the right expertise, schedule, high quality deliverables, and even satisfied clients. But if the dreaded “scope creep” bug is allowed to fester and multiply, all of your other amazing project accomplishments will be as good as tossed out the window.
As a project manager, you must understand the importance of project scope.
Project scope management is the second knowledge area in the Project Management Institute’s (PMI) Project Management Body of Knowledge (PMBOK). It includes the processes that ensure all of the required work (and only the required work!) is included in the project.
According to the PMBOK, scope management has six processes:
- Plan Scope Management: Planning the process, and creating a scope management plan.
- Collect Requirements: Defining and documenting the stakeholder’s needs.
- Define Scope: Developing a detailed project scope statement.
- Create WBS: Subdividing project deliverables into smaller work units.
- Validate Scope: Formalizing the acceptance of the deliverables.
- Control Scope: The ongoing process of monitoring and managing changes to the project scope.
Plan Scope Management
Newly added into the 5th edition of the PMBOK, this planning step involves the creation of a scope management plan. This plan defines that scope of the project and how the scope will be managed and controlled.
The PMBOK describes it like this:
PMBOK, 5th Edition, Section 5.1.3.1, “Scope Management Plan”
The scope management plan is a component of the project or program management plan that describes how the scope will be defined, developed, monitored, controlled, and verified. The scope management plan is a major input into the Develop Project Management Plan process, and the other scope management processes. The components of a Scope Management Plan include:
- Process for preparing a detailed project scope statement;
- Process that enables the creation of the WBS from the detailed project scope statement;
- Process that establishes how the WBS will be maintained and approved;
- Process that specifies how formal acceptance of the completed project deliverables will be obtained; and
- Process to control how requests for changes to the detailed project scope statement will be processed. This process is directly linked to the Perform Integrated Change Contol process (Section 4.5)
The scope management plan can be formal or informal, broadly framed or highly detailed, based on the needs of the project.
The inputs, tools and techniques, and outputs of the process are as follows:
Collect Requirements
Most projects have a long list of requirements. In the construction field there are usually hundreds of building codes, environmental regulations, design manuals, and the like. And in the I.T. and internet fields the requirements are often not even well defined at the project outset which has resulted in the popularity of iterative project management methods like scrum and agile.
The success of any project is directly related to the accurate definition and documentation of stakeholder needs. Thus, requirements become the foundation of the Work Breakdown Structure (WBS) in a future step (below).
Define Scope
At this second step, the requirements are compiled into a scope statement. An example of a scope statement might be:
The inputs, tools and techniques, and outputs of this process are:
Create WBS
In this section, a detailed work breakdown structure is created, which is a break down of the deliverables into smaller, more manageable work packages. A WBS can take numerous forms, such as division by phases, deliverables, or subprojects. But regardless of how you structure it, the WBS should contain the man-hours, equipment, tools, contractor expenses, and any other item of cost. The WBS is not about the cost; Pricing and cost control are part of the Project Cost Management knowledge area. But the realization of cost helps to ensure you identify every part of a work package.
Validate Scope
Formalizing of the project deliverables is a task unto itself. In my engineering company, we sometimes give clients a scope statement and ask them to give verbal approval, particularly if it contains many non-standard things (i.e. not just another bridge). Other stakeholders, like landowners around a new development, are given scope statements which may or may not require acceptance depending on the circumstances and stage of the project.
Control Scope
Project scope must not only be well defined, but well controlled. Like I said above, “scope creep” trips up many projects and I’ve seen some ugly outcomes. Any changes in stakeholder expectations or requirements during the project’s execution must be integrated into a new scope statement and work breakdown structure. The associated cost, time, and resource changes must be itemized and managed.
Do you have anything to add? I’d love to hear your comments about scope management in the comments section below.
