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 the other amazing project accomplishments will be as good as tossed out the window.
Therefore, 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.
In 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
This planning step involves the creation of a scope management plan, which defines the scope of the project and how it will be managed and controlled.
The PMBOK describes it like this:
PMBOK, 6th Edition, Section 22.214.171.124, “Scope Management Plan”
The scope management plan is a component of the project management plan that describes how the scope will be defined, developed, monitored, controlled, and validated. The components of a Scope Management Plan include:
- Process for preparing a project scope statement;
- Process that enables the creation of the WBS from the detailed project scope statement;
- Process that establishes how the scope baseline will be approved and maintained; and
- Process that specifies how formal acceptance of the completed project deliverables will be obtained.
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:
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 space the requirements are often not even well defined at the project outset which has resulted in the popularity of iterative project management methods like agile.
The success of any project is directly related to the accurate definition and documentation of stakeholder needs.
At this 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:
In this section, a detailed work breakdown structure (WBS) is created. The WBS is defined as the subdivision of the work 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. Although the WBS is not about the cost (Pricing and cost control are part of the Project Cost Management knowledge area), the realization of cost helps to ensure you identify every part of a work package.
Formalizing 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.
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 ones. Any changes in stakeholder expectations or requirements during the project’s execution phase 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.