Project Scope Management

Knowledge Area Executive Summary

This Knowledge Area about the final product, service, or result from the project.  Specifically, it is all about setting the processes in place so that all of the work needed to create the final product, service, or result and ONLY the work needed to create the final product, service is included in the project.  This is includes deciding what is and what is not included in the project.  This is performed from two separate perspectives; Project Scope and Project Scope.

• Process Groups covered by Scope Management:
  • Planning
  • Monitoring and Controlling
• Processes that make up this Knowledge Area
  • Plan Scope Management
  • Collect Requirements
  • Define Scope
  • Create Work Breakdown Structure (WBS)
  • Validate Scope
  • Control Scope
• Major or important ITTOs
  • Project Charter
  • Project Documents
  • Agreements
  • Business Documents
  • Verified Deliverables
  • Work Performance Data
  • Data Gathering
  • Data Analysis
  • Inspections
  • Decomposition
  • Product Analysis
  • Decision Making
  • Data Representation
  • Scope Management Plan
  • Requirements Management Plan
  • Requirements Documentation
  • Requirements Traceability Matrix
  • Project Scope Statement
  • Scope Baseline
  • Accepted Deliverables
  • Change Requests
  • Work Performance Information
• Critical concepts

Scope Management is an extremely crucial Knowledge Area.  So much in fact, that it is included in the “Triple Constraint Model” from the Project Management Institute (PMI^®).  It is relevant whether discussing Predictive Lifecycle projects or Adaptive Lifecycle projects.  Each handles scope and the collection of requirements slightly differently, but both use every process from Scope Management to generate a comprehensive plan for the work that must be accomplished on the project.  Predictive Lifecycle projects generally perform all of the Planning processes early in the project and perform the Execution and Monitoring and Controlling processes periodically as needed.  Adaptive Lifecycle projects perform the Planning processes during each iteration or “sprint.”

Since we know that all the processes are needed, let’s start working on the Scope Planning…

As with every Knowledge Area, we need a plan to guide us in our actions as we deal with scope and changes to scope throughout the project.  This starts us with the Plan Scope Management process.  After reviewing the Project Charter and any other already-developed portions of the PM Plan, we can get an idea of the type of project we are going to undertake, how we will need to manage the scope of the product and the project, as well was how we will collect requirements and determine what will and will not be included in the project.  We will use all of this information to guide us in the creation of the Scope Management Plan and the Requirements Management Plan.  It is important to realize that these are separate documents with separate purposes.  By their name alone, we can essentially figure out what each is going to do for us.  The Scope Management Plan will be the overarching document that will set the rules and foundation for how we will deal with scope items on the project, where the Requirements Management Plan, will be the overarching document that will set the rules and foundation for how we will collect, prioritize, and determine which requirements will be included in the project and product scope.

Now that we know how we are going to collect, prioritize, and determine which requirements will be included, let’s start that evolution with the next process, Collect Requirements.  In this process, we will gather ALL of the requirements from our stakeholders (whether they will be included in the project or not – because some might not be…).  This can be performed in many ways, from data gathering tools like interviews and brainstorming sessions to document analysis to glean requirements.  Outputs here include the Requirements Documentation, which is a wish list for the project requirements, and the Requirements Traceability Matrix (RTM), which is what we will use to track the life of all of our requirements throughout their life.  The RTM will include a large amount of information that may not be available in the early scope planning processes, but will be refined as we move through them.

So to this point, we’ve collected absolutely everything that our stakeholders want included in our project.  It would be an overwhelming task to try and include all of them into the project, so we need to filter them down to what we will actually be performing in the project.  We do this by taking a look at the Project Charter and filter the collected requirements against the constraints of the project that we see there.  In some cases, the only constraints we may have to filter against are how much money and time we have to get everything accomplished.  Once we have determined what will be included in the project, we can create on of our outputs, the Project Scope Statement.  This will show what will be included in the project, how we will do it, and any acceptance criteria needed.  Oftentimes, we will also include specifically what will not be included in the project.  We will also take this opportunity to update the RTM with any new information from this process.

Now, we need to determine the real “how” and “what” of the project by creating the Work Breakdown Structure (WBS).  Here, we will gather the experts and decompose the work needed (requirements) into deliverables and sub-deliverables so that we know what will need to be created.  This is “THING-based” and should be progressively decomposed only as far as the project team needs to understand the things that need to be created, not the work that will be undertaken to create those things.  As we create the WBS, we will also create a companion document, called the WBS Dictionary, that will be used to provide amplifying information on the individual work packages as we receive new information.  The Scope Statement, WBS, and WBS Dictionary are combined together to become the Scope Baseline, which is one of the baselines used to measure project performance.

And that’s it for Scope Planning… Seems simple, right?  Well in all actuality, it is as long as you collect your requirements with the right level of effort and tools, ensure that you only include the work that is needed, and then break that work down into the appropriate level.  What could go wrong, right? So how will you know when they do go wrong?  The same way you do with any of the other Knowledge Areas; using Monitoring and Controlling processes to determine what your actual results are in comparison to what you planned to happen.  There are two processes that help us do that; Validate Scope and Control Scope.

We are going to first discuss the Control Scope process.  In this process, the primary focus is on performing data analysis techniques to find out if scope variances exist, and if one does exist, determining if it is within the allowable threshold.  If it is not within the threshold limits, you will also determine if the project goals can be accomplished if nothing is done to correct the deficiency.

Our last Scope Management process is the Validate Scope process.  This process is performed to attempt to gain final acceptance of the project deliverables.  Verified Deliverables from the Control Quality process will be reviewed with the Sponsor or customer to ensure that they conform to the documented requirements.  Our last accepted deliverable of the project or a phase will trigger the Close Project or Phase process.  We will also need to document the completion of the requirement(s) on the RTM.

Knowledge Area Frequently Asked Questions

Q: If we are not going to include a requirement on the project, why would we need to track it on the Requirements Traceability Matrix?

A:  There are many requirements that we may receive from the various stakeholders that may be excluded from the project because they are so far afield from what the project goals are attempting to create for us.  In other cases however, we are going to exclude some requirements due to time or funding constraints.  It may be determined later in the project that the money or time is available, or that the requirement is needed or justified to include it into the work of the project.  Even if we don’t ever include that requirement into the work of the project, we need to track it because we may have stated in the Scope Statement that it was specifically excluded from the project, and the RTM will likely hold the justification for its exclusion.  Even further into that thought pattern, the exclusion of a specific requirement may be identified as the reason for project success or failure in the Lessons Learned register and your justification for its exclusion may be needed by another project to aid in determining its inclusion into a similar future or parallel project.

What to Memorize in this Knowledge Area

For the Scope Management section, you should focus your energy on memorizing the various outputs of the processes (particularly the planning processes) and their purposes.  You should also focus on the difference in Scope Management techniques (and timing) between predictive and adaptive projects.  Lastly, understand the difference between project and product scope.

• Plan Scope Management – Scope Management Plan, Requirements Management Plan
• Collect Requirements – Requirements Documentation, Requirements Traceability Matrix
• Define Scope – Scope Statement
• Create WBS – Work Breakdown Structure (WBS), WBS Dictionary, Scope Baseline
• Validate Scope – Accepted Deliverables, Change Requests
• Control Scope – Work Performance Information, Change Requests

 

Knowledge Area Critical Reasoning & Testing Skills

Q: You are a Project Manager on a project to update the camera, sensor, and traffic light system of an urban area.  You have started to collect the requirements for the project and you are trying to determine the people and documents you will need to review to gather the needed information.  In order to make sure that you collect all of the requirements, which of the following would you need to meet with to collect requirements for your project?

1. Your Project Sponsor
2. Public Servants such as Police Officers and Utility Groups
3. Individual motorists
4. All of the above

EXPLANATION: The answer here is D.  We need to collect requirements as “quantified and documented needs and expectations of the sponsor, customer, and other stakeholders” to ensure that all of the possible requirements, whether included in the project or not, are captured, “analyzed, and recorded in enough detail to be included in the scope baseline and to be measured once project execution begins” (PMBOK, Page 140).  This would mean that you would need to include a very large audience to gain an understanding of everyone’s needs for the project.  Again, they may all not be included, but you do need to gather them and make a subsequent decision on their specific inclusion or exclusion.

Knowledge Area Closing Summary

As a member of the Triple Constraint model, project and product scope need a large amount of attention and expertise to successfully manage.  To execute appropriate Scope Management on your projects, it requires a robust planning process and proper control techniques.  The experts at PM-ProLearn can help you learn how to execute this for both the PMP exam (using the Best PMP Study Guide) and for your real-world projects.  Let us help you along the way!