Project Scope Management according to the PMBOK

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:

1. Plan Scope Management: Planning the process, and creating a scope management plan.
2. Collect Requirements: Defining and documenting the stakeholder’s needs.
3. Define Scope: Developing a detailed project scope statement.
4. Create WBS: Subdividing project deliverables into smaller work units.
5. Validate Scope: Formalizing the acceptance of the deliverables.
6. 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.

Inputs

• Project management plan
• Project charter
• Enterprise environmental factors
• Organizational process assets

Tools & Techniques

• Expert judgment
• Meetings

Outputs

• Scope management plan
• Requirements management plan

Collect Requirements

The success of any project is directly related to the accurate definition and documentation of stakeholder needs. Requirements become the foundation of the Work Breakdown Structure (WBS) in a future step.

Inputs

• Scope management plan
• Requirements management plan
• Stakeholder management plan
• Project charter
• Stakeholder register

Tools & Techniques

• Interviews
• Focus groups
• Facilitated workshops
• Group creativity techniques
• Group decision-making techniques
• Questionnaires and surveys
• Observations
• Prototypes
• Benchmarking
• Context diagrams
• Document analysis

Outputs

• Requirements documentation
• Requirements traceability matrix

Define Scope

At this second step, the requirements are compiled into a scope statement. An example of a scope statement might be:

Inputs

• Scope management plan
• Project charter
• Requirements documentation
• Organizational process assets

Tools & Techniques

• Expert judgment
• Product analysis
• Alternatives generation
• Facilitated workshops

Outputs

• Project scope statement
• Project documents updates

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.

Inputs

• Scope management plan
• Project scope statement
• Requirements documentation
• Enterprise environmental factors
• Organization process assets

Tools & Techniques

• Decomposition
• Expert judgment

Outputs

• Scope baseline
• Project document updates

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.

Inputs

• Project management plan
• Requirements documentation
• Requirements traceability matrix
• Validated deliverables
• Work performance data

Tools & Techniques

• Inspection
• Group decision-making techniques

Outputs

• Accepted deliverables
• Change requests
• Work performance information
• Project document updates

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.

Inputs

• Project management plan
• Requirements documentation
• Requirements traceability matrix
• Work performance data
• Organization process assets

Tools & Techniques

• Variance analysis

Outputs

• Work performance information
• Change requests
• Project management plan updates
• Project documents updates
• Organizational process assets updates

Do you have anything to add?  I’d love to hear your comments about scope management in the comments section below.

Related posts:

Project Scope Management according to the PMBOK How to Control Project Scope Create a Scope Management Plan The PMBOK’s Project Scope Management Knowledge Area 9 Parts of a Scope Management Plan Components of a Scope Management Plan