project scope management days 1 & 2 1. project scope management project scope management...
TRANSCRIPT
Project Scope Management
Days 1 & 2
1
Project Scope Management Project Scope Management
Ensures that project includes all the work required, and only the work required, to complete the project successfully
Primarily concerned with defining and controlling what is and is not included in the project
Processes need to be integrated with other knowledge area processes so that the work of the project will result in delivery of the specified product scope
2
Project Scope Management Processes Plan Scope Management
Creating a plan that documents how the project scope will be defined, validated, and controlled
Collect Requirements Defining and documenting stakeholders’ needs to meet the
project objectives Define Scope
Developing a detailed description of the project and product Create WBS
Subdividing the major project deliverables and project work into smaller, more manageable components
Validate Scope Formalizing acceptance of the completed project deliverables
Control Scope Monitoring the status of the project and product scope and
managing changes to the scope baseline
3
What is scope? Project scope
The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions
Completion is measured against the project management plan
Product scope The features and functions that characterize
a product, service, or result Completion is measured against the product
requirements
4
The Scope Baseline is
A detailed agreement between the customer and the service provider stating what work (tasks/activities) will and won’t be delivered that will satisfy stakeholder requirements
The approved version of the Project scope statement Work Breakdown Structure (WBS) WBS Dictionary
5
A Baseline
Can be changed only through formal change control procedures
Used to measure the acceptability of the deliverable during Validate and Control Scope processes as well as other controlling processes
6
Plan Scope Management Creates the scope management plan Says how the project scope will be defined,
validated and controlled Helps you to decided how to manage scope
throughout the project
7
8
DFD
Plan Scope Management: Inputs
Project Management Plan Approved subsidiary plans of the project
management plan are used to create the scope management plan and influence the approach taken for planning scope and managing project scope
Project Charter Provides the high-level project description
characteristics from the project statement of work
9
Plan Scope Management: Inputs
Enterprise Environmental Factors Organization’s culture, Infrastructure Personnel administration Market place conditions
Organizational Process Assets Policies and procedures Historical information and lessons learned
10
Plan Scope Management: Tool and Techniques
Expert Judgment Input received from knowledgeable and
experienced people Meetings
Collaborative meetings to discuss the solution alternative, boundaries of investigation, how scope will be define, validated and controlled
11
Plan Scope Management: Outputs
Scope Management Plan Describes how the scope will be defined,
developed, monitored, controlled, and verified
Is a major input into the Develop Project Management Plan process, and the other scope management processes
12
Scope Management Plan: Components Process for preparing a detailed project scope statement Process that enables the creation of the WBS from the
detailed project scope statement Process that establishes how the WBS will be maintained
and approved Process that specifies how formal acceptance of the
completed project deliverables will be obtained Process to control how requests for changes to the detailed
project scope statement will be processed This process is directly linked to the Perform Integrated
Change Control process
13
Requirements Management Plan
A component of the project management plan
Describes how the requirements will be analyzed, documented and managed
Indicates which phase-to-phase relationship will be used Sequential Overlapping
14
Requirements Management Plan Components How requirements activities will be planned, tracked, and
reported Configuration management activities such as: how
changes to the product 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 Traceability structure to reflect which requirement
attributes will be captured on the traceability matrix
15
Collect Requirements Requirements
Development starts by analyzing the project charter Include needs and expectations of the sponsor,
customer and other stakeholders Are asked for, analyzed and recorded in enough detail
to be measured once the project execution begins Become the foundation of the WBS Are used for cost, schedule & quality planning Are categorized into project and product efforts
16
Collect Requirements: ITTO
17
18
DFD
Collect Requirements
Success directly influenced by Active stakeholder involvement in the
discovery and decomposition of needs into requirements
Care taken in determining, documenting and managing the requirements of the product, service or result
19
Collect Requirements: Include
Conditions or capabilities to be met by the project or are present in the product, service, or result to satisfy an agreement or other formally imposed specification
Quantified and documented needs and expectations of the sponsor, customer and other stakeholders
20
How are requirements obtained?
Elicited (asked for), analyzed, and recorded in enough detail to be included in the scope baseline and to be measured once project execution begins
Start by analyzing the project charter, stakeholder register and stakeholder management plan
21
Requirements become or are used as:
The foundation of the WBS The basis for:
Cost Schedule Quality Planning Procurement
22
Requirements are categorized into different types
Business Stakeholder needs
Technical Solutions How stakeholder needs will be
implemented
23
Requirements are categorized into different classifications
Business Requirements Higher-level needs of the organization as a
whole, like business issues or opportunities and reasons why the project is undertaken
Stakeholder requirements Describe needs of a stakeholder or
stakeholder group
24
Requirements are categorized into different classifications Solution Requirements
Describe features, functions, and characteristics of the product, service, or result that will meet the business and stakeholder requirements
Functional Describe the behaviors of the product which may
include processes, data and interactions with the product
Nonfunctional Describe the environmental conditions or qualities
required for the product to be effective
25
Requirements are categorized into different classifications Nonfunctional examples include:
Reliability Security Performance Safety Level of Service Supportability Retention/Purge
26
Requirements are categorized into different types or classifications:
Transition Requirements Describe temporary capabilities, such as data
conversion and training requirements, needed to transition from the current “as-is” state to the future “to-be” state
Project Requirements Describe actions, processes, or other conditions the
project needs to meet Quality Requirements
Describe any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment of other project requirements
27
Collect Requirements: Input Scope Management Plan
Provides clarity as to how project teams will determine which type of requirements need to be collected
Requirements Management Plan Provides the processes used to define and document
the stakeholder needs Stakeholder Management Plan
Helps understand stakeholder communications requirements and the level of stakeholder engagement to assess and adapt to the level of stakeholder involvement in requirements activities
28
Collect Requirements: Input
Project Charter High-level project requirements and
product description Stakeholder Register
Defines which stakeholders can provide information on detailed project and product requirements
29
Collect Requirements: Tools and Techniques Interviews Focus Groups Facilitated Workshops Group Creativity Techniques Group Decision Making Techniques Questionnaires and Surveys Observations Prototypes Benchmarking Context Diagrams Document Analysis
30
Collect Requirements: Tools and Techniques
Interviews Ways to discover information from
stakeholders by talking to them directly May be one on one or involve multiple
interviewers Aids in identifying and defining features
and functions
31
Collect Requirements: Tools and Techniques
Focus Groups Gather prequalified stakeholders and SMEs
to learn about their expectations and attitudes about the proposed product service or result
Uses a trained moderator to guide the team through an interactive discussion
Are designed to be more conversational than the one on one interview
32
Collect Requirements: Tools and Techniques Facilitated Workshops
Brings key cross-functional stakeholders together to define product requirements
Build trust, foster relationships, improve communication among participants which leads to increased stakeholder consensus
Supports: Risk identification and mitigation Issue discovery and resolution
33
Collect Requirements: Tools and Techniques Facilitated Workshops…
Participants create business perspective stories to describe functionality and features Who wants What and Why, (but not the How)
…. So that… Joint Application Design (JAD) in SW brings users
and developers together to improve the SW development process
Quality Function Deployment (QFD) in manufacturing helps to determine critical product characteristics and starts by collecting customer needs; aka: the voice of the customer
34
Collect Requirements: Tools and Techniques Group Creativity Techniques organized to
identify project and product requirements Brainstorming – used to generate and collect multiple
ideas Nominal Group Technique – enhanced brainstorming
with a voting process used to rank the most useful ideas gathered during brainstorming
Idea/Mind Mapping Individual brainstorming ideas consolidated and
mapped to show commonalities and differences in understanding
Helps to generate new ideas
35
Collect Requirements: Tools and Techniques Group Creativity Techniques…
Affinity Diagram Ideas generated from other gathering methods are
organized or categorized by similarities and then given a name
Multi-criteria Decision Analysis Uses a decision matrix to provide an objective but
systematic approach for establishing criteria to evaluate and rank many ideas like: Risk levels Uncertainty Business value
36
Collect Requirements: Tools and Techniques
Group Decision Making Technique is: An assessment process of multiple
alternatives with an expected outcome in the form of future actions
Used to generate, classify and prioritize product requirements
37
Collect Requirements: Tools and Techniques Group Decision Making Techniques
Unanimity – everyone agrees on a single course of action. One way to achieve unanimity is to use: Delphi Technique – selects SMEs to answer
questionnaires and provide feedback only available to the facilitator to maintain anonymity regarding responses from each round of requirements gathering
Majority – support for more than 50% Plurality – the largest block in the group decides even
if a majority is not achieved Dictatorship – one individual makes the decision for
the group
38
Collect Requirements: Tools and Techniques
Questionnaires and Surveys Written set of questions designed to
quickly obtain accurate information from a wide number of respondents
Used with broad audiences when quick turnaround is needed and where statistical analysis is appropriate
39
Collect Requirements: Tools and Techniques Observations
Viewing workers in their environment and how they perform their jobs or tasks and carry out processes
Helpful when the people have difficulty or are reluctant to articulate their requirements
Job shadowing Done externally by the observer viewing the user
doing the job Done by a participant observer who actually performs
a process or procedure to experience how work is done to uncover hidden requirements
40
Collect Requirements: Tools and Techniques Prototypes
Method used to get early feedback on requirements by providing a working model of the expected product before building it
Lets stakeholders experiment with a model of the final product rather than talking about concepts
Supports the concept of progressive elaboration and used in iterative cycles
When feedback cycle are done requirements obtained are sufficient to build the product
41
Collect Requirements: Tools and Techniques Benchmarking
Involves comparing actual or planned practices, such as processes and operations, to those of comparable internal or external organizations to identify best practices, generate ideas for improvement, and provide a basis for measuring performance
42
Collect Requirements: Tools and Techniques Context Diagrams
Visually depict the product scope by showing a business system (process, equipment, computer system, etc.), and how people and other systems (actors) interact with it.
Show inputs to the business system, the actor(s) providing the input, the outputs from the business system, and the actor(s) receiving the output
43
44
Collect Requirements: Tools and Techniques Document Analysis
Elicit requirements by analyzing existing documentation and identifying information relevant to the requirements
Examples Business plans, marketing literature, agreements,
requests for proposal, current process flows, logical data models, business rules repositories, application software documentation, business process or interface documentation, use cases, other requirements documentation, problem/issue logs, policies, procedures, and regulatory documentation such as laws, codes, or ordinances
45
Collect Requirements: Outputs Requirements
A condition or capability that must be met Quantified and documented needs, wants, and
expectations of the sponsor, customer and other stakeholders
Requirements Document Requirements Traceability Matrix
46
Collect Requirements: Outputs Requirements Documentation
Describes how individual requirements meet the business need for the project
Start out at a high level and become progressively more detailed as more is known (progressively elaborated)
Must be measurable and testable, traceable, complete, consistent and acceptable to key stakeholders
Format may range from a simple listing categorized by stakeholder and priority, to more elaborate forms containing executive summary, detailed descriptions and attachments
47
Requirements documentation can include but is not limited to: Business need or opportunity with limitations and why project
is being done Business/project objectives for traceability Functional requirements describing business processes Non-functional requirements like level of service, performance,
safety, security, scalability Quality requirements Acceptance criteria Business rules stating organization guiding principles Impacts to other organization areas like call center, sales force,
technology groups Impacts to other entities in/outside the company Support and training requirements Requirements assumptions and constraints
48
Requirements Traceability Matrix A table/grid that links requirements to their origin
and traces them throughout the project life cycle Helps ensure that each requirement adds
business value by linking it to the business and project objectives
Provides a means to track each requirement and ensure it’s delivered
Provides a structure for managing changes to product scope
49
Requirements Traceability Matrix Process includes tracing requirements to:
Business needs, opportunities, goals and objectives
Project Objectives Project Scope/WBS deliverables Product Design Project Development Test Strategy and Scenarios More detailed requirements from high level
requirements
50
Requirements Traceability Matrix Attributes Help define key information about the requirement Typical attributes used may include a:
Unique identifier Textual description Rationale for inclusion Owner or Source Priority Version or Current Status (active, cancelled, deferred,
added, approved) and the date completed Others ensure stakeholder satisfaction and may include
stability, complexity and acceptance criteria
51
52
Project Name
Network Builders Route Manager
Business Area Network Provisioning
Project Manager
Lisa Doe Business Analyst Lead B. Williams
Systems Analyst
J. Doe Target Deploy Date 09/30/97
Req#Requirements Description
Charter Reference
High Level Design
Reference
Detail Design Document
Test Case Reference
User Accceptanc
e Testing Reference
Comments
1 Model circuit equipment PC-1.1 HLD001-010 DDD001-050 TC001-10 UAT001-10Extremely complex, requires Equipment Designer
2 Produce capacity reports PC-1.2 HLD011-020 DDD051-100 TC011-20 UAT011-20Get input from Provisioning Engineer
3Produce circuit routing reports PC-2.1 HLD020-030 DDD101-200 TC021-30 UAT021-30
Consult with Sales, Provisioning, Distribution
4Produce task order report PC-2.2 HLD031-040 DDD201-300 TC031-40 UAT031-40
Ensure Provisioning Manager has input
5Create work order instructions PC-2.3 HLD041-050 DDD301-400 TC041-50 UAT041-50
Ensure Provisioning Manager has input
6Manage work order status PC-2.4 HLD051-060 DDD401-500 TC051-60 UAT051-60
Consult with Lead Provision Engineer
7 Find network capacity PC-3.1 HLD061-070 DDD501-600 TC061-70 UAT061-70Benchmark time required to execute
8 Provision circuits PC-3.1 HLD071-080 DDD601-700 TC071-80 UAT071-80 Benchmark response time
Requirements Traceability Matrix
Define Scope Since all of the requirements identified in Collect
Requirements may not be included in the project this process describes the project, service or result boundaries by defining which of the requirements will be included and excluded from the project scope
Develops a detailed description of the project and product
53
DFD
54
Define Scope Critical to project success Builds upon the major deliverables,
assumptions, and constraints that are documented during project initiation in the project charter
Defined and described with greater specificity as more information about the project is known
Used to divide the project work into activities to which we can assign resources
Assumptions/constraints are analyzed for completeness and updated as necessary
55
Define Scope: Inputs
Scope Management Plan Establishes activities for developing, monitoring and
controlling project scope Project Charter
Contains high-level project description and product characteristics
Requirements Documentation Used to select the requirements that will be included
in the project Organizational Process Assets
Policies, procedures, templates, past project/phase files and lessons learned
56
Define ScopeTools and Techniques:
Expert Judgment Product Analysis Alternatives Identification Facilitated Workshops
57
Define ScopeTools and Techniques:
Expert Judgment Each area has experts who can develop
portions of the detailed project scope statement Software Assurance Testing Finance Billing etc
58
Define ScopeTools and Techniques:
Product Analysis Methods for translating project objectives
and/or product descriptions into tangible deliverables
Includes techniques such as product breakdown, systems analysis, requirements analysis, systems engineering, value engineering and value analysis
59
Define ScopeTools and Techniques: Alternatives Identification
A technique used to generate various approaches to execute and perform project work such as: Brainstorming Lateral thinking
Look at the components of the problem from different angles to devise a solution or approach
Encourage team to come up with different ways to solve the problem that aren’t apparently obvious
60
Define Scope Output:Project Scope Statement An agreement between the project and the project
customer that states precisely what the work of the project will produce; Further it: Describes the project's objectives, deliverables,
assumptions, constraints and the work required to create them
Provides a common understanding of the project scope among all project stakeholders
May contain explicit project 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 Provides the baseline for evaluating whether requests for
changes or additional work are contained within or outside the project's boundaries
61
Define Scope: OutputDegree and Level of Detail Can help determine how well the project
management team can control the overall project scope
Directly or indirectly includes: Product Scope Description Acceptance Criteria Deliverable Project Exclusion Constraint Assumptions
62
Define Scope: Output Degree and Level of Detail Product Scope Description
Progressively elaborates the characteristics of the product service or result described in the project charter and requirements documentation
Acceptance Criteria Required conditions to be met before deliverables are
accepted Deliverable
A unique verifiable product, result or capability to perform a service to be produced to complete a process, phase or project.
Includes ancillary results like management reports and documentation
63
Define Scope: OutputDegree and Level of Detail Project Exclusion
Generally identifies what is excluded from the project Explicitly stating this helps to manage expectations
Constraints Limiting factor(s) that affect the execution of a project
or process, like predefined budgets, imposed dates, etc. Contractual provisions
Assumptions Factors in the planning process that are considered to
be true, real, or certain, without proof or demonstration and the potential impact of those factors if they prove to be false
64
Define Scope Output:Elements of the Project Charter and Project Scope Statement
Project charter and project scope statement are sometimes perceived redundant, but are different in the level of detail contained in each Project charter contains high-level
information Project scope statement contains a detailed
description of the scope elements which are progressively elaborated throughout the project
65
Define Scope Output:Elements of the Project Charter and Project Scope Statement
66
Define Scope Output:Scope Statement Components
Product Scope Description Product Acceptance Criteria Project Deliverables Project Exclusions Project Constraints
67
Define Scope Output:Scope Statement Components
Product Scope Description Describes the characteristics of the
product, service, or result that the project was undertaken to create
These characteristics will generally have less detail in early phases and more detail in later phases as the product characteristics are progressively elaborated
68
Define Scope Output:Scope Statement Components
Product Acceptance Criteria Defines the process and criteria for
accepting completed products
69
Define Scope Output:Scope Statement Components
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
Depending on the project scope statement, the deliverables may be described at a summary level or in great detail
70
Define Scope Output:Scope Statement Components
Project Exclusions States explicitly what is excluded from
the project
71
Define Scope Output:Scope Statement Components
Project Constraints Lists and describes the specific project
constraints associated with the project scope that limit the team's options
For example: Predefined budget Any imposed dates (schedule milestones) that
are issued by the customer or performing organization
For a project performed under contract, contractual provisions will generally be constraints
72
Define Scope Output:Scope Statement Components 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
Project teams frequently identify, document, and validate assumptions as part of their planning process Try to validate your assumptions wherever possible Make vendors put their assumptions in writing If services or goods you are expecting to be delivered
by suppliers are critical to the project, include a clause in the contract to assure a contingency plan in case your suppliers fail to perform
Remember when assumptions are incorrect or not documented, they may cause problems halfway through the project and may even be a project killer
73
Define Scope Output:
Project Document Updates Stakeholder Register Requirements Documentation Requirements Traceability Matrix
74
Approving and Publishing the Project Scope Statement
The project scope statement should be: approved, agreed upon, and distributed to
Stakeholders, Key management personnel and Project team members
Signoff signifies agreement to the project deliverables and requirements and ensures participation from those providing signature
75
So Far… Everything done so far builds on a previous step
Project Charter Outline the project goals and major deliverables
Project Scope Statement Further refines these deliverables into an exhaustive list
and Documents the requirements of the deliverables
Now we’ll use that comprehensive list of deliverables To build the framework of the WBS
Work performed so far is very important
76
Create WBS Process of subdividing project
deliverables and project work into smaller, more manageable components
Provides a structured vision of what has to be delivered
77
Create WBS It’s like creating a family tree It’s a deliverable oriented hierarchical
decomposition of the work to be executed by the project team
It represents the total scope of the project Defines the work of the project and only the
work of the project Like the scope statement it serves as a
foundational agreement among the stakeholders and project team members regarding the project scope
78
Work Breakdown Structure The WBS is only as accurate as your list of
deliverables The deliverables will become the groupings
that will form the higher levels of the WBS from which all activities will be derived later in the Planning Process
This breakdown provides a foundation for estimating project cost and time, scheduling resources, and determining quality controls
Project progress will be based on estimates and measurements assigned to the WBS segments
79
WBS Input: Scope Management Plan
How to create the WBS and how it will be maintained and approved
Project Scope Statement Describes the work that will be performed and any
exclusions Requirements Documentation
Describes what needs to be produced as a result of the project and what needs to be done to deliver the project and it’s final products
Enterprise Environmental Factors Organizational Process Assets
80
WBS: Decomposition Tools and Techniques
Decomposition Expert Judgment
81
WBS: Decomposition Tools and Techniques
Decomposition Is the subdivision of project scope and project
deliverables into smaller, more manageable parts
The work package is the work defined at the lowest/last level of the WBS segment where in which work may be more easily scheduled, estimated (cost and time), monitored and controlled
The level of detail for work packages will vary with the size and complexity of the project
82
WBS: Decomposition…Tools and Techniques Work for some deliverables needs to be
decomposed only to the next level As the work is decomposed to lower levels of
detail, the ability to plan, manage, and control the work is enhanced
Each level of the WBS is more detailed than the one above it
83
WBS: Decomposition yields…Tools and Techniques Improved estimating because it’s
easier to Estimate costs, time and resources for an
individual work component Assign performance measures and
controls, thus providing a baseline to compare against during the entire project phase
Assign resources, responsibility and skill sets for individual components
84
WBS Decomposition Involves: (5 steps)Tools and Techniques
Identifying and analyzing the deliverables and related work
Structuring and organizing the WBS Decomposing the upper WBS levels into lower-
level detailed components like deliverables and requirements and responsible organization
Assigning identification codes/numbers to the WBS components for clarity
Verifying that the degree of decomposition of the deliverables is appropriate
85
Constructing the WBS
There’s no right way to construct a WBS
Chart structure is most common Outline form is used as well
86
Organizing the WBS may be done in:
Phases Major Deliverables Or combination of both above
87
WBS Decomposed Down Through Work Packages
88
WBS Organized by Phase
89
WBS Organized by Major Deliverables
90
Rolling Wave Planning Sometimes when working on large projects that consists
of several subcomponents, some of the subcomponents may not be scheduled to be worked on until a future date
It makes sense to develop the WBS in detail at that future date when deliverables and subcomponents are better known and more details are available
This technique is known as rolling wave planning. The idea behind this technique is that you elaborate the
work of the project to the level of detail you know about at the time
All work at the lower levels should aggregate to the higher levels so nothing is left out – knows as the 100% rule
91
Create WBS: Output
Scope Baseline – only changed through formal change control procedures and is used as a basis for comparison Approved version of the scope statement WBS WBS Dictionary
Project Document Updates
92
Create WBS: Output
Project Scope Statement Includes the description of the project
scope, major deliverables, assumptions, and constraints
93
Create WBS: WBS Output
Hierarchical decomposition of the total scope of the work Each descending level increases in detail definition of the work Is finalized by assigning each work package to a control account
and establishing a unique identifier for that work package from a code of accounts
The identifiers provide a structure for hierarchical summation of costs, schedule and resource information
A control account is a management control point where scope, budget, actual cost and schedule are integrated and compared to the earned value for performance measurement
Control accounts are placed at selected management points in the WBS
A control account may contain 1 or more work packages, but each work package should only be related to only one control account
94
WBS Dictionary
Code of accounts identifier Description of the work of the components Responsible organization List of scheduled milestones Schedule activities Required resources Cost estimates Quality requirements Criteria for acceptance Technical references Contract information
WBS: Project Document UpdatesOutput
Requirements documentation, may need to be updated to include approved changes
96
Understanding WBS Levels Project complexity determines number
of levels Level 1 - project name level Level 2 - first level of decomposition may
be deliverables, phases or subcomponents
Levels that follow show more and more detail and may include more deliverables
97
Project Name
2.0
3.0
1.0
1.1
1.2
2.1
3.2
3.3
3.1
1.1.1
1.1.2
1.1.1.1
1.1.1.2
1.1.2.1
1.1.1.2.1
1.1.1.2.2
1.1.1.2.1.1
1.1.1.2.1.2
2.1.1
2.1.2
2.1.1.1
2.1.1.2
2.1.2.1
2.1.1.2.1
2.1.1.2.2
2.1.2.2
Work Package
Control Account
Level 1
Level 2
Level 3
Level 4
Level 5
Level 6
Level 7
Control Accounts
Permits for the aggregation of work Provides a method of managing and
controlling: Scope, Time, Costs, Quality
Each work package is assigned to one and only one control account
A control account may be comprised of multiple work packages
Validate Scope Process of formalizing acceptance of the
completed project deliverables Brings objectivity to the acceptance process Increases the chance of final product, service or
result acceptance by validating each deliverable
100
DFD
101
Validate Scope
Control Quality verified deliverables Reviewed with customer or sponsor and
received formal acceptance Ensured that they are satisfactorily
completed Outputs from planning and executing
process are used as a basis for validation and acceptance
102
Validate Scope vs. Control Quality Control Quality is primarily concerned with
Correctness of the deliverables Meeting the quality requirements specified for the
deliverables Control Quality is generally performed before
Validate Scope, but these two processes may be performed in parallel
Scope Validation is primarily concerned with acceptance of the verified deliverables by the customer from the Control Quality process
103
Validate Scope: Input Project Management Plan
Scope Management Plan - how formal acceptance of completed project deliverables will be obtained
Scope Baseline – used as a bases for comparison Requirements Documentation Requirements Traceability Matrix Validated Deliverables
The deliverables are those that have been fully or partially completed and validated for correctness by the Perform Quality Control process
Work Performance Data Degree of compliance, number/severity of nonconformities,
number of validation cycles performed in a period of time
104
Validate Scope: Tools and Techniques
Inspection Includes activities such as measuring,
examining, and verifying to determine whether work and deliverables meet requirements and product acceptance criteria
Inspections are variously called reviews, product reviews, audits, and walkthroughs
Group Decision-Making Techniques Used to reach a conclusion when validation is
performed by project team and other stakeholders
105
Validate Scope: Output Accepted Deliverables
Completed deliverables that have been accepted Completed deliverables that have not been accepted
along with the reasons for non-acceptance Supporting information received from the customer or
sponsor and acknowledging stakeholder acceptance of the project's deliverables
Change Requests May be generated from the Verify Scope process, and
are processed for review and disposition through the Integrated Change Control process
Project Document Updates Documents updated as a result of this process which
include any document that defines the product or reports status on product completion
106
Control Scope Process of monitoring the status of the
project and product scope and managing changes to the scope baseline
Scope Baseline is maintained throughout the project
107
Control Scope: ITTOs
108
DFD
109
Control Scope Ensures all requested changes and recommended
corrective actions are processed through the project Perform Integrated Change Control process
Used to manage the actual changes when they occur and is integrated with the other control processes
Scope Creep Uncontrolled changes Expansion to product/project scope w/o adjustments to
triple constraints Change control processes are mandatory
110
Control Scope: Input Project Management Plan Requirements Documentation Requirements Traceability Matrix Work Performance Data Organizational Process Assets
111
Control Scope: Input Project Management Plan
Scope Baseline Compared to actual results to determine if a change,
corrective or preventative 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 items that are configurable, those that require
formal change control and the process for controlling changes to such items
112
Control Scope: Input Requirements Documentation
Requirements must be unambiguous, traceable, complete, consistent and acceptable to key stakeholders
Well documented requirements make it easier to detect any deviation in agree upon project and product scope
Requirements Traceability Matrix Helps to detect any impact of any change or deviation
from the scope baseline on the project objectives
113
Control Scope: Input Work performance Data
Can include number of change requests received and or accepted or the number of deliverables completed
Organizational Process Assets Existing formal and informal scope, control
related policies, procedures, guidelines Monitoring and reporting methods and
templates to be used
114
Control Scope:Tools and Techniques
Variance Analysis Project performance measurements
are used to assess the magnitude of variation
Important aspects of project scope control include determining the cause of variance relative to the scope baseline and deciding whether corrective action is required
115
Control Scope: Output Work Performance Information
Correlated and context information on how the project scope is performing compared to the scope baseline
Change Requests The results of project Control Scope can generate requested
changes, which are processed for review and disposition according to the project Integrated Change Control process
Project Management Plan Updates Scope and other baselines
Project Document Updates Requirements documentation and Traceability Matrix
Organizational Process Assets Updates Causes of variances Corrective action chosen and the reasons Other types of lessons learned
116