Project Scope Management

Project Scope Management
Days 1 & 2

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

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

What is scope? Project scope Product 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

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

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

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

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

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

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

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

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

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

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

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

Collect Requirements: ITTO

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

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

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

Requirements become or are used as:
The foundation of the WBS The basis for: Cost Schedule Quality Planning Procurement

Requirements are categorized into different types
Business Stakeholder needs Technical Solutions How stakeholder needs will be implemented

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

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

Nonfunctional examples include: Reliability Security Performance Safety Level of Service Supportability Retention/Purge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Collect Requirements: Outputs
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

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

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

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

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

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

Requirements Traceability Matrix
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 Accceptance Testing Reference Comments 1 Model circuit equipment PC-1.1 HLD DDD TC001-10 UAT001-10 Extremely complex, requires Equipment Designer 2 Produce capacity reports PC-1.2 HLD DDD TC011-20 UAT011-20 Get input from Provisioning Engineer 3 Produce circuit routing reports PC-2.1 HLD DDD TC021-30 UAT021-30 Consult with Sales, Provisioning, Distribution 4 Produce task order report PC-2.2 HLD DDD TC031-40 UAT031-40 Ensure Provisioning Manager has input 5 Create work order instructions PC-2.3 HLD DDD TC041-50 UAT041-50 6 Manage work order status PC-2.4 HLD DDD TC051-60 UAT051-60 Consult with Lead Provision Engineer 7 Find network capacity PC-3.1 HLD DDD TC061-70 UAT061-70 Benchmark time required to execute 8 Provision circuits HLD DDD TC071-80 UAT071-80 Benchmark response time

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

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

Define Scope: Inputs Scope Management Plan Project Charter
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

Define Scope Tools and Techniques:
Expert Judgment Product Analysis Alternatives Identification Facilitated Workshops

Expert Judgment Each area has experts who can develop portions of the detailed project scope statement Software Assurance Testing Finance Billing etc

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

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

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

Define Scope: Output Degree 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

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

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

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

Define Scope Output: Elements of the Project Charter and Project Scope Statement

Define Scope Output: Scope Statement Components
Product Scope Description Product Acceptance Criteria Project Deliverables Project Exclusions Project Constraints

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

Product Acceptance Criteria Defines the process and criteria for accepting completed products

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

Project Exclusions States explicitly what is excluded from the project

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

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

Define Scope Output: Project Document Updates Stakeholder Register
Requirements Documentation Requirements Traceability Matrix

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

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

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

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

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

WBS Input: Scope Management Plan Project Scope Statement
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

WBS: Decomposition Tools and Techniques
Expert Judgment

WBS: Decomposition Tools and Techniques
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

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

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

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

Constructing the WBS There’s no right way to construct a WBS
Chart structure is most common Outline form is used as well

Organizing the WBS may be done in:
Phases Major Deliverables Or combination of both above

WBS Decomposed Down Through Work Packages

WBS Organized by Phase

WBS Organized by Major Deliverables

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

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

Create WBS: Output Project Scope Statement
Includes the description of the project scope, major deliverables, assumptions, and constraints

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

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 Updates Output
Requirements documentation, may need to be updated to include approved changes

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

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

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

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

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

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

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

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

Control Scope: ITTOs

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

Control Scope: Input Project Management Plan
Requirements Documentation Requirements Traceability Matrix Work Performance Data Organizational Process Assets

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

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

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

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

Control Scope: Output Work Performance Information Change Requests
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

Project Scope Management

Similar presentations

Presentation on theme: "Project Scope Management"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Project Scope Management

Similar presentations

Presentation on theme: "Project Scope Management"— Presentation transcript:

Similar presentations

About project

Feedback