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 Group |
Process Number | Process Name |
Process Description |
| Planning |
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.
Filed under: Uncategorized |
Leave a comment