Scope Management Process

ACC Online Course Number BMGT 1040 Lesson 5: Scope Management Scope Management Process

In a previous video, we talked about the benefits of investing in the project scope management overhead. Now, let us discuss the overall scope management process in this video that comprises six processes – Plan Scope Management, Collect Requirements, Define Scope, Create WBS, Validate Scope, and Control Scope.

Being project managers, I am sure you are not surprised that we plan how we should approach each knowledge area. So in scope management, the first process has to do with how to plan scope management!
As discussed in class, using this project management framework, we have to tailor each process to the project at hand. We tailor processes by collaborating with key stakeholders and ensuring our recommendations work for them.
Officially, ‘Plan Scope Management’ is the process of creating a scope management plan that documents how the project and product scope will be defined, validated, and controlled. We document the alignment with our stakeholders on how to approach scope management in a document called Scope Management Plan. We will discuss what’s in this document in a later video.
The key inputs in this process are Project Charter and Project Management Plan (the Quality Management Plan, Project Life Cycle Description, and Development Approaches components)
The main technique is Alternatives Analysis
The key outputs are Scope Management Plan and Requirements Management Plan

One of the first things we must do after we have an approved project charter is to work with key stakeholders and understand the scope objective that the sponsor wants you to accomplish at a more granular level. The official PMI definition is ‘Collect Requirements is the process of determining, documenting stakeholder needs and requirements to meet objectives’ . The main thing to remember about this process is that the project manager is trying to understand what the stakeholders really want and need without getting it confused with the technical solutions to meet those needs.
The key inputs in this process are the Project Charter, Project Management Plan (the Scope Management Plan, Requirements Management Plan, and Stakeholder Engagement Plan components), Assumption Log, Lessons Learned Register, Stakeholder Register, Business Case, and Agreements.
The key tools and techniques are Brainstorming, Interviews, Focus Groups, Benchmarking, Document Analysis, Voting, Multicriteria Decision Analysis, Affinity Diagrams, Mind Mapping, Nominal Group Technique, Facilitation, Context Diagrams, and Prototypes. For the exam, it is important that you know the definitions of these techniques and where to use them but not much more.
The key outputs are Requirements Documentation and Requirements Traceability Matrix.
Project requirements are the stakeholders’ needs and can be either project or product requirements. Typically, trained business analysts may be the ones performing this function on a large project.
On large projects with hundreds of stakeholders, the requirements may be collected as a separate phase in the overall project lifecycle.

After understanding the stakeholders’ needs, Project Managers work with the project team members who identify the technical solution (aka product scope). The official definition is ‘Define Scope is the process of developing a detailed description of the project and product’. The main thing to know here is that the project manager should help the team focus on identifying the technical solution and not on disputing whether the stakeholders’ needs are correct. If the team feels strongly that the stakeholders’ needs are incorrect, a collaborative conversation between the stakeholders and the team can be helpful
The key inputs in this process are the Project Charter, Project Management Plan (the Scope Management Plan component), Assumption Log, Requirements Documentation, and Risk Register.
The key tools and techniques are Product Analysis, Multicriteria Decision Analysis, Alternatives Identification, Alternatives Identification, and Facilitated Workshops.
The key output is the Project Scope Statement.
The purpose of this process is to identify both the project and product deliverables of the project and the work required to create those deliverables.
In this process, you should also clearly identify what’s excluded from the scope of the project. It’s very common for stakeholders to try and press for additional work unrelated to the project objectives during the execution of the project without going through the established change control process.
Product Analysis techniques depend on the application area but include Product Breakdown, Systems Analysis, Requirements Analysis, Systems Engineering, Value Engineering, and Value Analysis. These terms are not as important on the exam.
The main deliverable of this process is the Project Scope Statement which contains a list of deliverables, project exclusions, product specifications, product acceptance criteria, project constraints, and project assumptions.
The Project Scope Statement provides a common understanding of the project scope to the stakeholders but the WBS is better suited to verify this common understanding due to its visual nature.

The WBS is one of the best kept secrets in the project management field. Even though a lot of project managers are exposed to the concept when they are preparing for the PMP, most never figure out how to create one. The trick is realizing it’s natural for us to decompose deliverables into smaller components without an intermediate step. That step can be a technique like mind-mapping that helps people think clearly first without trying to communicate the info in a structured fashion at the same time. People naturally don’t think in a structured fashion.
Officially, “Create Work Breakdown Structure (WBS) is the process of subdividing project deliverables and project work into smaller, more manageable components.”
The key inputs to this process are the Project Management Plan (the Scope Management Plan component), Project Scope Statement, and the Requirements Documentation.
The key technique is Decomposition.
The key output is the Scope Baseline (the Project Scope Statement,WBS, and the WBS Dictionary).
The WBS is one of the core concepts that is unique when one is using a project management methodology like the PMI process as opposed to not using a formalized methodology.
The work package is the lowest level of the WBS that can be delegated to an individual, team, department, or vendor.
The WBS can be developed using phases, major deliverables, or subprojects.
Remember that the WBS does not have any scheduling, resources, cost, or any other information except deliverable and project work related components.
The WBS is a great communication tool to get the key stakeholders on the same page since it’s a visual representation of all the project work and nothing but the project work.
The WBS dictionary can be created to support the WBS and it has the rest of the info including description of work, responsible organization, schedule milestones, resources, cost estimates, quality requirements, acceptance criteria, contact info, etc.
From an exam perspective, remember that the Scope Baseline is the approved version of the combined project scope statement, WBS, and WBS Dictionary.

As consumers, when we purchase a big ticket item, we expect the seller to get our signoff as a paying customer before we actually pay. Businesses are no different and this process has to do with the project manager getting the signoff and approval of the internal customer for the product scope deliverables.
The official definition is “Validate Scope is the process of formalizing acceptance of the completed project deliverables”
The key inputs to this process are the Project Management Plan (the Scope Management Plan and Requirements Management Plan components), Lessons Learned Register, Quality Reports, Requirements Documentation, Requirements Traceability Matrix, and Verified Deliverables. The verified deliverables are outputs from the Control Quality process. The rest of the inputs to this process are outputs from other planning processes.
The only technique used in this process is that of Inspection.
The key outputs of this process are Accepted deliverables and Change requests.
Many get confused with the term ‘Validate Scope’ so it’s important to understand the definition for exam purposes – it is ensuring that the project work completed by the project team is acceptable to the customer or sponsor and obtaining formal acceptance. If the customer or sponsor is unhappy with the verified deliverables and refuses to accept the deliverables, then there will be change requests to perform defect repair. These change requests are then processed through the Integrated Change Control. When you think of the Validate Scope process, think of sign off sheets and it will help you keep the definition straight on the exam.
Once the project team creates the deliverables in the Direct and Manage Project Execution process, the project team has to test it in the Perform Quality Control process, and then the customer is presented with the verified deliverables to obtain a formal signoff.
From an exam perspective, the concept could show up in unpredictable ways but the main thing to remember is the definition of the concept and that the project can’t end till the customer signs off on it.

The purpose of this process is to see whether the project is on track from a scope perspective or not. In combination with Control Schedule, Control Costs, and Monitor and Control Project Work processes, Project Managers can publish status reports with the info that’s an output of these processes.
The official definition is “Control Scope is the process of monitoring the status of the project and managing changes to the scope baseline”.
The key inputs to this process are the Project Management Plan (the Scope Management Plan, Requirements Management Plan, Change Management Plan, Configuration Management Plan, Scope Baseline, and Performance Measurement Baseline components), Lessons Learned Register, Requirements Documentation, and Requirements Traceability Matrix. Most of these inputs are from other planning processes.
The only tools in this process are Variance Analysis where the PM determines the difference between where the project was supposed to be from a scope perspective and where it actually is and Trend Analysis where the PM does something similar to assess the status of the project.
The key output of this process is Change Requests.
Uncontrolled project scope when a project manager buckles without going through the established and agreed upon integrated change control process proper change control is called ‘Scope Creep’.
Unnecessary scope changes that get introduced by the project team without going through proper change controls is called ‘Gold Plating’ and is not recommended even if the team believes that it is ‘exceeding customer expectations’. Sometimes gold plating is simply due to the project team misunderstanding the customer requirements.
Project managers must control product and project scope by evaluating work performance information relating to the scope baseline using ‘variance analysis’ or ‘trend analysis’ and process all change requests (defect repair, corrective and preventive actions) through the Integrated Change Control process.

Previous Topic

Back to Lesson

Next Topic