PMP Scope Management Knowledge Area Cheat Sheet
A WIZARD WAY TO PASS YOUR PMP EXAM!
Dave Litten PMP Trainer
Become PMP Certified
The term ‘scope’ can trip you up and needs careful definition.
It may refer to the scope of the entire project or just the scope of the project’s product.
The product scope is everything that must be completed in order to meet product requirements, whereas the project scope includes everything in the entire project plan.
As an example here at some point during the project you made document lessons learned, and this would be considered part of the project scope. The reason is that although it does not really have anything to do with producing the product, the lessons learned might be helpful for future projects.
Scope management as a topic within the PMP exam is not a particularly difficult area to master, and it certainly pays big dividends within your exam itself. Scope management is more intuitive than other PMP exam areas, and there are no complex formulas to memorize and no particular difficult theories.
Scope management is a logical group of process is to help you understand requirements, define those requirements, breakdown and control the scope of the project, and finally verify that the product was completed correctly.
The scope management approach
This approach can be summarized as the following two elements:The project manager should always be in control of the scope by carefully defining it and carefully managing the processes
Changes to the scope should be handled in a structured and controlled wayThe best approach is to start with the end goal so that each requirement and its acceptance criteria is accurately documented.
Good scope management ensures that the scope is well defined and clearly communicated so that the project is carefully managed to limit unnecessary changes. This of course would need a different philosophy for when managing agile projects.
The work is closely monitored so that when change does happen on the project, it is detected, evaluated, and documented.
Project managers should work pro-actively to identify and influence the factors that cause change.
When we refer to the project ‘scope’ we are referring to the work needed to successfully complete the project and only that work. A project manager should take care to ensure that customer expectations are exceeded, as this increases risk and uncertainty while adding potential problems into the project.
PMP Scope Management Process
The key PMP Exam knowledge areas of scope management contains the following elements:Planning the overall scope related effortsGathering requirements for the product and the projectDefining and documenting the deliverables that are part of the product and the project (this is the scope itself)Creating the work breakdown structure (WBS) and baseline in the scope
Checking the work being done against the scope to ensure it is both complete and correctMaking sure that all of what is ‘in scope’ and only what is ‘in scope’, is completed and the changes are properly managedThe 6 PMP Scope Management Knowledge Area processes
There are six process is in the scope management knowledge area and these are, Plan Scope Management, Collect Requirements, Define Scope, Create WBS, Validate Scope, and Control Scope.
In the knowledge area of scope management, it is essential that you know the main outputs that accompany each process. The different key outputs that are creative within each process are summarized in the diagram below.
The following is a helpful diagram that states the main six process is within this knowledge area and the key outputs for each of them.
I will now give you a brief overview of what each process is there to do.
Plan scope management
This is the first of the six scope management processes, and defines the approach or strategy of how the remaining five scope processes will be carried out.
You will note that the project charter is one of the inputs to this process and for that reason plan scope management will have a significant impact on the success of the project because of the requirements defined within the project charter.
These requirements are the main source of understanding and managing stakeholder expectations, project schedule, budget, quality specifications, risk factors, and resource planning – all of those will try back to the work that is done within this process.
Another important input here are the enterprise environmental factors and organizational process assets as these will have a bearing of how scope is managed for this specific project.There are two main outputs from this process – the scope management plan and the requirements management plan.
The former is the approach or strategy I mentioned above, defines what activities the team will perform in order to gather and manage the project requirements. Please note that this plan defines what activities the team will perform together and manage the project requirements and does not contain the requirements themselves.
The requirements management plan shows how the requirements will be covered, how decisions we made, how changes to the requirements will be handled, and how the requirements will be documented.
The PMP Collect requirements process
This process describes what is needed to satisfy the stakeholders and then documents that understanding. As before, this includes both the scope of the product and the scope of the entire project.
It is vital that a common understanding of the project is gathered here as it will aid the success of the project while giving the project manager a great tool to set and manage stakeholder expectations. As before, schedule, budget, quality specifications, risk factors, and resource planning will all tie back to these requirements
This process takes place early in the project because of the impact that requirements will have on the rest of the project. On an agile project this process may repeat iteratively throughout much of the project.
It is important that requirements must be gathered and accurately documented before any project execution takes place.
You will probably have noted that the two processes Develop Project Charter and Indentify Stakeholders within the initiating process group, must be performed first before it is possible to complete the collect requirements process
The scope management plan and requirements management plan as well as the project charter are three of the main inputs to this process. There are two main outputs here, the requirements documentation and the requirements traceability matrix.
There are many tools here, mostly used by individuals, teams, or focus groups.
In summary there are four steps:Data gatheringData analysisData representationDecision making
The PMP Define Scope process
The scope of the project is what drives the execution of the project, and define scope is the process for the project requirements are more thoroughly understood and documented. The key driver here is that every successful project must develop a clear understanding of the requirements to be executed, verified, and delivered.
The Define Scope process should be started as soon as the collect requirements process has been completed, although as well as the requirements, evolution of the project scope is generally progressively elaborated.
The project manager will refine the requirements that were collected earlier in the project by performing additional analysis, factoring in any approved changes, and adding detail.
The project scope statement is the main output of this process, contains detailed information about the project scope and the requirements.
There are three main inputs for the define scope process and these are:
The project charter since this will contain a high level view of the scope
The scope management plan because it describes how the scope activities will be managed including this processThe requirements documentation since it defines what the project has to do and the degree to which it must perform
There are two categories of tools used here, data analysis which outlawed the different ways of achieving the goals, and product analysis.
Product analysis is a detailed analysis of the project’s product, service, or result, with the objective of improving the project teams understanding of the product and helping to capture that understanding in the form of requirements. There are many tools and techniques that could be used here such as product breakdown structures and systems analysis
The project scope statement
This is the only output of this process and its forms a scope baseline agreed by the project stakeholders. Typical contents here consists of the following sections:
Product scope description – a text description of the scopeDeliverables – including a clear and measurable description of what the product is going to look and feel like
Acceptance criteria – a checklist of the tests and measurements that will be performed before in the product is accepted
Project exclusions – this is where you document what is outside the scope of the project.
This can be important because it encourages all stakeholders to agree what is within scope and what is not.
The PMP Create WBS process
Interestingly, the WBS is not listed as one of the outputs of this process. The reason is that although it is created, it is combined with two other documents to create the scope baseline. Please note that while the main product of this process is the work breakdown structure, the main output will be the scope baseline.
The WBS is vital for the project and for the PMP exam, since the WBS becomes a hub of information for the project and is probably the most important element of the project plan. Project risks, activities, cost, quality attributes, and procurement decisions all link back to the WBS, as it is the primary tool for verifying and controlling the project scope.
This process is performed off for the define scope process has created the project scope statement.
The scope management plan, and project scope statement, and requirements documentation of the main inputs to this process.
The Decomposition Tool
The WBS is a hierarchical diagram with higher levels showing project deliverables or products, and the lower levels broken down to work package level.
A work package may have one or more people working on it and each work package will have a deliverable such as a document, a decision or a product.
This is the single tool that is used within this process, as it involves breaking down the project deliverables into progressively smaller components.
To ensure that decomposition has occurred down to the appropriate level of detail, there are three main questions that need to be asked:
Are your work package is small enough to be estimated for time and costIs the project manager and the project team satisfied that the current level of detail provides enough information to precede identifying subsequent project activitiesIs each work package small enough to be able to be assigned to a single person or group that can be responsible for the resultsIt is worth mentioning here are some projects including most agile projects, use a rolling wave technique to decompose requirements.
In this case, decomposition may not be performed all at once, rather, some of the WBS may be created followed by that work being carried out, before more of the WBS is decomposed.
In summary, these activities of progressive elaboration, repeat like rolling waves.
Now let me summarize the outputs of this process:Scope baseline. By definition, a baseline at a point in time, will consist of the original plan plus all approved changes.
At this point, the scope baseline represents the combination of the project scope statement, the WBS, the WBS dictionary, work package, and planning package.
Once the scope baseline has been created it is placed under control, meaning that changes to the scope are made according to the scope management plan.
The WBS
The guidance here is that the work breakdown structure should be based on the project deliverables rather than the tasks needed to create those deliverables and that it will be built (or decomposed) from the top down.
The resulting WBS is a graphical, hierarchical chart, logically organized from top to bottom. Each node on the WBS has the unique number which is used to locate and identify that node
The WBS Dictionary
This is a document detailing the contents of the WBS by providing detailed information about the nodes on a WBS.
The reason for this dictionary is a practical one. Since the WBS is a diagram, there is a limit to how much information can be described for each node. The WBS Dictionary provides the solution by capturing additional attributes about each work package in this document as it does not have the graphical space constraints that the WBS diagram does.
For each node on the WBS, the dictionary might include the number of the node, the name of the node, the rich and requirements for the node, to whom the node is assigned, and include time, cost, and account information.
The PMP Validate Scope process
Validate scope is the process of ensuring that the product, service, or result of the project matches the documented scope. Validate scope is easily confused with other processes, thinking that this process involves verifying that the scope is documented accurately. This is NOT its purpose.
The validate scope process compares the product that is being created with the scope to ensure that both match.
One of the confusing aspects mentioned above is that the validate scope has some similarities to the process of control quality (a process within the quality management knowledge area).
The reason being is that both of these process is inspect the product against the scope, however there are key differences between them that you need to be clear about: Control quality is performed before validate scope
Validate scope is mainly concerned with completeness, while control quality is mainly concerned with correctnessValidate scope process of gaining acceptance of the product by the project manager, the sponsor, the customer, and others
Control quality is concerned with adherence to the quality specification
After the validate scope process has been completed, the product is accepted by the project manager, the customer, the sponsor, and sometimes by functional managers and other key stakeholders. This outcome forms a significant milestone within the project life.
Because of the definition of validate scope this process can only be performed off to some of the product components have been delivered.
Depending on the nature and approach or methods of the project, validate scope may be performed several times throughout the life of the project. Nevertheless, validate scope will be performed one final time as the project nears completion by gaining acceptance of the project end product.
There are two main inputs here- verified deliverables and work performance data
Verified deliverables
These flow out of the control quality process that I mentioned earlier and into this one. Validate scope compares the deliverables with the documented scope to ensure that everything has been completed, and as I mentioned above this may be performed several times during a project.
Work performance data
Occasionally, a product can be developed to achieve the right outcome, but the manner or approach to get their was unacceptable. An example here might be the use of unacceptable levels of overtime or low team morale. For these reasons, work performance data describes how the deliverables were created, which will help in managing the project from this point forward.The main tool here is inspection. Inspection is normally a point by point review of the scope along with the associated deliverable.
In some instances inspection could be user acceptance testing for a software product. In any situation, the objective here is to make sure the deliverables match the documented scope.There are many approaches used to carry out inspection, it may be done by measuring, examining, testing, validating, reviewing, or auditing
There are two main outputs of the validate scope process:
Accepted deliverables
Probably one of the most important and significant within the project! Acceptance of the deliverables is the primary output here and is typically performed by the project manager, the sponsor, the customer, and the functional managers, and consists of a formal written acceptance by the appropriate stakeholders
Work performance information
Don’t get confused, work performance data flows into this process which is then refined and converted into work performance information. Work performance information details how something was created, including whether it was on time, within budget, how resources were used compared with estimates, and other metrics of interest. A simple comparison here might be that work performance data consists of the hours an individual worked within a particular week, whereas work performance information would put that into context such as percentage complete, actual hours worked and hours remaining.
The PMP Control Scope process
This process maintains control of the project by preventing scope change requests from overwhelming the project one at the same time ensuring the scope change requests are properly handled. The outcome here is that the scope baseline is always kept current.One of the biggest killers of failed projects is dreaded ‘scope creep’, and this process ensures that all change requests are processed, and also that any of the underlying causes of scope change requests are understood and managed. It is key here that not only scope change requests are managed, but also unnecessary change requests are prevented.
Control scope is used immediately after the scope baseline is created. Control scope is used whenever the work results are different from the documented scope whether or not that scope change was requested in advance.
For this reason, the project manager should continually utilize the control scope process.
There are three main inputs here, the scope management plan, the scope baseline (which consists of the WBS, the WBS dictionary and the project scope statement), and work performance dataWork performance data. This input provides information on all aspects of the work completed as it relates to the project plan. An example here might be the volume of change requests flowing into the project. Notice here how this raw work performance data is refined into one of the outputs that of work performance information.
The main tool here is data analysisData analysis is a very broad phrase but in this case we are interested in variance analysis and trend analysis.
Variance analysis measures differences between what was defined in the scope baseline and what was created in order to investigate the root causes behind any differences.
Trend analysis helps identify areas that may turn into problems.
Apart from keep in the sections of the project management plan updated, there are two main outputs in the control scope process:
Work performance information. As mentioned earlier WPI is work performance data that has been processed and put into an actionable formatChange requests, as changes are made to the scope baseline, these must be factored into updates to the WBS.
If such a challenge represents a new piece of scope, the work must first be decomposed in the WBS down to work package level and then brought into the other appropriate processes.
Finally a quick word about the use of agile on scope management
The six process is I have covered here would be handled very differently on projects that use agile or other adaptive methodologies.
Typically such projects would use short ‘iterations’ to prioritize the next sets of features to be developed. These are called backlogs within agile and consist of important features that I’ve been prioritized in terms of their importance and delivery. This prioritizes a shun is dictated by what would give the stakeholders the highest value, and such stakeholders are very closely involved with the agile project throughout his life.
Rather than use the word requirements, agile projects capture usability scenarios known as user stories, and an important difference here is that agile projects do not try to define and all of the requirements and functionality from the start of the project, but rather by a series of iterations allow it to involve and defined in detail for the project life.
