5th Edition PMBOK® Guide—Chapter 5: Scope Management Knowledge Area Processes

In the last post, I gave a general introduction to Chapter 5 of the PMBOK® Guide, the Scope Management knowledge area.

This post contains is a summary of the six project management processes that are in the Scope Management knowledge area.

1. Scope Management Knowledge Area—Six Processes

You will notice that the Scope Management Knowledge area, as well as the following two knowledge areas of Time and Cost, only have processes in either the Planning Process Group or the Monitoring & Controlling Process Group. In particular, the Scope Management Knowledge Area has four processes in the Planning Process Group, and two processes in the Monitoring & Controlling Process Group.



Process Number Process
Process Description
5.1 Plan Scope Management The process of creating a scope management plan that documents how a project scope will be defined, validated and controlled.
5.2 Collect Requirements The process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives.
5.3 Define Scope The process of developing a detailed description of the project and product.
5.4 Create WBS The product of subdividing project deliverables and project work into smaller, more manageable components.
Monitoring & Controlling 5.5 Validate Scope The process for formalizing acceptance of the completed project deliverables.
5.6 Control Scope The process of monitoring the status of the project and product scope and managing changes to the scope baseline.

Let’s take a closer look at the process descriptions.

5.1 Plan Scope Management

This is a new process in the 5th Edition of the PMBOK® Guide. This is not to say that the scope management plan was never done before, it’s just that the process of creating that plan was considered part of the larger generic process 4.2 Develop Project Management Plan. Now, however, EACH of the knowledge areas has its own process that is dedicated to planning.

In the case of the Scope Management Plan, the plan gives details on how the project scope will be defined (processes 5.2 through 5.4), validated (process 5.5) and controlled (process 5.6). It therefore charts how the organization will chart its way through the rest of the scope-related processes.

5.2 Collect Requirements

This takes the high-level needs and expectations of the sponsor, customer, and other stakeholders outlined in the project charter and translates them into detailed set of requirements that can be analyzed for possible inclusion in the scope baseline.

5.3 Define Scope

This is the detailed description of the project and product, which includes which of the requirements collected in the previous process will be included in the scope and which will be excluded. The output of this process is the Project Scope Statement, one of the three components of the scope baseline.

5.4 Create WBS

This is the process of subdividing the project deliverables and project work into smaller, more manageable components called work packages. The output of this process is the work breakdown structure or WBS, and the WBS dictionary, which contains detailed information about the contents of the work packages. The WBS and WBS dictionary are the other two components of the scope baseline besides the Project Scope Statement.

5.5 Validate Scope

The interim deliverables are formally accepted by the customer or sponsor as a way of making sure that everybody is on the “same page” when it comes to the project progressing along the lines of the performance baseline, which in the case of the scope management knowledge area means the scope baseline in particular.

The deliverables are internally verified to make sure they meet the requirements (as part of the Control Quality process), and then the Validate Scope process makes sure they are either externally validated by the customer or, in the case of a purely internal project, with the sponsor of the project.

5.6. Control Scope

Control Scope is the process in the Monitoring and Controlling Process group which attempts to maintain the project within the scope baseline if possible. If it is not possible and the scope must be changed, then the process may generate as an output a change request which may (if approved) lead to a changed scope baseline.

This is a basic outline of these processes. Tomorrow I will go through the inputs, tools & techniques, and outputs of the first process, 5.1 Plan Scope Management.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: