Project Scope Management

Chapter 3: Project Scope Management

Stevbros Training & Consultancy www.stevbros.edu.vn

Copyright@STEVBROS Project Management Fundamentals 1

PMI, PMP and PMBOK are registered marks of the Project Management Ins9tute, Inc.

Overview Ini%a%ng

process group

Planning process group

Execu%ng process group

Monitoring & controlling process group

Closing process group

Project scope management

•  Plan Scope Management

•  Collect Requirements

•  Define Scope •  Create WBS

•  Validate Scope

•  Control Scope


Overview •  In the project context, the term scope can refer to:

–  Product scope. The features and funcQons that characterize a product, service, or result;

–  Project scope. The work performed to deliver a product, service, or result with the specified features and funcQons. The term project scope is someQmes viewed as including product scope.

•  The scope baseline for the project is the approved version of the project scope statement, work breakdown structure (WBS), and its associated WBS dicQonary. A baseline can be changed only through formal change control procedures and is used as a basis for comparison while performing Validate Scope and Control Scope processes as well as other controlling processes.


Plan scope management

•  The process of creaQng a scope management plan that documents how the project scope will be defined, validated, and controlled. The key benefit of this process is that it provides guidance and direcQon on how scope will be managed throughout the project.


A Guide to the Project Management Body of Knowledge, FiBh Edi9on (PMBOK® Guide) ©2013 Project Management Ins9tute, Inc. All Rights Reserved. Figure 5-‐4 Page 111.

Inputs 1.   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

2.   Project Charter •  Output of the Develop Project Charter process

3.   Enterprise Environmental Factors •  Include organizaQon’s culture, infrastructure, personnel administraQon, and marketplace condiQons

4.   Organiza%onal Process Assets •  Include policies and procedures, and historical informaQon and lessons learned knowledge base


Tools and techniques

1.   Expert Judgment •  refers to input received from knowledgeable and experienced parQes. ExperQse may be provided by any group or person with specialized educaQon, knowledge, skill, experience, or training in developing scope management plans.

2.   Mee%ngs •  a\endees at these meeQngs may include the project manager, the project sponsor, selected project team members, selected stakeholders, anyone with responsibility for any of the scope management processes, and others as needed.


Outputs 1.   Scope Management Plan: the components of a scope management plan

include: •  Process for preparing a detailed project scope statement; •  Process that enables the creaQon 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; and •  Process to control how requests for changes to the detailed project scope

statement will be processed. 2.   Requirements Management Plan: components of the requirements

management plan can include: •  How requirements acQviQes will be planned, tracked, and reported; •  ConfiguraQon management acQviQes; Requirements prioriQzaQon process; •  Product metrics that will be used and the raQonale for using them; and •  Traceability structure to reflect which requirement a\ributes will be captured

on the traceability matrix. Copyright@STEVBROS Project Management Fundamentals 7

Collect requirement

•  The process of defining and documenQng all Stakeholders’ needs to meet the project objecQves. This process is criQcal to project success.



Collect requirement -‐ Inputs

1.   Scope Management Plan: provides clarity as to how project teams will determine which type of requirements need to be collected for the project.

2.   Requirements Management Plan: provides the processes to define and document the stakeholder needs.

3.   Stakeholder Management Plan: is used to understand stakeholder communicaQon requirements and the level of stakeholder engagement in order to assess and adapt to the level of stakeholder parQcipaQon in requirements acQviQes.

4.   Project Charter: is used to provide the high-‐level descripQon of the product, service, or result of the project so that detailed requirements can be developed.

5.   Stakeholder Register: is used to idenQfy stakeholders who can provide informaQon on the requirements.


Collect requirement -‐Tools and techniques

(1/2) 1.   Interview: Project manager/ team sits down with stakeholders one-‐

on-‐one to get them to explain exactly what they need so that you can be sure your project can meet its goals.

2.   Focus Group: Prequalified stakeholders and subject ma\er experts. A facilitator to guide the conversaQon. InteracQve discussions.

3.   Facilitated Workshops: Bring key -‐ cross funcQonal stakeholders, reconciling differences, build trust, improve communicaQon, increase stakeholder consensus.

4.   Group Crea%vity Techniques: Brainstorming, Nominal Group Technique, Mind Map, Delphi Technique, Affinity Diagram.

5.   Group Decision-‐Making techniques: Unanimity, majority, plurality and dictatorship.

6.   Ques%onnaires and Surveys: Use a quesQonnaire and/or survey to get requirements from a bigger group of users, customers, or stakeholders.


Collect requirement -‐Tools and techniques

(2/2) 7.   Observa%ons: observes an end user performing the tasks to be

analyzed in the end user’s own environment 8.   Prototypes: are models of the product that you’re going to build that

let your stakeholders get a be\er idea to elicit requirements more effecQvely

9.   Benchmarking: involves comparing actual or planned pracQces, such as processes and operaQons, to those of comparable organizaQons to idenQfy best pracQces, generate ideas for improvement, and provide a basis for measuring performance

10.   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

11.   Document Analysis: is used to elicit requirements by analyzing exisQng documentaQon and idenQfying informaQon relevant to the requirements.


Collect requirement -‐Outputs

1.   Requirements Documenta%on: describes how individual requirements meet the business need for the project: –  Business requirements –  Stakeholder requirements –  SoluQon requirements –  FuncQonal and nonfuncQonal requirements –  Technology and standard compliance requirements –  Support and training requirements –  Quality requirements –  Project requirements –  TransiQon requirements –  Requirements assumpQons, dependencies, and constraints.

2.   Requirements Traceability Matrix: shows the relaQonship between requirements and business objecQves. A requirement that does not map back to an objecQve is deemed as out of scope and must be removed from the list of requirements.


Define scope •  The process of developing a detailed descripQon of the

project and product. The key benefit of this process is that it describes the project, service, or result boundaries by defining which of the requirements collected will be included in and excluded from the project scope.



Inputs 1.   Scope Management Plan

•  Output of the Plan Scope Management process 2.   Project Charter

•  Output of the Develop Project Charter process 3.   Requirements Documenta%on

•  Output of the Collect Requirement process 4.   Organiza%onal Process Assets

•  OrganizaQonal process assets can influence how scope is defined. Examples include, but are not limited to: policies, procedures, and templates for a project scope statement; project files from previous projects; and lessons learned from previous phases or projects.



1.   Expert Judgment •  from many sources: other units within the organizaQon; consultants;

stakeholders, including customers or sponsors; professional and technical associaQons; industry groups; and SMEs.

2.   Product Analysis •  for projects that have a product as a deliverable, product analysis

includes techniques such as product breakdown, systems analysis, requirements analysis, systems engineering, value engineering, and value analysis.

3.   Alterna%ves Genera%on •  is a technique used to develop as many potenQal opQons as possible in

order to idenQfy different approaches to execute and perform the work of the project

4.   Facilitated Workshops •  The parQcipaQon of key players with a variety of expectaQons and/or

fields of experQse helps to reach a cross-‐funcQonal and common understanding of the project objecQves and its limits.


Outputs

1.   Project Scope Statement •  The detailed project scope statement, either directly, or by reference to other documents, includes the following: product scope descripQon, acceptance criteria, deliverables, project exclusion, constraints, assumpQons

2.   Project Documents Updates


Project cha\er vs. project scope statement


A Guide to the Project Management Body of Knowledge, FiBh Edi9on (PMBOK® Guide) ©2013 Project Management Ins9tute, Inc. All Rights Reserved. Table 5-‐1 Page 124.

Create WBS •  The process of subdividing project deliverables and project

work into smaller, more manageable components. The key benefit of this process is that it provides a structured vision of what has to be delivered.



Inputs 1.   Scope Management Plan: output of the Plan Scope

Management process 2.   Project Scope Statement: output of the Define Scope process 3.   Requirements Documenta%on: output of the Collect

Requirement process 4.   Enterprise Environmental Factors: industry-‐specific WBS

standards, relevant to the nature of the project, may serve as external reference sources for creaQon of the WBS. For example, engineering projects may reference ISO/IEC 15288 on Systems Engineering -‐ System Life Cycle Processes [6], to create a WBS for a new project.

5.   Organiza%onal Process Assets: such as policies, procedures, and templates for the WBS; project files from previous projects; and lessons learned from previous projects.



1.   Decomposi%on: is the subdivision of project deliverables into smaller, more manageable components unQl the work and deliverables are defined to the work package level. •  Rolling wave planning: decomposiQon of some deliverables

can be waited unQl uncertainty is clarified. •  Team buy-‐in: is the most valuable result of creaQng a WBS. •  80 hour rule (rule of thumb or heurisQc): work package

should take approximately 80 hours worth of effort to complete.

2. Expert judgment: is onen used to analyze the informaQon needed to decompose the project deliverables down into smaller component parts in order to create an effecQve WBS.


WBS decomposed through work packages



WBS Organized by Phase



WBS with major deliverables



Outputs

1.   Scope Baseline: is the approved version of a scope statement, work breakdown structure (WBS), and its associated WBS dicQonary, that can be changed only through formal change control procedures and is used as a basis for comparison.

2.   Project Document updates: the creaQon of the WBS may result in necessary revisions to certain project documents.


Validate scope •  The process of formalizing acceptance of the completed

project deliverables. The key benefit of this process is that it brings objecQvity to the acceptance process and increases the chance of final product, service, or result acceptance by validaQng each deliverable.




•  contains the scope management plan and the scope baseline. 2.   Requirements Documenta%on

•  output of the Collect Requirement process. 3.   Requirements Traceability Matrix

•  output of the Collect Requirement process. 4.   Verified Deliverables

•  are project deliverables that are completed and checked for correctness through the Control Quality process.

5.   Work Performance Data •  include the degree of compliance with requirements, number of nonconformiQes, severity of the nonconformiQes, or the number of validaQon cycles performed in a period of Qme.



1.   Inspec%on •  includes acQviQes such as measuring, examining, and validaQng to determine whether work and deliverables meet requirements and product acceptance criteria. InspecQons are someQmes called reviews, product reviews, audits, and walkthroughs.

2.   Group Decision-‐Making Techniques •  are used to reach a conclusion when the validaQon is performed by the project team and other stakeholders. The techniques are unanimity, majority, plurality and dictatorship.


Outputs 1.   Accepted Deliverables

•  deliverables that meet the acceptance criteria are formally signed off and approved by the customer or sponsor.

2.   Change Requests •  the completed deliverables that have not been formally accepted are documented, along with the reasons for non-‐acceptance of those deliverables. Those deliverables may require a change request for defect repair.

3.   Work Performance Informa%on •  includes informaQon about project progress, such as which deliverables have started, their progress, which deliverables have finished, or which have been accepted. This informaQon is documented and communicated to stakeholders at the Project CommunicaQon Management.

4.   Project Documents Updates Copyright@STEVBROS Project Management Fundamentals 28

Deliverables vs. Accepted Deliverable

Deliverables Verified

deliverables Accepted

deliverables

Copyright@STEVBROS STEVBROS -‐ Global PMI R.E.P 29

Close Project

Validate Scope

Control Quality

Direct and Manage Project ExecuQon

VerificaQon Acceptance

Control scope •  The process of monitoring the status of the project and

product scope and managing changes to the scope baseline. The key benefit of this process is that it allows the scope baseline to be maintained throughout the project avoid scope creep (details of scope creep at slide 34)




•  the following informaQon from the project management plan is used to control scope: scope baseline; scope management plan; change management plan; configuraQon management plan; and requirements management plan.

2.   Requirements Documenta%on •  output of the Collect Requirement process.

3.   Requirements Traceability Matrix •  output of the Collect Requirement process.

4.   Work Performance Data •  include the number of change requests received, the number of requests

accepted or the number of deliverables completed, etc. 5.   Organiza%onal Process Assets

•  such as exisQng formal and informal scope, control-‐related policies, procedures, guidelines; and monitoring and reporQng methods and templates to be used.



1.   Variance Analysis: –  is a technique for determining the cause and degree of difference between the baseline and actual performance. Important aspects of project scope control include determining the cause and degree of variance relaQve to the scope baseline and deciding whether correcQve or prevenQve acQon is required.


Outputs 1.   Work Performance Informa%on

•  includes correlated and contextualized informaQon on how the project scope is performing compared to the scope baseline. It can include the categories of the changes received, the idenQfied scope variances and their causes, how they impact schedule or cost, and the forecast of the future scope performance

2.   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 prevenQve or correcQve acQons, defect repairs, or enhancement requests

3.   Project Management Plan Updates 4.   Project Documents Updates 5.   Organiza%onal Process Assets Updates Copyright@STEVBROS Project Management Fundamentals 33

Scope creep •  Also called requirement creep, refers to uncontrolled changes or conQnuous

growth in a project’ scope. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered a negaQve occurrence, and therefore should be avoided.

•  Scope creep can be a result of: –  disingenuous customer with a determined "value for free" policy –  poor change control –  lack of proper iniQal idenQficaQon of what is required to bring about the project objecQves –  Weak project manager or execuQve sponsor –  Poor communicaQon between parQes

•  Scope creep is a risk in most projects. Most megaprojects fall vicQm to scope creep. Scope creep onen results in cost overrun. A value for free strategy is difficult to counteract and remains a difficult challenge for even the most experienced project managers.


Summary •  The relaQon among deliverables, validated deliverables and accepted deliverables.

•  The relaQon among the following processes: Direct and Manage Project ExecuQon, Control Quality, Validate Scope, Close Project.

•  The difference between Requirement Document and Scope Statement.

•  The important of Requirement Traceability Matrix in the Validate Scope process.

•  Team buy-‐in, rule of 80 hours, scope creep


QuesQons for review


•  You did the good job at this chapter. Please complete quesQons for review before moving to next chapter.

Project Scope Management

Education

Transcript of Project Scope Management