Chapter 05: Scope Management Flashcards
Knowledge Area Overview
This knowledge area defines what is inside and outside the parameters of the project, and defines the requires work to meet those requirements.
Scope management
Knowledge Area Overview
What are the two kinds of scope?
project scope and product scope
Knowledge Area Overview
This scope consists of the features and functions of the product, service, and/or result that is to be formed by the project. Completion of the scope is measured against the product requirements.
product scope
Knowledge Area Overview
This scope consists of the project work that is needed to deliver the project’s product, service, and results. Fulfillment of the scope is measured against the project management plan.
project scope
Knowldge Area Overview
The general workflow for scope management consists of collecting … , defining the … , and creating the …
requirements
scope
WBS
Knowledge Area Overview
Which project management life cycle typically has the project scope and deliverables defined at the beginning and tightly managed through change control?
predictive life cycle
Knowledge Area Overview
For adaptive/agile environments, the scope is defined and approved at the beginning of each … by choosing work from a product … , which is also reprioritized and constantly reviewed.
iteration
product backlog
Knowledge Area Overview
In a predictive lifecycle, scope validation occurs at the ____. In an adaptive lifecycle, scope validation is repeated throughout ____. Controlling the scope is an ____ process for both.
end of each phase
each iteration
ongoing
Knowledge Area Overview
Why is stakholder input important at the beginning of a project for predictive life cycles?
Because their requirements and expectations will dictate quality management, which will help towards providing deliverables that can be validated smoothly. If project managers are flying blind without guidance on what the customer wants, then rework will likely have to be done.
Knowledge Area Overview
Why is higher stakeholder engagement and input important throughotu an adaptive/agile life cycle?
Having them alongside you providing feedback (i.e., reprioritized backlog, accepted deliverables) is even more important because things are moving quickly. You don’t want to get too far ahead and then find out reword and peddling back to revisit work is needed.
Knowledge Area Overview
In predictive life cycles the scope baselines are determined early on in the project and can only be changed through formal … procedures.
change control
Knowledge Area Overview
For adaptive live cycles, the scope comes in the form of a … that is constantly changed, added, amended, and reprioritized with … stories. This is done with the high engagement of stakeholder to make sure everything stays on track.
product backlog
user stories
Processes Overview
What are the six (6) processes belonging to Scope Management? Write them down on a piece of paper. If you get it wrong; write it down ten times.
5.1: Plan Scope Management
5.2: Collect Requirements
5.3: Define Scope
5.4: Create WBS
5.5: Validate Scope
5.6: Control Scope
Processes Overview
Under which process groups do each of these Scope Management processes belong?
1. Plan Scope Management
2. Collect Requirements
3. Define Scope
4. Develop WBS
5. Control Scope
6. Validate Scope
- Plan Scope Management (Planning)
- Collect Requirements (Planning)
- Define Scope (Planning)
- Develop WBS (Planning)
- Control Scope (Monitor/Controlling)
- Validate Scope (Monitor/Controlling)
Trends & Emerging Practices
There is a growing emphasis on utilizing the information from … analysis to define, manage and control the project requirements. As a result, the PM is collaborating more with this field/personnel during and before project planning.
business analysis
business analyst
Trends & Emerging Practices
The … deals more with requirement responsibilities, whereas the PM is concerned with the work related to those requirements.
business analyst
Adaptive/Agile Environments
In adaptive/agile environments, (more/less) time is deliverately spent determining the scope at the beginning and (more/less) planning the processes for ongoing discovery and refinement. Whereas (scope/time/cost) is fixed and (scope/time/cost) varies in predictive life cycles, adaptive life cycles usually have fixed (scope/time/cost) and varying (scope/time/cost).
In adaptive/agile environments, (more/less) time is deliverately spent determining the scope at the beginning and (more/less) planning the processes for ongoing discovery and refinement. Whereas (scope/time/cost) is fixed and (scope/time/cost) varies in predictive life cycles, adaptive life cycles usually have fixed (scope/time/cost) and varying (scope/time/cost).
Adaptive/Agile Environment
The prioritization of … stories in the …. backlog is constantly changing throughout an adaptive life cycle, between … by working closely with the product owners who are usually the …
user stories
product backlog
iterations
customer and/or stakeholder
Adaptive/Agile Environment
For agile projects, decomposition is used to break down … into user stories.
epics
Processes Definitions
This process is used to develop the Scope Management Plan
Hint: a project management plan subsidiary.
5.1: Plan Scope Management (Planning)
Processes Definitions
This process is used to identify the needs of all stakeholders and gathering feedback of the project’srequirements.
5.2: Collect Requirements (Planning)
Processes Definitions
This process will create a detailed description of the project’s scope and acceptance criteria.
5.3: Develop Scope (Planning)
Processes Definitions
This process will divide the project’s scope into smaller, discrete components.
5.4: Create Work Breakdown Structure (WBS)
Process Definitions
This process will obtain the customer’s formal acceptance and approval of the project deliverables.
5.5: Validate Scope (Monitor/Control)
Processes Definitions
This process will oversee the project’s scope and any changes made tot he project’s initial Scope baseline.
Hint: Do not get this confused with “Direct & Execute Project Work”
5.6: Control Scope (Monitor/Control)
5.1: Plan Scope Management
What are the two key outputs for Plan Scope Management
The scope management plan, and the requirements management plan.
5.1: Plan Scope Management
This key output for Plan Scope Management is the less expected one, but is important because it oultines how we will evaluate, record and capture our project requirements.
Requirements Management Plan
5.1: Plan Scope Management
This key output for Plan Scope Management includes the high-level strategy and process for controlling the scope, creating and maintaining the scope baseline, and obtaining approval from their project deliverables.
Hint: It does not actually create them, but rather creates a guidebook.
Scope Management Plan
5.1: Plan Scope Management
This document is a key input for Plan Scope Management because you need the overview/vision of the project to elaborate upon it into the scope.
project charter
5.1: Plan Scope Management
This key input belonging to the project management plan is important for Plan Scope Management because it lets you know if the scope should be planned early on AMAP or progressively elaborated and remains flexible throughout the project.
Hint: there’s an “&” in the answer
project life cycle & development approach
5.1: Plan Scope Management
This key output for Plan Scope Management will create a high-level strategy and process for creating a scope baseline (statement, WBS, dictionary), maintaining the baseline, controlling the project’s scope, and specifying how formal acceptance of the deliverables should occur.
scope management plan
5.1 Plan Scope Management
Why is the quality management plan a useful input for Plan Scope Management?
Because the procedures, processes, methodologies, and standards that you lay out there for measuring the quality of your project work will help validate and control and validate the project scope.
5.1: Plan Scope Management
The requirements management plan is one of two key outputs for Plan Scope Management because it codifies the project scope’s requirements.
It will provide guidance and strategies on how the requirements will be planned, tracked and reported (including what metrics will measure them). There will also be guidance on how to reprioritize requirements. And it also has the important subcomponent known as this: RTM.
requirements traceability matrix
5.2: Collect Requirements
Whereas this process is done once or at predefined points throughout a predictive project, how are requirements typically collected in agile projects?
Usually constantly and throughout. Remember there are breaks in between sprints and iterations, and stakeholder input and engagement is much higher.
5.2: Collect Requirements
What three key subsidiary components of the project management plan is crucial for Collect Requirements?
scope management plan - your bible
requirements management plan - formed in the previous process, includes how to collect
stakeholder management plan - who you need to speak with and has influence on scope
5.2: Collect Requirements
In addition to the three typical data-gathering tools/techniques we have seen in Integration Management (brainstorming, interviewing, focus groups), there are two new techniques introduced in Collect Requirements. This one obtains requirements by comparing other systems, product, organizations and/or approaches to identify the best practices or where there is room for improvement.
benchmarking
5.2: Collect Requirements
In addition to the three typical data-gathering tools/techniques we have seen in Integration Management (brainstorming, interviewing, focus groups), there are two new techniques introduced in Collect Requirements. This one is used to quickly gather information from large number of people. It’s good for when you want to conduct statistical analyses, has quick turnaround, and have stakeholders/participants geographically dispersed.
Hint: there’s an “&”
Questionnaires & Surveys
5.2: Collect Requirements
This data-gathering technique is a slight variation of brainstorming, where you vote tank the most favorable/important ideas to prioritize brainstorming. Rank and process eliminate.
nominal group technique
5.2: Collect Requirements
This data/tool technique used in Collect Requirements will visualize how the organization, project team, and users will interact with the business processes and organization.
context diagram
5.2: Collect Requirements
This data/tool technique used in Collect Requirements is great for obtaining feedback by providing a model to look at; it moves thins out of the abstract and bring the idea to reality.
Hint: used in agile environments and storyboarding, media industry for illustrations or markup software
protoyping
5.2: Collect Requirements
This is one of two key outputs for Collect Requirements which is a list of all the requirements that you have gathered and established for the project from this process.
Hint: unlike the RTM, it does not provide traceability or linkage to any of the project deliverables.
requirements documentation
5.2: Collect Requirements
This one of two key outputs for Collect Requirements links the requirements gathered from the process to the different deliverables and work activities so you can better know how and when something is accomplished.
Hint: project managers use this to trck the product’s scope and requirements completion throughout the entire project life cycle.
requirements traceability matrix (RTM)
5.2: Collect Requirements
Name the two key outputs for Collect Requirements
Hint: they’re similar
requirements documentation
requirements traceability martrix
5.2: Collect Requirements
The requirements documentation that is generated as a result of Collect Requirements contains the following:
… (behaviors) and … (environmental conditions, ease of use, etc.) solution requirements
… requirements (needs of SH)
… requirements (moving between phases or to hand it off)
… requirements (the conditions and criteria to confirm successful deliverable)
functional and nonfunctional behaviors
stakeholder requirements
transition requirements
quality requirements
Processes Overview
This process fully characterizes the product’s scope and acceptance criteria, based upon the requirements captured in the previous process Collect Requirements
5.3: Defining Scope (Planning)
5.3: Define Scope
Alongside the obvious scope management plan, this key project document will be essential for Define Scope.
Hint: it was created in the previous process and hsa the long list that you can select from to make the project scope official.
requirements documentation
5.3: Define Scope
This other project document input is useful because it will contain certain response and mitigation strategies to account for when defining the scope.
risk register
Processes Overview
This process chooses the final requirements and creates a detailed statement of the product/project’s final scope.
5.3: Define Scope
5.3: Define Scope
This concept is based off progressive elaboration, where the scope can be iteratively developed. First start off with a sufficient high-level scope and then it gets refined and more detailed as more information is discovered.
Hint: the ocean.
rolling wave planning
5.3: Define Scope
This key output for Define Scope outlines the entire scope of your project and product.
scope statement
5.3: Define Scope
This tool/technique is used to define the characteristics of the product, service or result that will be part of the scope. Activities include value engineering, studying components and product breakdowns
product analysis
5.3: Define Scope
This tool/technique used in Define Scope continuously studies and asks questions to determined the characteristics of the final deliverables for the project. The information from that analysis is translated and decomponsed into details to create the final requirements.
product analysis
5.3: Define Scope
The scope statement contains the product scope and deliverables, but also this term for confirming they meet requirements, and also what is not part of the project. It is important to include this information as well because it minimizes scope creep.
acceptance criteria
exclusions
5.3: Define Scope
What are the three components to the scope statement?
Hint: it will relate to the deliverables.
product scope description
deliverables
acceptance criteria
exclusions
Processes Overview
This process creates the scope baseline by decomposing the project’s work into easy-to-manage “chunks” by looking at the recently created project scope and the requirements documentation
5.4: Create WBS
5.4: Create WBS
In Create WBS you take the ____ management plan, along with the ____ and the ____ documents created from the previous planning processes in order to create the WBS, which can then collevely create this key output known as the ____ baseline.
In Create WBS you take the scope management plan, along with the scope statement and the requirements documents created from the previous planning processes in order to create the WBS, which can then collevely create this key output known as the scope baseline.
Hint: The RTM is more for the executing and control input processes of this knowledge area since there is linkage to monitor the work back to deliverables.
5.4: Create WBS
This tool/technique is used to take the scope statement and the requirements and breaks it down into manageable work packages
decomposition
5.4: Create WBS
True or False. The work breakdown structure includes the project activities.
False. The work breakdown structure only includes the project deliverables.
5.4: Create WBS
What are the three key inputs for Create WBS.
Hint: one of them does not relate to scope. All of them are created in the previous planning processes for Scope Management
scope management plan
scope statement
requirements documentation
5.4: Create WBS
What is the hierarchy of structures in a WBS?
control accounts; planning package; work packages
5.4: Create WBS
This hierarchical structure of the WBS stores future work until it can be broken down into the needed work packages.
planning packages
5.4: Create WBS
This hierarchical structure in the WBS is the highest and combines the scope, cost and schedule to then use it as a reference point for performance measurement.
control accounts
5.4: Create WBS
This rule is used when creating work packages to avoid decompositioning the work too far and overhwelming yourself with resource management, data gathering bloat.
8/80 rule
Processes Overview
This process is inspection-driven, where the customer inspects the project work and grants formal acceptance of completed deliverables.
5.5 Validate Scope
Processes Overview
Audits, reviews, or walkthroughs are performed by this customer to inspect the project deliverables in this process
5.5: Validate Scope
5.5: Validate Scope
The **… deliverables **that come out from the Control Quality process are used as an input in Validate Scope for the customer to formally accept.
verified deliverables
5.5: Validate Scope
The verified deliverables from the … process that are an input for Validate Scope are compared against what two key project documents, along with what three (3) project management plan components.
Hint: they both have the same word in them.
Control Quality
scope management plan
requirements management plan
scope baseline
requirements documentation
requirements traceability matrix
For this process, the … deliverables from the Control Quality process are compared against the … baseline and the two requirement-based documents against the … data generated during the Direct & Manage Project Work process from Integration Management, using the … management plan and the … management plan as your guide.
For this process, the .verified deliverables from the Control Quality process are compared against the scope baseline and the two requirement-based documents (requirements traceability matrix and the requirements matrix) against the work performance data generated during the Direct & Manage Project Work process from Integration Management, using the scope management plan and the requirements management plan as your guide.
5.5: Validate Scope
There are three general questions that the SH will answer upon answering the deliverables:
- What did we want?
- What did we create?
- Did we create what we wanted?
The following set of inputs will help answer which question?
* scope baseline
* scope management plan
* requirements management plan
What did we want?
5.5: Validate Scope
There are three general questions that the SH will answer upon answering the deliverables:
- What did we want?
- What did we create?
- Did we create what we wanted?
The following set of inputs will help answer which question?
* verified deliverables
* work performance data
What did we create?
5.5: Validate Scope
There are three general questions that the SH will answer upon answering the deliverables:
- What did we want?
- What did we create?
- Did we create what we wanted?
The following set of inputs will help answer which question?
* quality reports
* requirements documentation
* requirements traceability matrix
Did we create what we wanted?
Hint: You will take the verified deliverables and the work performance data and compate them against these documents.
5.5: Validate Scope
Those verified deliverables that are accepted by the customer become this key output for Validate Scope.
accepted deliverables
The project stakeholders will take the work performance data that is received in Validate Scope and use it to make a decision on the deliverable’s acceptance. To make that decision, the data needs to be analyzed, and so another key output of this process is …
work performance information
5.5: Validate Scope
Though the goal is to generate accepted deliverables, this other output could result if there are inconsistencies, gaps, or additional requirements that come from the customer reviewing the deliverables.
change requests
5.5: Validate Scope
This key tool/technique for Validate Scope is used by the customer to review the deliverables and determine if the completed work meets all the requirements and acceptance criteria.
inspections
5.5: Validate Scope
Which of the following would be the best document to update for Validate Scope to document the accepted deliverables?
lessons learned register
requirements documentation
requirements traceability matrix
requirements traceability matric (RTM)
Processes Overview
This process monitors and controls the scope baseline to make sure it doesn’t change without being reviewed and approved by the Change Control Board through the formal Integrated Change Control process.
5.6: Controlling Project Scope
5.6: Control Project Scope
All requested changes (including corrective, preventive, and defect repair actions) for changing the scope must go through … This methdology is put in place to avoid scope creeping and goldplating.
integrated change control
Why are the following project management plan components important for Validate Scope?
- scope management plan
- requirements management plan
- change management plan
- configuration management plan
- scope baseline AND performance measurement baseline
The scope management plan will serve as a guide that has laid out how to control the scope. The scope baseline is the actual scope that you will refer to and making sure the performed work is within its bounds.
The **requirements management plan ** will lay out the requirements that are to be collected, tracked, and how to analyze them; knowing what those requirements are and how to evaluate them will be critical for making sure you can accurately determine if the project is performing within the scope baseline.
The change management plan will tell you what, when and how to change via the formal control procedures laid out within it. Should there be something about the scope you need to change, this is what you will need to follow. If the changes are to the product, service, or result’s features and functions, then you have the configuration management plan to consult as well.
The schedule and costs of the project are also monitored against the performance measurement baseline to see if the project scope is matching against the time and money spent.
All of them wil tell you how to evaluate the work performance data so that you can accurately determine if the project is on track in terms of scope.
5.6: Control Scope
What four (4) project management plans and two (2) baselines are used to guide the PM for evaluating the work performance data in Validate Scope?
What sources will tell you what benchmarks the work performance data should meet?
scope management plan
scope baseline and performance measurement baseline
change management plan
configuration management plan
requirements management plan
requirements documentation and requirements traceability matrix
5.6: Control Scope
True or False. Deliverables are not an input for the Control Scope process.
True. Verified deliverables are only an input for Validate Scope. In this process you are simply evaluating the work performance data to make sure the work is being done as needed or if any changes are required.
5.6: Control Scope
This data analysis technique for Control Scope compares your initial baseline to the actual performance of the project, where depending on the difference it will determine what kind of action (if any) should be taken to steer the project back ont track.
variance analysis
5.6: Control Scope
This data anlysis technique for Control Scope evaluates the project’s historical performance to see if the rpoject’s performance will improve, get worse, or remain on course. Doing this analysiswill allow you to be proactivce and change the scope proactively, if needed.
trend anaysis
5.6: Control Scope
Name the two common types of analysis techniques that are used in Validate Scope.
Hint: current, past and future
trend analysis and variance analysis
5.6: Control Scope
What are the two key outputs resulting from Control Scope?
Hint: one evolves, and one is needed if you want to do anything.
work performance information
change requests
Because the work performance data that was an input is analyzed, it now has context and is measured against the baselines. Should there be any gaps, inconsistencies, or variances and a change in the scope id required, then those changes can only be done by initiating the formal change contro procedures that begins with a change request.
