Pmbok 4th edition chapter 5 - Project Scope Management

CHAPTER 5

PROJECT SCOPE MANAGEMENT

Ahmad H. Maharma PMP®

Project Scope Management

PM Knowledge Areas & Process Groups

PM Process Groups / KnowledgeArea Processes

Initiating Process Group

Planning Process Group Executing Process Group

Monitoring & Controlling Process Group

Closing Process Group

Project Develop Project Charter Develop Project Management Direct and Manage Project Monitor and Control Project Work Close ProjectProject Management Integration

Develop Project Charter Develop Project Management Plan

Direct and Manage Project Execution

Monitor and Control Project WorkIntegrated Change Control

Close Project

Project Scope Management

Collect requirementsDefine ScopeCreate WBS

Verify ScopeControl Scope

Project Time Define Activity Schedule ControlProject Time Management

ySequence ActivityEstimating ResourceEstimating Duration Develop Schedule

Project Cost Management

Estimating CostBudgeting Cost

Control Cost

Project Quality Management

Quality Planning Perform Quality Assurance Perform Quality Control

Project HR Management

Human Resources Planning Acquire Project TeamDevelop Project TeamManage Project Team

P j t Id tif St k h ld Pl C i ti Di t ib t I f ti P f R tiProjectCommunications Management

Identify Stakeholders Plan Communications Distribute Information Manage stakeholders expectations

Performance Reporting

Project Risk Management

Plan Risk ManagementRisk IdentificationQualitative / Quantitative Risk AnalysisRi k R Pl i

Risk Monitoring and Control

Risk Response Planning

Project Procurement Management

Plan procurement Conduct procurement Administer Contract Close procurement

Project Scope ManagementPlanningProcesses

Monitoring &Controlling Processes

Enter phase/Start project

Exit phase/End project

InitiatingProcesses

ClosingProcesses

ExecutingProcesses

Knowledge Process

M it i & Area Initiating Planning Executing Monitoring & Contol Closing

ScopeCollect RequirementsDefine Scope Verify ScopeScope Define ScopeCreate WBS Control Scope

Project Scope Management• Process to ensure that the project includes all-and-only the work

required, to complete the project successfullyq , p p j y

• Scope can refer to Product Scope & Project Scope

• Scope Management Plan (part of Develop Project Mgmt Plan)How will I do the scope?– How will I do the scope?

– Provides guidance on how project scope will be defines, documented verified managed and controlled by documented, verified, managed, and controlled by project management team• Don’t assume that requirements were determined before project began (not part of the project)

• Attitude to say no to unnecessary scope. It should go to project approval process

PROJECT SCOPE MANAGEMENT

Project Scope Management:includes the processes required to ensure that theproject includes all the work required, and only thework required, to complete the project successfully.

Managing the project scope is primarily concerned withdefining and controlling what is and is not included inhthe project.

Project Scope Management Processes

5.1 Collect Requirements ‐ The process of defining anddocumenting stakeholders' needs to meet the projectdocumenting stakeholders' needs to meet the projectobjectives.

5.2   Define Scope‐The process of developing a detailed p p p gdescription of the project and product.

5.3 Create WBS‐The process of subdividing projectdeliverables and project work into smaller moredeliverables and project work into smaller, moremanageable components.

5.4 Verify Scope‐The process of formalizing acceptance ofthe completed project deliverables.

5.5 Control Scope‐The process of monitoring the status ofthe project and product scope and managing changes tothe project and product scope and managing changes tothe scope baseline.

Product Scope vs Project Scopeln the project context, the term scope can refer to:

• Product scope. The features and functions that characterize aproduct, service, or result; and/or

• Project scope. The work that needs to be accomplished toj p pdeliver a product, service, or result with the specified featuresand functions.

Product Scope vs Project ScopeThe processes used to manage project scope, as well as thesupporting tools and techniques, vary by application area andare usually defined as part of the project Lifecycleare usually defined as part of the project Lifecycle.

The approved detailed project scope statement and itspp p j passociated WBS and WBS dictionary are the scope baseline forthe project.

This baseline scope is then monitored, verified, and controlledthroughout the lifecycle of the projectthroughout the lifecycle of the project.

Product Scope vs Project ScopeCompletion of the project scope is measured against the projectmanagement plan (Section 4.2.3.1).

Completion of the product scope is measured against theproduct requirements (Section 5.1).p q ( )

The Project Scope Management processes need to be wellintegrated with the other Knowledge Area processes, so thatthe work of the project will result in delivery of the specifiedproduct scope.product scope.

Collect Requirements

5.1 Collect Requirements

Collect Requirements is the process of defining anddocumenting stakeholders' needs and expectations to meet thedocumenting stakeholders needs and expectations to meet theproject objectives.

The project's success is directly influenced by the care taken incapturing and managing project and product requirements.Requirements include the quantified and documented needsRequirements include the quantified and documented needsand expectations of the sponsor, customer, and otherstakeholders.

5.1 Collect RequirementsTh i d b li i d l d d d dThese requirements need to be elicited, analyzed, and recordedin enough detail to be measured once project execution begins.

Requirements become the foundation of the•WBS.•Cost•Schedule•and quality planningare all built upon these requirements.

The development of requirements begins with an analysis of theinformation contained in the project charter (Section 4 1 3 1)information contained in the project charter (Section 4.1 .3.1)and the stakeholder register (Section 1 0.1 .3,1 ).

5.1.1 Collect Requirements: lnputs.1 Project Charter:The project charter is used to provide thehigh‐level project requirementshigh‐level product description of the project so that detailedproduct requirements can be developedproduct requirements can be developed.

.2 Stakeholder Register:gThe stakeholder register is used to identify stakeholders thatcan provide information on detailed project and product

i trequirements.The stakeholder register is described in Section 10.1 .

5.1.2 Collect Requirements: Tools and Techniques.1 Interviews:

An interview is a formal or informal approach to discoverinformation from stakeholders by talking to them directly.

lt is typically performed by asking prepared and spontaneousquestions and recording the responses. Interviews are oftenconducted "one‐on‐one," but may involve multipleinterviewers and/or multiple interviewees.

Interviewing experienced project participants, stakeholders,and subject matter experts can aid in identifying and definingthe features and functions of the desired project deliverables.

5.1.2 Collect Requirements: Tools and Techniques

.2 Focus groups:

Focus groups bring together prequalified stakeholders and subject matter experts tosubject matter experts to • learn about their expectations • attitudes about a proposed product, service, or result.p p p , ,

trained moderatorguides the group through an interactive discussion, designed to be more conversational than a one‐on‐one interview.

5.1.2 Collect Requirements: Tools and Techniques.3  Facilitated Workshops:

Workshops are considered a primary technique for quickly d fi i f ti l i t d ilidefining cross‐functional requirements and reconciling stakeholder differences. 

Because of their interactive group nature, well‐facilitated sessions can build trust, foster relationships, and improve 

i i h i i hi h l dcommunication among the participants which can lead to increased stakeholder consensus.  

4 Group Creativity Techniques:

5.1.2 Collect Requirements: Tools and Techniques. 4  Group Creativity Techniques: 

• Brainstorming. A technique used to generate and collect multiple ideas related to project and product requirements.

• Nominal group technique This technique enhances brainstorming• Nominal group technique. This 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.

4 Group Creativity Techniques:

5.1.2 Collect Requirements: Tools and Techniques. 4  Group Creativity Techniques: 

• ldea/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. This technique allows large numbers of ideas to be sorted into groups for review and analysis.

Idea/Mind Mapping

5.1.2 Collect Requirements: Tools and Techniques.5 Group Decision Making Techniques:

Group decision making is an assessment process of multiple alternativeswith an expected outcome in the form of future actions resolution. These

h b d l ftechniques can be used to generate, classify,and prioritize product requirements.

There are multiple methods of reaching a group decision, for example:• Unanimity. Everyone agrees on a single course 0f action.• Majority. Support from more than 50% of the members of the group.• Plurality. The largest block in a group decides even if a majority is notachieved.

• Dictatorship. 0ne individual makes the decision for the group.

Almost any of the decision methods described previously can be applied tothe group techniques used in the requirements gathering process.

5.1.2 Collect Requirements: Tools and Techniques.6 Questionnaires and Surveys:

Questionnaires and surveys are written sets of questionsdesigned to quickly accumulate information from a widenumber of respondents.pQuestionnaires and/or surveys are most appropriate withbroad audiences, when quick turnaround is needed, andh i i l l i i iwhere statistical analysis is appropriate.

5.1.2 Collect Requirements: Tools and Techniques

.7 0bservations:

0bservations provide a direct way of viewing individuals intheir environment and how they perform their jobs or tasksand carry out processes ‐ lt is particularly helpful for detailedprocesses when the people that use the product havedifficulty or are reluctant to articulate their requirements.

0bservation, also called "job shadowing," is usually doneexternally by the observer viewing the user performing his orexternally by the observer viewing the user performing his orher job. lt can also be done by a "participant observer" whoactually performs a process or procedureto experience how it is done to uncover hidden requirementsto experience how it is done to uncover hidden requirements.

5.1.2 Collect Requirements: Tools and Techniques.8 Prototypes:

Prototyping is a method of obtaining early feedback oni t b idi ki d l f th t drequirements by providing a working model of the expected

product before actually building it.

Since prototypes are tangible, it allows stakeholders to experimentwith a model of their final product rather than only discussingabstract representations of their requirements.abstract representations of their requirements.

Prototypes support the concept of progressive elaboration becauseth d i it ti l f k tithey are used in iterative cycles of mock‐up creation, userexperimentation, feedback generation, and prototype revision.When enough feedback cycles have been performed, the

b d f h ff lrequirements obtained from the prototype are sufficientlycomplete to move to a design or build phase.

5.1.3 Collect Requirements Outputs.1 Requirements Documentation:

Requirements documentation describes how individualrequirements meet the business need for the projectrequirements meet the business need for the project.Requirements may start out at a high level and becomeprogressively more detailed as more is known.

Before being baselined, requirements must be unambiguous(measurable and testable), traceable, complete, consistent,( ), , p , ,and acceptable to key stakeholders.

The format of a requirements document may range from aThe format of a requirements document may range from asimple document listing all the requirements categorized bystakeholder and priority, to more elaborate forms containingexecutive summary detailed descriptions and attachmentsexecutive summary, detailed descriptions, and attachments.

5.1.3 Collect Requirements OutputsComponents of requirements documentation can include, but, are not limited to:

• 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;

i l i d ibi b i i f i d• Functional requirements, describing business processes, information, and interaction with the product, as appropriate which can be documented textually in a requirements list, in models, or both;

• Nonfunctional requirements, such as level of service, performance, safety, security, compliance, supportability, retention/purge, etc. ;

5.1.3 Collect Requirements Outputs• Quality requirements;

• Acceptance criteria;Acceptance criteria;

• Business rules stating the guiding principles of the organization;

• lmpacts 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 assumptions and constraints.

5.1.3 Collect Requirements Outputs.2 Requirements Management Plan:

The requirements management plan documents how requirements will beThe requirements management plan documents how requirements will beanalyzed, documented, and managed throughout the project.

The phase to phase relationship described in Section 2 1 3 2 stronglyThe phase‐to‐phase relationship, described in Section 2.1.3.2, stronglyinfluences how requirements are managed.

h j h h ff l l i hi f hThe project manager must choose the most effectlve relationship for theproject and document this approach in the requirements management plan.

Many of the requirements management plan components are based on thatrelationship.

Components of the requirements management plan can include but are

5.1.3 Collect Requirements OutputsComponents of the requirements management plan can include, but arenot limited to:

• How requirements activities will be planned, tracked, and reported;q p p

• Configuration management activities such as how changes to theproduct, service, or result requirements will be initiated, how impactswill be analyzed how they will be traced tracked and reported as wellwill be analyzed, how they will be traced, tracked, and reported, as wellas 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 becaptured on the traceability matrix and to which other projectdocuments requirements will be traced.

5.1.3 Collect Requirements Outputs.3 Requirements Traceability Matrix:

The requirements traceability matrix is a table that linksThe requirements traceability matrix is a table that linksrequirements to their origin and traces them throughout theproject life cycle.

The implementation of a requirements traceability matrixhelps ensure that each requirement adds business value byp q ylinking it to the business and project objectives.

It provides a means to track requirements throughout theIt provides a means to track requirements throughout theproject life cycle, helping to ensure that requirementsapproved in the requirements documentation are delivered atthe end of the projectthe end of the project.

Requirement Document• Output of the Collect Requirement process• Helps make sure the requirements clear and unambiguous.

• How will we know if the work we do will acceptability meet this requirement?q

• Rule of thumb (SMART)

S ifi (U bi )– Specific (Unambiguous)– Measurable (How will we know we have finished?)– Achievable (Can we do it?)Achievable (Can we do it?)– Relevant (Is it the right thing to do?)– Timed (When will we do it?)

Define Scope

5.2 Define ScopeDefine Scope is the process of developing a detailed description of theproject and product.

The preparation of a detailed project scope statement is critical to projectsuccess and builds upon the major deliverables, assumptions, and constraintsthat are documented during project initiation.g p j

During planning, the project scope is defined and described with greaterspecificity as more information about the project is knownspecificity as more information about the project is known.

Existing risks, assumptions, and constraints are analyzed for completeness;additional risks assumptions and constraintsadditional risks, assumptions, and constraintsare added as necessary.

5.2.1 Define Scope: inputsj h.1 Project Charter:

The project charter provides the high‐level project description andd t h t i ti lt l t i j t lproduct characteristics. lt also contains project approval

requirements.

2 Requirements Documentation:.2 Requirements Documentation:Described in Section 5.1 .3.1 .

3 organizational Process Assets:.3 organizational Process Assets:Examples of organizational process assets that can influence theDefine Scope process include, but are not limited to:• Policies procedures and templates for a project scope• Policies, procedures, and templates for a project scopestatement,

• Project files from previous projects, and• Lessons learned from previous phases or projectsLessons learned from previous phases or projects.

5.2.2 Define Scope: Tools and Techniques.1 Expert Judgment:

Expert judgment is often used to analyze the informationneeded to develop the project scope statement.Such judgment and expertise is applied to any technicalSuch judgment and expertise is applied to any technicaldetails. Such expertise is provided by any group or individualwith specialized knowledge or training, and is available frommany sources.

5.2.2 Define Scope: Tools and Techniques.2 Product Analysis:

F j t th t h d t d li bl d tFor projects that have a product as a deliverable, as opposed to aservice or result, product analysis can be an effective tool. Eachapplication area has one or more generally accepted methodsfor translating high‐level product descriptions into tangibledeliverables.Product analysis includes techniques such asy q• product breakdown• systems analysis• requirements analysis• systems engineering• value engineeringvalue engineering• value analysis.

5.2.2 Define Scope: Tools and Techniques.3 Alternatives ldentification:

ldentifying alternatives is a technique used to generatediff t h t t d f th k f thdifferent approaches to execute and perform the work of theproject.A variety of general management techniques can be usedy g g qsuch as brainstorming, lateral thinking, pair wise comparisons,etc.

. 4 Facilitated Workshops:Described in Section 5.1.2.3.Described in Section 5.1.2.3.

5.2.3 Define Scope: 0utputs.1 Project Scope Statement:

The project scope statement describes in detail the project'sThe project scope statement describes, in detail, the project sdeliverables and the work required to create those deliverables.

The project scope statement also provides a commonThe project scope statement also provides a commonunderstanding of the project scope among project stakeholders.

I i li i l i h i i iIt may contain explicit scope exclusions that can assist in managingstakeholder expectations.

It enables the project team to perform more detailed planning,guides the project team's work during execution, and provides thebaseline for evaluating whether requests for changes or additional

k t i d ithi t id th j t' b d iwork are contained within or outside the project's boundaries.

5.2.3 Define Scope: 0utputsThe detailed project scope statement includes, either directly, or by reference to other documents, the following:

• Product scope description. Progressively elaborates thecharacteristics of the product, service, or result described in the

j h d i d iproject charter and requirements documentation.

• Product acceptance criteria. Defines the process and criteria forp paccepting completed products, services, or results.

P j t d li bl D li bl i l d b th th t t th t• Project deliverables. Deliverables include both the outputs thatcomprise the product or service of the project, as well as ancillaryresults, such as project management reports and documentation.h d l bl b d b d l lThe deliverables may be described at a summary level or in greatdetail.

5.2.3 Define Scope: 0utputs

• Project exclusions. Generally identifies what is excluded as from theproject. Explicitly stating what is out of scope for the project helps tomanage stakeholders' expectations.

• Project constraints. Lists and describes the specific project constraintsassociated with the project scope that limits the team's options, forexample a predefined budget or any imposed dates or scheduleexample, a predefined budget or any imposed dates or schedulemilestones that are issued by the customer or performing organization.When a project is performed under contract, contractual provisions willgenerally be constraints. Information on constraints may be listed in theg y yproject scope statement or in a separate log.

• Project assumptions. Lists and describes the specific project assumptionsassociated with the project scope and the potential impact of thoseassumptions if they prove to be false. Project teams frequently identify,document, and validate assumptions as part of their planning process.

5.2.3 Define Scope: 0utputs.2  Proiect Document Updates

Project documents that may be updated include, but are not li it d tlimited to:

• Stakeholder registerStakeholder register,• Requirements documentation, and• Requirements traceability matrix.q y

5.3 Create WBSCreate WBS is the process of subdividing project deliverables andproject work into smaller, more manageable components.

The work breakdown structure (WBS) is a deliverable‐orientedhierarchical decomposition of the work to be executed by thep yproject team to accomplish the project objectives and create therequired deliverables, with each descending level of the WBSrepresenting an increasingly detailed definition of the projectrepresenting an increasingly detailed definition of the projectwork.

• WBS does not show dependencies• Dividing work package into activities is part of the time management process

(Define Activities)

Project Scope Management

5.3 Create WBS

The WBS organizes and defines the total scope of the project, and representsthe work specified in the current approved project scope statement.p pp p j p

The planned work is contained within the lowest level WBS components, which are called work packageswhich are called work packages.

A work package can be scheduled, cost estimated, monitored, and controlled. 

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.

How do you eat an elephant?How do you eat an elephant?

“BITE”

“BITE”

“BITE”

“BITE”

“BITE” “BITE”

“BITE”“BITE”

“BITE” “BITE”

BITE“BITE”

Breakdown the ScopeBreakdown the Scope

“BITE”

Freezer

BITE“BITE”

Breakdown the Scope to the Next Level

“BITE” “BITE”

“BITE”“BITE”

Freezer

Work Breakdown StructureWork Breakdown StructureCanoe Trip to

Boundary Watersy

Arrange Travel Get Equipment Prepare BudgetPlan Meals

S h d l Fli ht t M l C t t BW O tfitt B i ki A i B d t P

Plan for Emergencies Plan Activities

Obtain CSchedule Flights to Mpls

Rent Van

Contact BW Outfitter Bring cooking gear

Freeze dry food

Assign Budget Person

Get depositsRent canoes

Obtain emerg. #’s

Arrange contact at BW

Bring Cards

Bring Joke book

Arrange Motel

Schedule return flights

Retain Receipts

Pay for supplies

Rent Tents

Bring Sleeping Bags

Prepare 7 breakfasts

Prepare 7 lunches

Bring emerg. flares

Bring two first aid kits

Bring scotch

Close-out tripBring Fishing Gear Prepare 6 dinners

Bring lights and waterproof

matches

Work Breakdown StructureWork Breakdown StructureCanoe Trip to

Boundary Watersy

Arrange Travel Get Equipment Prepare BudgetPlan Meals

S h d l Fli ht t M l C t t BW O tfitt B i ki A i B d t P

Plan for Emergencies Plan Activities

Obtain CSchedule Flights to Mpls

Rent Van

Contact BW Outfitter Bring cooking gear

Freeze dry food

Assign Budget Person

Get depositsRent canoes

Obtain emerg. #’s

Arrange contact at BW

Bring Cards

Bring Joke book

Arrange Motel

Schedule return flights

Retain Receipts

Pay for supplies

Rent Tents

Bring Sleeping Bags

Prepare 7 breakfasts

Prepare 7 lunches

Bring emerg. flares

Bring two first aid kits

Bring scotch

Close-out tripBring Fishing Gear Prepare 6 dinners

Bring lights and waterproof

matches

Work Breakdown StructureWork Breakdown StructureCanoe Trip to

Boundary Watersy

Arrange Travel Get Equipment Prepare BudgetPlan Meals

S h d l Fli ht t M l C t t BW O tfitt B i ki A i B d t P

Plan for Emergencies Plan Activities

Obtain CSchedule Flights to Mpls

Rent Van

Contact BW Outfitter Bring cooking gear

Freeze dry food

Assign Budget Person

Get depositsRent canoes

Obtain emerg. #’s

Arrange contact at BW

Bring Cards

Bring Joke book

Arrange Motel

Schedule return flights

Retain Receipts

Pay for supplies

Rent Tents

Bring Sleeping Bags

Prepare 7 breakfasts

Prepare 7 lunches

Bring emerg. flares

Bring two first aid kits

Bring scotch

Close-out tripBring Fishing Gear Prepare 6 dinners

Bring lights and waterproof

matches

Work Breakdown StructureWork Breakdown StructureCanoe Trip to

Boundary Watersy

Arrange Travel Get Equipment Prepare BudgetPlan Meals

S h d l Fli ht t M l C t t BW O tfitt B i ki A i B d t P

Plan for Emergencies Plan Activities

Obtain CSchedule Flights to Mpls

Rent Van

Contact BW Outfitter Bring cooking gear

Freeze dry food

Assign Budget Person

Get depositsRent canoes

Obtain emerg. #’s

Arrange contact at BW

Bring Cards

Bring Joke book

Arrange Motel

Schedule return flights

Retain Receipts

Pay for supplies

Rent Tents

Bring Sleeping Bags

Prepare 7 breakfasts

Prepare 7 lunches

Bring emerg. flares

Bring two first aid kits

Bring scotch

Close-out tripBring Fishing Gear Prepare 6 dinners

Bring lights and waterproof

matches

Work Breakdown StructureWork Breakdown Structure

System Hardware Replacement

RFP Development Vendor Selection Hardware ImplementationStaff TrainingRFP Development Vendor Selection Hardware ImplementationStaff Training

Needs Assessment

Needs Analysis

Research Vendors

Research Sites

Identify training Plan

Schedule Training

Schedule Installation

Prepare Site

Write RFP

Finalize with Purchasing

Select Vendors to mail RFP

Review Proposals

Train Arrange Vendor Support

Rank Proposals

Configure System

Install SystemRank Proposals

Recommendation

Install System

Work Breakdown StructureWork Breakdown Structure

System Hardware Replacement

RFP Development Vendor Selection Hardware ImplementationStaff TrainingRFP Development Vendor Selection Hardware ImplementationStaff Training

Assess Needs

Analyze Needs

Research Vendors

Research Sites

Identify training Plan

Schedule Training

Schedule Installation

Prepare Site

Write RFP

Finalize with Purchasing

Select Vendors to mail RFP

Review Proposals

Train Sysadmins Arrange Vendor Support

Rank Proposals

Configure System

Install SystemRank Proposals

Make Recommendations

Install System

Work Breakdown StructureWork Breakdown Structure

• Requires structured brainstormingRequires structured brainstorming

WBS Sample

Image Source: Practice Standard for WBS 2nd Edition. PMI © 2006

Project Scope Management

Project Scope Management

Project Scope Management

5.3.1 Create WBS: lnputs

.1 Project Scope StatementDescribed in Section 5.2.3.1 .

.2 Requirements DocumentationDescribed in Section 5 1 3 1Described in Section 5.1.3.1.

.3 Organizational Process Assets:.3  Organizational Process Assets:The organizational process assets that can influence the Create WBS process include, but are not limited to:• Policies, procedures, and templates for the WBS,• Project files from previous projects, and

l d f• Lessons learned from previous projects.‐

5.3.2 Create WBS: Tools and Techniques.1 Decomposition

Decomposition is the subdivision of project deliverables intoll bl t til th k dsmaller, more manageable components until the work and

deliverables are defined to the work package level.

The work package level is the Iowest level in the WBS, and isthe point at which the cost and activity durations for the work

b li bl i d d dcan be reliably estimated and managed.

The level of detail for work packages will vary with the sizeThe level of detail for work packages will vary with the sizeand complexity of the project.

5.3.2 Create WBS: Tools and TechniquesThe WBS structure can be created in a number of forms, such as:

• Using phases of the project life cycle as the first level ofdecomposition, with the product and project deliverablesinserted at the second level, as shown in Figure 5‐9;, g ;

• Using major deliverables as the first level of decomposition, asshown in Figure 5‐l 0; and

U i b j t hi h b d l d b i ti• Using subprojects which may be developed by organizationsoutside the project team, such as contracted work. The sellerthen develops the supporting contract work breakdownstructure as part of the contracted work.

5.3.2 Create WBS: Tools and TechniquesAs the work is decomposed to greater levels of detail, the ability toplan, manage, and control the work is enhanced.

However, excessive decomposition can lead to non‐productivemanagement effort, inefficient use of resources, and decreasedffi i i f i h kefficiency in performing the work.

The WBS represents all product and project work, including the projectmanagement work.

The total of the work at the lowest levels must roll up to the higherThe total of the work at the lowest levels must roll up to the higherlevels so that nothing is Left out and no extra work is completed.

This is sometimes called the 100% rule.

5.3.2 Create WBS: Tools and TechniquesDecomposition may not be possible for a deliverable or subprojectthat will be accomplished far into the future.

The project management team usually waits until the deliverable orsubproject is clarified so the details of the WBS can be developed.

This technique is sometimes referred to as “rolling wave planning”.

5.3.3 Create WBS: 0utputs. 1 WBS:

The WBS is a deliverable‐oriented hierarchical decompositionf th k t b t d b th j t t t li hof 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 anincreasingly detailed definition of the project work.

Th WBS i fi li d b bli hi l f hThe WBS is finalized by establishing control accounts for thework packages and a unique identifier from a code ofaccounts.

These identifiers provide a structure for hierarchicalf h d l d fsummation of costs, schedule, and resource information.

5.3.3 Create WBS: 0utputsA control account is a management control point where scope,cost, and schedule are integrated and compared to the earnedvalue for performance measurementvalue for performance measurement.

Control accounts are placed at selected management points inp g pthe WBS.

Each control account may include one or more work packages,but each of the work packages must be associated with onlyone control account.one control account.

2 WBS Di ti

5.3.3 Create WBS: 0utputs.2 WBS Dictionary:

The WBS dictionary is a document generated by the Create WBS process thatsupports the WBS. The WBS dictionary provides more detailed descriptions of thecomponents in the WBS, including work packages and control accounts.components in the WBS, including work packages and control accounts.lnformation in the WBS dictionary includes, but is not limited to:

Code of account identifierDescription of workDescription of work,Responsible organizationList of schedule milestones,Associated schedule activitiesAssociated schedule activities,Resources required,Cost estimates,Quality requirementsQuality requirements,Acceptance criteria,Technrcal references, andContract informationContract information.

Project Scope Management

WBS Dictionary Sample

Image Source: Practice Standard for WBS 2nd Edition. PMI © 2006

WBS Dictionary Sample (2)

Source: http://www.brighthub.com/office/project-management/articles/52388.aspx

5.3.3 Create WBS: 0utputs.3 Scope Baseline:The scope baseline is a component of the project  

t l C t f th b li i l dmanagement plan. Components of the scope baseline include:• Project scope statement. The project scope statement includes the product scope description, the project p p p , p jdeliverables and defines the product user acceptance criteria.WBS Th WBS d fi h d li bl d h• WBS. The WBS defines each deliverable and the decomposition of the deliverables into work packages.

• WBS dictionary. The WBS dictionary has a detailedWBS dictionary. The WBS dictionary has a detailed description of work and technical documentation for each WBS element.

5.3.3 Create WBS: 0utputs.4  Project Document Updates:

Project documents that may be updated include, but are not limited to requirements documentation.

lf approved change requests result from the Create WBS process, then the requirements documentation may need to be updated to include approved changes.

5.4 Verify Scope

Verify Scope is the process of formalizing acceptance of thel t d j t d li blcompleted project deliverables.

Verifying scope includes reviewing deliverables with theVerifying scope includes reviewing deliverables with thecustomer or sponsor to ensure that they are completedsatisfactorily and obtaining formal acceptance of deliverables byhthe customer or sponsor.

5.4 Verify ScopeScope verification differs from quality control

in that scope verification is primarily concerned with acceptanceof the deliverables, while quality control is primarily concernedwith correctness of the deliverables and meeting the qualityg q yrequirements specified for the deliverables.

Quality control is generally performed before scope verification,but these two processes can be performed in parallel.

5.4.1 Verify Scope: inputs.1 Project Management Plan:

The project management plan described in Section 4.2.3.1t i th b li C t f thcontains the scope baseline. Components of the scope

baseline include:• Project scope statement. The project scope statementj p p j pincludes the product scope description, includes the projectdeliverables, and defines the product user acceptancecriteriacriteria.

• WBS. The WBS defines each deliverable and thedecomp0sition of the deliverables into work packages.

• WBS dictionary. The WBS dictionary has a detaileddescription of work and technical documentation for eachWBS elementWBS element.

5.4.1 Verify Scope: lnputs.2 Requirements Documentation:

The requirements documentation Iists all the project, product,t h i l d Oth t f i t th t t btechnical, and Other types of requirements that must bepresent for the project and product, along with theiracceptance criteria.Requirements documentation is described in Section 5.1 .3.1 .

.3 Requirements Traceability Matrix:The requirements traceability matrix links requirements totheir origin and tracks them throughout the project life cycle,which is described in Section 5.1.3,3.which is described in Section 5.1.3,3.

.4 Validated Deliverables:Validated deliverables have been completed and checked forcorrectness by the Perform Quality Control Process.

5.4.2 Verify Scope: Tools and Techniques.1 inspections:

lnspection includes activities such as measuring, examining,and verifying to determine whether work and deliverablesmeet requirements and product acceptance criteria.q p p

inspections are sometimes called reviews, product reviews,audits, and walkthroughs. ln some application areas, thesedifferent terms have narrow and specific meanings.

5.4.3 Verify Scope: Outputs

.1 Accepted Deliverables:Deliverables that meet the acceptance criteria are formally signed offand approved by the customer or sponsorand approved by the customer or sponsor.Formal documentation received from the customer or sponsoracknowledging formal stakeholder acceptance of the project'sdeliverables is forwarded to the Close Project or Phase process (4 6)deliverables is forwarded to the Close Project or Phase process (4.6).

.2 Change Requests:Those completed deliverables that have not been formally accepted aredocumented, along with the reasons for non‐acceptance. Thosedeliverables may require a change request for defect repair.

3 Project Document Updates.3 Project Document UpdatesProject documents that may be updated as a result of the Verify Scopeprocess include any documents that define the product or reportstatus on product completionstatus on product completion.

Project Scope Management

5.5 Control ScopeControl Scope is the process of monitoring the status of the projectand product scope and managing changes to the scope baseline.

Controlling the project scope ensures all requested changes andrecommended corrective or preventive actions are processed throughh P f i d Ch C l ( S i 4 5)the Perform integrated Change Control process (see Section 4.5).

Project scope control is also used to manage the actual changes whenj p g gthey occur and is integrated with the other control processes.

U t ll d h ft f d t j tUncontrolled changes are often referred to as project scope creep.

5.5.1 Control Scope: lnputs.1 Project Management Plan:

The project management plan described in Section 4.2.3,1t i th f ll i i f ti th t i d t t lcontains the following information that is used to control

scope:• Scope baseline: The scope baseline is compared to actualp p presults to determine if a change, corrective action, orpreventive action is necessary.S l Th l• Scope management plan: The scope management plandescribes how the project scope will be managed andcontrolled.

• Change management plan: The change management plandefines the process for managing change on the project.

5.5.1 Control Scope: lnputs• Configuration management plan: The configuration

management plan defines those items that are configurable,those items that require formal change control and thethose items that require formal change control, and theprocess for controlling changes to such items.

• Requirements management plan. The requirementsmanagement plan can includes how requirements activitieswill be planned tracked and reported and how changes towill be planned, tracked, and reported and how changes tothe product, service, or result requirements will be initiated. ltalso describes how impacts will be analyzed and theauthorization levels required to approve these changes;

5.5.1 Control Scope: inputs.2 Work Performance lnformation:

lnformation about project progress, such as whichd li bl h t t d th i d hi hdeliverables have started, their progress and whichdeliverables have finished.

.3 Requirements Documentation:Described in Section 5.1.3.1.

4 Requirements Traceability Matrix:Described in Section 5.1 .3.3.

5.5.1 Control Scope: inputs

.5 0rganizational Process AssetsThe organizational process assets that can influence theControl Scope process include but are not limited to:– Existing formal and informal scope control‐related policiesExisting formal and informal scope control‐related policies,procedures, and guidelines,

– Monitoring and reporting methods to be used.

5.5.2 Control Scope: Tools and Techniques.1 Variance Analysis:

Project performance measurements are used to assess theit d f i ti f th i i l b limagnitude of variation from the original scope baseline.

lmportant aspects of project scope control includelmportant aspects of project scope control includedetermining the cause and degree of variance relative to thescope baseline (Section 5.3.3.3) and deciding whether

i i i i i dcorrective or preventive action is required.

5.5.3 Control Scope:0utputs.1   Work Performance Measurements:

Measurements can include planned vs. actual technical f th f tperformance or other scope performance measurements. 

This information is documented and communicated to stakeholders.

.2  0rganizational Process Assets Updates:0rganizational process assets that may be updated include, but are not limited to:• Causes of variances• Causes of variances,• Corrective action chosen and the reasons, and• other types of lessons learned from project scope control.yp p j p

5.5.3 Control Scope:0utputs.3 Change Requests:

Analysis of scope performance can result in a change requestto the scope baseline or other components of the projectmanagement plan.g p

Change requests can include preventive or correctiveactions or defect repairs.

Change requests are processed for review and dispositionaccording to the Perform lntegrated Change Control process(Section 4.5).( )

5.5.3 Control Scope:0utputs.4 Project Management Plan Updates:

•Scope Baseline Updates. lf the approved change requests have anff t th j t th th t t t th WBSeffect upon the project scope, then the scope statement, the WBS,

and the WBS dictionary are revised and reissued to reflect theapproved changes.

•0ther Baseline Updates. lf the approved change requests have anff t th j t th th di t b li deffect on the project scope, then the corresponding cost baseline and

schedule baselines are revised and reissued to reflect the approvedchanges.g

5.5.3 Control Scope:0utputs

.5 Project Document UpdatesProject documents that may be updated include, but are notlimited to• Requirements documentation andRequirements documentation, and• Requirements traceability matrix.

For more information do not hesitate to contact me.

Ahmad H. Maharma ‐ PMP®

• Ramallah, Palestine Ph (972) (2) 2968644• Phone: + (972) (2) 2968644

• Mobile: + (972) (599) 001155E‐Mail: [email protected]@g