PMP 5: Project Scope Management

Project Scope Management
Includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully
Project Scope Management Processes
5.1 Collect Requirements
5.2 Define Scope
5.3 Create WBS
5.4 Verify Scope
5.5 Control Scope
Scope Management Plan
Provides guidance on how project scope will be defined, documented, verified, managed and controlled
Scope Management Plan is completed as part of the…
Develop Project Management Plan process
Managing Project Scope
Primarily concerned with defining and controlling what is and is not included in the project
Scope Baseline
Consist of the approved detailed project scope statement and its associated WBS and WBS dictionary. The scope baseline is monitored, verified, and controlled throughout the lifecycle of the project
Product Scope
The features and functions that characterize a product, service or results. Measured against the product requirements
Project Scope
The work that needs to be accomplished to deliver a product, service or result with the specified features and functions. Measured against the project management plan
Collect Requirements
The process of defining and documenting stakeholders needs to meet the project objectives
Inputs to Collect Requirements
1. Project Charter
2. Stakeholder Register
Tools and Techniques for Collect Requirements
1. Interviews
2. Focus Groups
3. Facilitated Workshops
4. Group Creativity Techniques
5. Group Decision Making Techniques
6. Questionnaires and Surveys
7. Observations
8. Prototypes
Outputs of Collect Requirements
1. Requirements Documentation
2. Requirements Management Plan
3. Requirements Traceability Matrix
• Quantified and documented needs and expectations of the sponsor, customer and other stakeholders
• Elicited, analyzed and recorded in enough detail to be measured once project execution begins
• Become the foundation of WBS
• Cost, schedule, and quality planning are all built upon these requirements
Development of requirements begin with…
An analysis of the information contained in the project charter and the stakeholder register
Project Requirements
Include business requirements, project management requirements, delivery requirements
Product Requirements
Include information on technical requirements, security requirements, performance requirements
Project Charter Use in Collect Requirements
Used to provide the high level project requirements and high level product description of the project so that detailed product requirements can be developed
Stakeholder Register Use in Collect Requirements
Used to identify stakeholders that can provide information on detailed project and product requirements
A formal or informal approach to discover information from stakeholders by talking to them directly
Purpose of Interviews
Interviewing experienced project participants, stakeholders, and subject matter experts can aid in identifying and defining the features and functions of the desired project deliverables
Focus Groups
• Brings together prequalified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service or result
• A trained moderator guides the group through an interactive discussion, designed to be more conversational than a one-on-one interview.
Facilitated Workshops
Focused sessions that bring key cross-functional stakeholders together to define product requirements. Workshops are considered a primary technique for quickly defining cross-functional requirements and reconciling stakeholder differences
Benefits of Facilitated Workshops
• Because of their interactive group nature, well-facilitated sessions can build trust, foster relationships, and improve communication among the participants which can lead to increased stakeholder consensus.
• Issues can be discovered and resolved more quickly than in individual session
Joint Application Development (Or Design). Facilitated workshops that focus on bringing users and the development team together to improve the software development process
JAD: Industry Use
Used in the software development industry
Quality Function Deployment. Facilitated workshops that help determine critical characteristics for new product development. QFD starts by collecting customer needs, also known as Voice of the Customer (VOC), objectively sorting and prioritizing those needs, and setting goals for achieving them
QFD: Industry Use
Used in the manufacturing industry
Group Creativity Techniques
Group activities organized to identify project and product requirements
Examples of Group Creativity Techniques
• Brainstorming
• Nominal Group Technique
• The DelphiTechnique
• Idea/mind mapping
• Affinity Diagram
Generates and collets multiple ideas related to project and product requirements
Nominal Group Technique
Enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization
The Delphi Technique
A selected group of experts answers questionnaires and provides feedback regarding the responses from each round of requirements gathering. The responses are only available to the facilitator to maintain anonymity
Idea/mind Mapping
Ideas created through individual brainstorming are consolidated into a single map to reflect commonality and differences in understanding and generate new ideas
Affinity Diagram
Allows large numbers of ideas to be sorted into groups for review and analysis
Group Decision Making Techniques
An assessment process of multiple alternatives with an expected outcome in the form of future actions resolution. These techniques can be used to generate, classify, and prioritize product requirements
Group Decision Types
• Unanimity
• Majority
• Plurality
• Dictatorship
Everyone agrees on a single course of action
Support from more than 50% of the members of the group
The largest block in a group decides even if a majority is not achieved
One individual makes the decision for the group
Questionnaires and Surveys
Written sets of questions designed to quickly accumulate information from a wide number of respondents. Most appropriate with broad audiences, when quick turnaround is needed, and where statistical analysis is appropriate
Provide a direct way of viewing individuals in their environment and how they perform their jobs or tasks and carry out processes. Helpful for detailed processes when the people that use the product have difficulty or are reluctant to articulate their requirements
Job Shadowing
A type of observation where the observer is viewing the user performing his or her job
Participating Observer
A type of observation where th observer performs a process or procedure to experience how it is done to uncover hidden requirements
• A method of obtaining early feedback on requirements by providing a working model of the expected product before actually building it
• Allows stakeholders to experiment with a model of their final product
• Support the concept of progressive elaboration because they are used in iterative cycles of mock-up creation, user experimentation, feedback generation, and prototype revision
Requirements Documentation
• Describes how individual requirements meet the business need for the project. May start at a high level and become progressively more detailed
Characteristics of Requirements
• Unambiguous (measureable and testable)
• Traceable
• Complete
• Consistent
• Acceptable to key stakeholders
Components of Requirements Documentation
• Business need or opportunity to be seized, describing the limitations of the current situation and why the project has been undertaken;
• Business and project objectives for traceability;
• Functional requirements, describing business processes, information, and interaction with the product, as appropriate
• Non-functional requirements, such as level of service, performance, safety, security, compliance, supportability, retention/purge, etc.;
• Quality requirements;
• Acceptance criteria;
• Business rules stating the guiding principles of the organization;
• Impacts to other organizational areas, such as the call center, sales force, technology groups;
• Impacts to other entities inside or outside the performing organization;
• Support and training requirements; and
• Requirements assumptions and constraints
Requirements Management Plan
Documents how requirements will be analyzed, documented, and managed throughout the project
Components of Requirements Management Plan
• How requirements activities will be planned, tracked, and reported;
• Configuration management activities such as how changes to the product, service, or result requirements will be initiated, how impacts will be analyzed, how they will be traced, tracked, and reported, as well as the authorization levels required to approve these changes;
• Requirements prioritization process;
• Product metrics that will be used and the rationale for using them; and
• Traceability structure, that is, which requirements attributes will be captured on the traceability matrix and to which other project documents requirements will be traced
Requirements Traceability Matrix
• A table that links requirements to their origin and traces them throughout the project lifecycle.
• Helps ensure that each requirement adds business value by linking to the business and project objectives
• Provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved into the requirements documentation are delivered at the end of the project
• Provides a structure for managing changes to the product scope
Requirements Traceability Matrix traces…
• Requirements to business needs, opportunities, goals, and objectives;
• Requirements to project objectives;
• Requirements to project scope/WBS deliverables;
• Requirements to product design;
• Requirements to product development;
• Requirements to test strategy and test scenarios; and
• High-level requirements to more detailed requirements.
Requirement Attributes
• A unique identifier
• A textual description of the requirement
• The rationale for inclusion
• Owner
• Source
• Priority
• Version
• Current Status (Active, cancelled, deferred, added, approved)
• Date completed
• Stability
• Complexity
• Acceptance criteria
Define Scope
The process of developing a detailed description of the project and product
Characteristics of Define Scope
• Critical to project success and builds upon the major deliverables, assumptions, and constraints that are documented during project initiation.
• Defined and described with greater specificity as more information about the project is known.
• Existing risks, assumptions, and constraints are analyzed for completeness; additional risks, assumptions, and constraints are added as necessary
Inputs to Define Scope
1. Project Charter
2. Requirements Documentation
3. Organizational Process Assets
Tools and Techniques for Define Scope
1. Expert Judgement
2. Product Analysis
3. Alternatives Identification
4. Facilitated Workshops
Outputs of Define Scope
1. Project Scope Statement
2. Project Document Updates
Project Charter Use in Define Scope
Provides the high-level project description and product characteristics and contains project approval requirements
Define Scope: Organizational Process Assets
• Policies, procedures, and templates for a project scope statement,
• Project files from previous projects, and
• Lessons learned from previous phases or projects
Define Scope: Expert Judgement Use
Used to analyze the information needed to develop the project scope statement. Such judgment and expertise is applied to any technical details
Define Scope: Expert Judgement Sources
Provided by any group or individual with specialized knowledge or training:
• Other units within the organization,
• Consultants,
• Stakeholders, including customers or sponsors,
• Professional and technical associations,
• Subject matter experts
Product Analysis
Includes techniques such as product breakdown, systems analysis, requirements analysis, systems engineering, value engineering, and value analysis
Alternatives Identification
A technique used to generate different approaches to execute and perform the work of the project. A variety of general management techniques can be used such as brainstorming, lateral thinking, pair wise comparisons, etc
Project Scope Statement
Describes, in detail, the project’s deliverables and the work required to create those deliverables
Purpose of a Project Scope Statement
• Provides a common understanding of the project scope among project stakeholders.
• May contain explicit scope exclusions that can assist in managing stakeholder expectations.
• Enables the project team to perform more detailed planning, guides the project team’s work during execution, and provides the baseline for evaluating whether requests for changes or additional work are contained within or outside the project’s boundaries.
Components of a Project Scope Statement
• Product scope description.
• Product acceptance criteria.
• Project deliverables.
• Project exclusions.
• Project constraints.
• Project assumptions.
Product Scope Description
Progressively elaborates the characteristics of the product, service, or result described in the project charter and requirements documentation
Product Acceptance Criteria
Defines the process and criteria for accepting completed products, services, or results
Project Deliverables
Include both the outputs that comprise the product or service of the project, as well as ancillary results, such as project management reports and documentation
Project Exclusions
Generally identifies what is excluded as from the project. Explicitly stating what is out of scope for the project helps to manage stakeholders’ expectations
Project Constraints
Lists and describes the specific project constraints associated with the project scope that limits the team’s options, for example, a predefined budget or any imposed dates or schedule milestones that are issued by the customer or performing organization
Project Assumptions
Lists and describes the specific project assumptions associated with the project scope and the potential impact of those assumptions if they prove to be false
Define Scope: Project Document Updates
• Stakeholder register,
• Requirements documentation, and
• Requirements traceability matrix
Create WBS
The process of subdividing project deliverables into smaller, more manageable components
In the context of the WBS, work refers to work products or deliverables that are the result of effort and not to the effort itself
Inputs to Create WBS
1. Project Scope Statement
2. Requirements Documentation
3. Organizational Process Assets
Tools and Techniques for Create WBS
1. Decomposition
Outputs of Create WBS
1. WBS
2. WBS Dictionary
3. Scope Baseline
4. Project Document Updates
Create WBS: Organizational Process Assets
• Policies, procedures, and templates for the WBS,
• Project files from previous projects, and
• Lessons learned from previous projects
The subdivision of project deliverables into smaller, more manageable components until the work and deliverables are defined to the work package level
Work Package Level
The work package level is the lowest level in the WBS, and is the point at which the cost and activity durations for the work can be reliably estimated and managed. The level of detail for work packages will vary with the size and complexity of the project
Decomposition Activities
• Identifying and analyzing the deliverables and related work,
• Structuring and organizing the WBS,
• Decomposing the upper WBS levels into lower level detailed components, where the WBS components represent verifiable products, services, or results
• Developing and assigning identification codes to the WBS components, and
• Verifying that the degree of decomposition of the work is necessary and sufficient
WBS Structure Forms
• Using phases of the project life cycle as the first level of decomposition, with the product and project deliverables inserted at the second level
• Using major deliverables as the first level of decomposition,
• Using subprojects which may be developed by organizations outside the project team, such as contracted work. The seller then develops the supporting contract work breakdown structure as part of the contracted work
WBS Structure
The WBS can be structured as an outline, an organizational chart, a fishbone diagram, or other method
Verifying the Decomposition
Verifying the correctness of the decomposition requires determining that the lower-level WBS components are those that are necessary and sufficient for completion of the corresponding higher level deliverables
Purpose of Decomposition
As the work is decomposed to greater levels of detail, the ability to plan, manage, and control the work is enhanced.
Excessive decomposition can…
lead to non-productive management effort, inefficient use of resources, and decreased efficiency in performing the work
Rolling Wave Planning
Decomposition may not be possible for a deliverable or subproject that will be accomplished far into the future. The project management team usually waits until the deliverable or subproject is clarified so the details of the WBS can be developed.
100% Rule
The total of the work at the lowest levels must roll up to the higher levels so that nothing is left out and no extra work is completed
Work Breakdown Structure. A deliverable-oriented hierarchical decomposition of the work to be executed by the project team, to accomplish the project objectives and create the required deliverables, with each descending level of the WBS representing an increasingly detailed definition of the project work
Purpose of the WBS
Organizes and defines the total scope of the project, and represents the work specified in the current approved project scope statement
How is the WBS Finalized
The WBS is finalized by establishing control accounts for the work packages and a unique identifier from a code of accounts. These identifiers provide a structure for hierarchical summation of costs, schedule, and resource information
Control Account
A management control point where scope, cost, and schedule are integrated and compared to the earned value for performance measurement
Characteristics of a Control Account
• Control accounts are placed at selected management points in the WBS.
• Each control account may include one or more work packages, but each of the work packages must be associated with only one control account
WBS Dictionary
A document generated by the Create WBS process that supports the WBS. It provides a more detailed descriptions of the components in the WBS, including work packages and control accounts
Information included in the WBS Dictionary
• Code of account identifier,
• Description of work,
• Responsible organization,
• List of schedule milestones,
• Associated schedule activities,
• Resources required,
• Cost estimates,
• Quality requirements,
• Acceptance criteria,
• Technical references, and
• Contract information.
Scope Baseline
A component of the project management plan
Components of the Scope Baseline
• Project scope statement.
• WBS.
• WBS dictionary.
Create WBS: Project Document Updates
• Requirements documentation
Verify Scope
The process of formalizing acceptance of the completed project deliverables
Verify Scope Activities
Includes reviewing deliverables with the customer or sponsor to ensure that they are completed satisfactorily and obtaining formal acceptance of deliverables by the customer or sponsor.
Verify Scope vs. Quality Control
Verify Scope is primarily concerned with acceptance of the deliverables, while quality control is primarily concerned with correctness of the deliverables and meeting the quality requirements specified for the deliverables. Quality control is generally performed before scope verification, but these two processes can be performed in parallel
Inputs to Verify Scope
1. Project Management Plan
2. Requirements Documentation
3. Requirements Traceability Matrix
4. Validated Deliverables
Tools and Techniques for Verify Scope
1. Inspection
Outputs of Verify Scope
1. Accepted Deliverables
2. Change Requests
3. Project Document Updates
Project Management Plan Use in Verify Scope
Contains the scope baseline. Components of the scope baseline include: Project scope statement, WBS, WBS dictionary
Requirements Documentation Use in Verify Scope
Lists all the project, product, technical, and other types of requirements that must be present for the project and product, along with their acceptance criteria
Requirements Traceability Matrix Use in Verify Scope
Links requirements to their origin and tracks them throughout the project life cycle
Validated Deliverables Use in Verify Scope
Validated deliverables have been completed and checked for correctness by the Perform Quality Control process
Includes activities such as measuring, examining, and verifying to determine whether work and deliverables meet requirements and product acceptance criteria. Sometimes called reviews, product reviews, audits, and walkthroughs. In some application areas, these different terms have narrow and specific meanings
Accepted Deliverables
Deliverables that meet the acceptance criteria are formally signed off and approved by the customer or sponsor. Formal documentation received from the customer or sponsor acknowledging formal stakeholder acceptance of the project’s deliverables is forwarded to the Close Project or Phase process
Verify Scope: Change Requests
• Those completed deliverables that have not been formally accepted are documented, along with the reasons for non-acceptance.
• Those deliverables that may require a change request for defect repair.
• The change requests are processed for review and disposition through the Perform Integrated Change Control proces
Verify Scope: Project Document Updates
Any documents that define the product or report status on product completion
Control Scope
The process of monitoring the status of the project and product scope and managing changes to the scope baseline
Purpose of Control Scope
Controlling the project scope ensures all requested changes and recommended corrective or preventive actions are processed through the Perform Integrated Change Control process. Also used to manage the actual changes when they occur and is integrated with the other control processes
Project Scope Creep
Uncontrolled changes
Inputs to Control Scope
1. Project Management Plan
2. Work Performance Information
3. Requirements Documentation
4. Requirements Traceability Matrix
5. Organizational Process Assets
Tools and Techniques for Control Scope
1. Variance Analysis
Outputs of Control Scope
1. Work Performance Measurements
2. Organizational Process Assets Updates
3. Change Requests
4. Project Management Plan Updates
5. Project Document Updates
Project Management Plan Use in Control Scope
• Scope baseline.
• Scope management plan.
• Change management plan.
• Configuration management plan.
• Requirements management plan.
Scope Baseline Use in Control Scope
Is compared to actual results to determine if a change, corrective action, or preventive action is necessary
Scope Management Plan
Describes how the project scope will be managed and controlled
Change Management Plan
Defines the process for managing change on the project
Configuration Management Plan
Defines those items that are configurable, those items that require formal change control, and the process for controlling changes to such items
Requirements Management Plan
Includes how requirements activities will be planned, tracked, and reported and how changes to the product, service, or result requirements will be initiated. It also describes how impacts will be analyzed and the authorization levels required to approve these changes
Work Performance Information Use in Control Scope
Information about project progress, such as which deliverables have started, their progress and which deliverables have finished
Control Scope: Organizational Process Assets
• Existing formal and informal scope control-related policies, procedures, and guidelines
• Monitoring and reporting methods to be used
Variance Analysis
Project performance measurements are used to assess the magnitude of variation from the original scope baseline. Important aspects of project scope control include determining the cause and degree of variance relative to the scope baseline and deciding whether corrective or preventive action is required
Control Scope: Work Performance Measurements
Can include planned vs. actual technical performance or other scope performance measurements. This information is documented and communicated to stakeholders
Control Scope: Organizational Process Asset Updates
• Causes of variances,
• Corrective action chosen and the reasons, and
• Other types of lessons learned from project scope control
Control Scope: Change Requests
• Analysis of scope performance can result in a change request to the scope baseline or other components of the project management plan.
• Change requests can include preventive or corrective actions or defect repairs.
• Change requests are processed for review and disposition according to the Perform Integrated Change Control process
Control Scope: Project Management Plan Updates
• Scope Baseline Updates. If the approved change requests have an effect upon the project scope, then the scope statement, the WBS, and the WBS dictionary are revised and reissued to reflect the approved changes.
• Other Baseline Updates. If the approved change requests have an effect on the project scope, then the corresponding cost baseline and schedule baselines are revised and reissued to reflect the approved changes
Control Scope: Project Document Updates
• Requirements documentation
• Requirements traceability matrix
Collect Requirements Process Group
Planning Process Group
Define Scope Process Group
Planning Process Group
Create WBS Process Group
Planning Process Group
Verify Scope Process Group
Monitoring and Controlling Process Group
Control Scope Process Group
Monitoring and Controlling Process Group
WBS Numbering System
Determines the level at which individual WBS elements are found
Value Addition
Usually, is a result of implementation of change requests
If there is a major change to the project, the project manager should…
try to influence the change to minimize the impact on the project. Usually the project manager is advised to do the following:

1. Evaluate the impact of the change within the team.
2. Help the customer (or person requesting the change) understand the impact of the change.
3. If changes are in fact required, then open a change control and get the request approved. Obviously, you will have to inform the management and the change control board about the impact of the changes.
4. If the change control board approves changes, then make appropriate changes in the project plan

A well constructed scope statement…
• Provides a documented basis for making future project decisions
• Develops common understanding of project scope among stakeholders
• Provides knowledge of project justification, deliverables, and objectives
Without the scope statement…
• You do not have a good understanding of the project justification, product, or project deliverables and project objectives.
• You do not have all the inputs for the scope definition and for the creation of work breakdown structure (WBS).
Verify Scope should be performed after…
getting individual deliverables from quality control process
You should be very diligent when you….
collect requirements. The project`s success is directly influenced by the care taken in capturing and managing project and product requirements
SMART Requirements
S pecific
M easurable
A ccurate / attainable
R ealistic / Relevant
T ime-bound
• Rule of Thumb
• an experience-based technique
• it is used when exhaustive estimation based on detailed mathematical formulas is impractical
• Can be applied to develop a schedule
Tagged In :

Get help with your homework

Haven't found the Essay You Want? Get your custom essay sample For Only $13.90/page

Sarah from studyhippoHi there, would you like to get such a paper? How about receiving a customized one?

Check it out