4squareviews

1.   Introduction

In the last post, I discussed the processes in the Integration Knowledge Area, which is covered in Chapter 4 of the 5th Edition PMBOK® Guide.   In this post, I will discuss the processes in the Scope Knowledge Area, which is covered in Chapter 5.

Here are the 47 processes of project management; the chart indicates how many are in each knowledge area and process group.

		Initiating	Planning	Executing	Monitoring & Controlling	Closing
Integration	6	1	1	1	2	1
Scope	6		4		2
Time	7		6		1
Cost	4		3		1
Quality	3		1	1	1
Human Resources	4		1	3
Communications	3		1	1	1
Risk	6		5		1
Procurements	4		1	1	1	1
Stakeholder	4	1	1	1	1
	47	2	24	8	11	2

2.  Scope Management knowledge area

Let’s take the Scope Management Processes first.

Here’s the portion of the above matrix of 47 processes that lists the processes in the Integration Management knowledge area, which is chapter 4 of the PMBOK® Guide.

Knowledge Area	Total # of Processes	Initiating	Planning	Executing	Monitoring & Controlling	Closing
Scope	6		4		2

Here’s a description of the six processes that are included in the Scope Knowledge Area.

Process Group	Process Number	Process Name	Process Description
Planning	5.1.	Plan Scope Management	Creates a Scope Management Plan that documents how the project scope will be defined, validated, and controlled.
	5.2	Collect Requirements	Defines and documents stakeholders’ needs to meet the project objectives.
	5.3	Define Scope	Developing a detailed description of the project and product.
	5.4	Create WBS	Subdivides project deliverables and project work into smaller, more manageable components.
Monitoring & Controlling	5.5	Verify Scope	Formalizing acceptance of the project deliverables with the customer.
	5.6	Control Scope	Monitoring status of the project and product scope and managing changes to the scope baseline.

Let’s take a closer look at the process descriptions.    Recall that the first four processes are in the planning process group and the last two are in the monitoring & controlling process group.

5.1  Plan Scope Management

The first planning process for ALL of the knowledge areas is going to be in the form Plan X Management, where X is the name of the knowledge area.   The object of this planning process is to produce the planning document for that knowledge area, which is going to be called X Management Plan, again where X is the name of the knowledge area.    In this case, with Scope being the relevant knowledge area, the name of the first planning process is Plan Scope Management.

The main output of the process, the Scope Management Plan, is a guideline or blueprint if you will for all of the other processes, whether they are in the planning group or the monitoring & controlling process group.    The other output of the process, another subsidiary plan called the Requirements Management Plan, is what is going to be filled in during the next process, 5.2 Collect Requirements.

5.2 Collect Requirements

This is the first time the scope is broken down from the high-level requirements that are included in the project charter (the output of process 4.1 Develop Project Charter) into more detailed requirements.    This process coordinates with the knowledge area of Stakeholder Management, because the detailed requirements are going to come from the various stakeholders.

The main question answered by this process:    What do the stakeholders want from the project?

This is like asking somebody who wants to go on a trip the kind of place they want to go to.    What are their requirements for their trip?

5.3 Define Scope

The purpose of this process is to create the project scope statement, which further defines the scope from the requirements that are the output of the previous process and turns it into a list of objectives, major deliverables, and a list of assumptions and constraints that give an idea of the potential risks to the project and what is consciously excluded from the project.

Main question answered by this process:     How do you get the project done?

Using the previous analogy of somebody going on a trip, once you know their requirements for their trip, you then pick a specific destination which fits those requirements.

5.4 Create WBS

The previous process of “Define Scope” gives the final objectives or major deliverables of the project, but this process breaks things down all the way to the level of specific deliverables, in something called the Work Breakdown Structure or WBS.

The output of this process is the “scope baseline” which consists of three things:   a) the project scope statement (the output of the last process), b) the WBS (mentioned above), which indicates the work that has to be done, and c) the WBS dictionary, which gives details about the work to be done (where, who, etc.).

Main question answered by this process:   What are the specific steps you will need to do in order to get the project done?

Extending the previous analogy of somebody going on a trip, once you know the destination, your GPS system (analogous to the WBS of your project) will give you the specific directions like “go straight 2.0 miles”, “turn left here”, etc. that, if followed, will get you to your destination.

All three of the above processes are part of planning, but they go from general to specific in terms of the level of detail.   Now let’s discuss the two processes in the Monitoring & Control group.

5.5 Validate Scope

Validating the scope means taking completed project deliverables and asking the customer or sponsor to give their formal acceptance of them to make sure that they conforms to their expectations.

NOTE:   This used to be called “verify” scope in the 4th edition; but it still refers to the same process of gaining formal acceptance.    Also, the final, formal acceptance of the project is not done here, but in the 4.6 Close Project or Phase process.

5.6 Control Scope

Control scope means to monitor the status of the project and product scope to see whether the project is proceeding according to plan.   What happens if the scope is deviating from what was in the plan?  Then changes are suggested to either a) have the project conform to the original plan or, if the original plan is judged to be unrealistic to b) have the plan adjusted accordingly.

In both of these processes, the actual scope is being compared with some standard; in the case of Validate Scope it is being compared with the customer’s expectations, and in the case of Control Scope it is being compared with the scope baseline.

The next post deals with the Time Knowledge Area.

Filed under: Uncategorized |