5 - Project Scope Management

- 5
Unit 5
5 -

Agenda

Project Scope
Management .
Collect Requirements .
Define Scope .
Create Work Breakdown
Structure .
Verify Scope .
Control Scope .

.
.
.

.
.
.

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

:






.
3

5- Project Scope Management

- 5
5.1 Collect Requirements:
The process of defining and documenting
stakeholders needs to meet the project
objectives.

5.2 Define Scope:

The process of developing a detailed
description of the project and product.

5.3 Create WBS:

The process of subdividing project deliverables
and project work into smaller, more
manageable components.

5.4 Verify Scope:

The process of formalizing acceptance of the
completed project deliverables.

5.5 Control Scope:

The process of monitoring the status of the
project and product scope and managing
changes to the scope baseline.

: 5-1

.

: 5-2
.

: 5-3


.

: 5-4

.

: 5-5

.
4

Scope Describes Product & Project - Project Scope

Product Scope :
The features & functions
of what to be produced
( The product to be
delivered ).
Completion is measured
against the
requirements.

Project Scope :
The work required to
deliver the product ( The
project process ).
Completion is measured
against the plan.

:

(
. )
.

.) (

.
5

Why Scope Management ?

Influenced Area : Schedule, Cost, quality, Risks.

. , , :
Influence Curves

Amount of Effort
Required

Potential Savings

Cost To Change

Plan

Design

Life Cycle

Development/
Construction
/

Operation

Demolition
6

Planning is Fortune Telling

Planning is reading the
future.
It is just guessing what is
will happen in the
future.
It is up to the project
manager and project
team to turn this guess
into reality.
The team should not
affect the future, but
should minimize the
chances of going wrong.
The project manager
sometimes acts as the
Fortune Teller.

.

.


.

.
.
:

5.1 Collect Requirements ( Planning )

) ( 5-1
Collect requirements
is the process of
defining and
documenting
stakeholders needs
to meet the project
objectives. They
become the
foundation of the
WBS.

.

.
8

5.1 Collect Requirements

1-5
1. Project charter
2. Stakeholder register

Inputs
. .1
. .2

Outputs

Tools & Techniques

Inputs
1.
2.
3.
4.
5.

Interviews
Focus groups
Facilitated workshops
Group creativity techniques
Group decision making
techniques
6. Questionnaires and surveys
7. Observations
8. Prototypes

Tools & Techniques

.
.
.
.
.
.
.
.

1. Requirements documentation
2. Requirements management
plan
3. Requirements traceability
matrix

Outputs
.1
.2
.3
.4
.5
.6
.7
.8

Source: PMBOK Guide Fourth Edition, page 105

. .1
. .2
. .3

Collect Requirements

Project Charter:
The project charter is used to
provide the high-level project
requirements and high-level
product description of the
project so that detailed
product requirements can be
developed.

Stakeholder Register: The

stakeholder register is used
to identify stakeholders that
can provide information on
detailed project and
product requirements.

:





.
:




10
.

5.1 Collect Requirements

1.5
1.
2.
3.
4.
5.
6.
7.
8.

Interviews
Focus groups
Facilitated workshops
Group creativity
techniques
Group decision
making techniques
Questionnaires and
surveys
Observations
Prototypes

.
.
.
.

.

.
.
.

.1
.2
.3
.4
.5
.6
.7
.811

Interviews

A formal or informal approach to

discover information from
stakeholders by talking to them
directly.
It is typically performed by asking
prepared and spontaneous
questions and recording the
responses.
Interviews are often conducted
one-on-one, but may involve
multiple interviewers and/or
multiple interviewees.
Interviewing experienced project
participants, stakeholders and
subject matter experts can aid in
identifying and defining the
features and functions of the
desired project deliverables.

.


.



/
.




.

12

Focus Groups





.





.
13

Bring together prequalified stakeholders

and subject matter
experts to learn about
their expectations about
a proposed product.
A trained moderator
guides the group through
an interactive discussion,
designed to be more
conversational than an
one-on-one interview.

Facilitated Workshops

Requirements workshops are
focused sessions that bring key
cross-functional stakeholders
together to define product
requirements.
Workshops are considered a
primary techniques for quickly
defining cross-functional
requirements and reconciling
stakeholder differences.
Issues can be discovered and
resolved more quickly than in
individual sessions.

.




.


.

14

Group Creativity Techniques

Brainstorming.

Nominal group technique.

A selected group of experts answers

questionnaires and provides feedback regarding
the responses from each round of requirements
gathering. The responses are only available to the
facilitator to maintain anonymity.

Idea/mind mapping.

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 technique used to generate and collect multiple

ideas related to project and product
requirements.

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

Group Decision Making Techniques

Unanimity.
Everyone agrees on a single
course of 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
not achieved.

Dictatorship.
One individual makes the
decision for the group.

.

.

.
% 50
.

.


.

16

The Delphi Technique

,
.
:

.
(

)

(
) .

( ) .
17

It is an anonymous way
to reach a consensus of
experts on a subject.
It involves the following:
Questionnaire to solicit
ideas from the experts .
Responses are submitted
anonymously, compiled,
and then circulated to the
experts for review .

A consensus may be
reached in a few rounds.

Questionnaires and Surveys

Questionnaires and
surveys :
are written sets of
questions designed to
quickly accumulate
information from a wide
number of respondents.
Questionnaires and/or
Surveys are most
appropriate with broad
audiences, when quick
turnaround is needed, and
where statistical analysis is
appropriate.

:



.
/





.
18

Observations

Observations
Provide a direct way of
viewing individuals in
their environment and
how they perform their
jobs or tasks and carry
out processes. It is
particularly helpful for
detailed processes when
the people that use the
product have difficulty
or are reluctant to
articulate their
requirements.

:




.




.
19

Prototypes

Prototyping :
is a method of obtaining
early feedback on
requirements by providing
a working model of the
expected product before
actually building it. Since
prototypes are tangible, it
allows stakeholders to
experiment with a model
of their final product rather
than only discussing
abstract representations of
their requirements.

:




.





.
20

Balance Stakeholder Requirements

Requirements
documentation .
Balance Stakeholder
Requirements .
Resolve competing
Requirements By :

Business case .
Project charter .
Project scope statement.
Project constraints .
Customer satisfaction .

.

.

:
.
.
.
.
.

21

5.1 Collect Requirements

1.5

1. Requirements
documentation
2. Requirements
management
plan
3. Requirements
traceability
matrix

.

.

.
22

Requirements Documentation




.

( / )

.

( )


.
23

Requirements Documentation
describes how individual
requirements meet the
business need for the project.
Requirements may start out at
a high level and become
progressively more detailed as
more is known.
Before being base lined,
requirements must be
unambiguous, traceable,
complete, consistent, and
acceptable to key
stakeholders.

Requirements Management Plan

It documents how requirements
will be analyzed, documented
and managed throughout the
project. It contains the following
components:
How requirements activities will
be planned, tracked and
reported.
Configuration management
activities such as how changes to
the product, service or result
requirements will be initiated,
how impacts will be analyzed
Requirements prioritization
process.
Product metrics that will be used
and the rationale for using them.

.
:

.





.
.

.

24

Requirements Traceability Matrix

The matrix is a table that links
requirements to their original
business objectives. This process
includes:
Requirements to business needs,
opportunities, goals, and objectives.
Requirements to project objectives.
Requirements to project scope/WBS
deliverables.
Requirements to product design.
Requirements to product
development.
Requirements to test strategy and
test scenarios.
High-level requirements to more
detailed requirements.

: .

.
.
/
.
.
.

.

.

25

5.2 Define Scope ( Planning )

) (2.5
Define Scope

is the process

of developing a
detailed

description of

the project and

.
product.
26

5.2 Define Scope

2.5
Inputs
1. Project charter
2. Requirements
documentation
3. Organizational
process assets

Inputs
. .1
. .2
. .3

27

Tools & Techniques

1. Project scope
statement
2. Project document
updates

1. Expert judgment
2. Product analysis
3. Alternatives
identification
4. Facilitated
workshops

Tools & Techniques

.
.
.

Outputs

.1
.2
.3
.4

Source: PMBOK Guide Fourth Edition, page 112

Outputs
.1
. .2

5.2 Define Scope

2.5
1.
2.
3.

Project charter
Requirements
documentation
Organizational process
assets:
a. Policies, procedures, and
templates for a project
scope statements.
b. Project files from previous
projects.
c. Lessons learned from
previous phases or
projects.

. .1
. .2
. .3
( a

.
( b
.
( c
.
28

5.2 Define Scope

2.5
1. Expert
judgment
2. Product
analysis
3. Alternatives
identification
4. Facilitated
workshops

. .1
. .2
. .3
.4
.
29

Product Analysis

Each application area has
one or more generally
accepted methods for
translating high-level
product descriptions into
tangible deliverables.
Product analysis includes
techniques such as:

Product breakdown .
Systems analysis .
Requirements analysis .
System engineering .
Value engineering .
Value analysis .

30

Alternatives Identification

Identifying alternatives
is a technique used to
generate different
approaches to execute
and perform the work
of the project.
A variety of general
management
techniques can be used
such as brainstorming
lateral thinking, pair
wise comparisons, etc.

.





.
31

5.2 Define Scope

2.5

1.Project
scope
statement
2.Project
document
updates

.
32

Project Scope Statement

The statement describes, in detail, the

projects deliverables and the work required
to create those deliverables.

It also provides a common understanding of

the project scope among project
stakeholders.

It may contain explicit scope exclusions that

can assist in managing stakeholder
expectations.

It enables the project team to:

Perform more detailed planning.

Guides the project teams work during

execution.

Provides the baseline for evaluating

whether requests for changes or
additional work are contained within or
outside the projects boundaries.

.


.


.
:





.

33

Scope Statement Content

Product scope description.

Product acceptance criteria.

Defines the process and criteria for accepting

completed products, services, or results.

Project deliverables.

progressively elaborates the characteristics of

the product, service, or result described in
the project charter and requirements
documentation.

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. The deliverables may be
described at a summary level or in great
detail.

Project exclusions.

Generally identifies what is excluded as from

the project. Explicitly stating what is out of
scope for the project helps to manage
stakeholders expectations.

.

.

.
.
.
.

34

Scope Statement Content

Project constraints.

Lists and describes the specific project

constraints associated with the project
scope that limits the teams options, for
example, a predefined budget or any
imposed dates or schedule milestones that
are issued by the customer or performing
organization. When a project is performed
under contract, contractual provisions will
generally be constraints. Information on
constraints may be listed in the project
scope statement or in a separate log.

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. Information on
assumptions may be listed in the project scope
statement or in a separate log.

.

.
.

.

.

.
35

Scope Statement Content

Project
exclusions
Project
constraints
Project
assumptions

.
.

.
36

Constraints and Assumptions

Constraint is a
known factor that
limits the project
teams options.
Assumption is a
factor that, for
planning purposes,
is considered to be
true, real, or
certain.

:


.

:

, ,
. ,

37

Identifying Constraints
) (
Examples of
constraints that
may be faced
during a project:
Budget
Schedule
People
Facilities and
equipment

:
.
.
.
.
38

Identifying Assumptions

Assumptions are
identified and
documented during the
planning process as they
affect all aspects of
planning.
They need to be verified
to ensure that they are
true.
If proven to be false, then
re-planning is needed
They always carry a
certain degree of risk

,

.

.

.

.

39

Unquantifiable Expectations

Some expectations
requirements may
be difficult to
quantify, like:
Customer satisfaction
Company Image
Community
Perception

They need to be
quantified as much as
possible.

: , )( \
. ) (
.

.

.
40

5.3 Create WBS ( Planning )

) ( 3.5
Create WBS is the process of
subdividing project
deliverables and project work
into smaller, more manageable
components.
The work breakdown structure
(WBS) is a deliverable-oriented
hierarchical decomposition of
the work to be executed by
the project team to
accomplish the project
objectives and create the
required deliverables.
With each descending level of
the WBS representing an
increasingly detailed definition
of the project work.

.
( WBS)




.


.
41

5.3 Create WBS

3.5
The WBS organizes and
defines the total scope of the
project and represents the
work specified in the current
approved project scope
statement.
The planned work is contained
within the lowest level WBS
components, which 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.

.



. ) (
(
)
.



.

42

Work Breakdown Structure (WBS)

Acts as a vehicle for
breaking the project down
into smaller elements.
Provides greater probability
that never major & minor
activity will be accounted
for.
Multi level presentation of
project objectives.
Multi level
communication tool among
stakeholders.

.


.

.


.

43

44

WBS Example with Code of Accounts

New Software
System

Program

10000

Project

Work
Packages

Hardware

User

Application

Installation

Interfacing

System

11000

12000

13000

Computer

Phases

Tasks

WBS Numbering System:

Identifies the level at which
individual elements are located

LAN
Equipment
11110

External

Documentation

Equipment

Internal
Organization

Organization

Training

11100

12100

12200

13100

Training
13200

Communications

Internal

External

11120

13210

13220

Circuits

Equipment

Installation

11120 - 01

11120 - 02

11120 - 03

45

WBS Example with Code of Accounts

Program

10000

13000

12000

11000

Project

13200

13100

12200

12100

11100

Phases

13220

13210

11120

11110

46

11120 - 03

11120 - 02

11120 - 01

Tasks

Work
Packages

WBS

1
Project

1.1

1.2

1.3

Phase 1

Phase 2

Phase 3

1.1.1

1.1.2

1.2.1

1.2.2

1.3.1

1.3.2

Activity

Activity

Activity

Activity

Activity

Activity

1.1.1.1

1.1.1.2

1.1.1.3

Task

Task

Task

1.1.1.2.1

1.1.1.2.2

1.1.1.2.3

Work
package

Work
Package

Work
Package
47

WBS

1

1.3

1.2

1.1

1.3.2

1.3.1

1.2.2

1.2.1

1.1.2

1.1.1

1.1.1.3

1.1.1.2

1.1.1.1

1.1.1.2.3

1.1.1.2.2

1.1.1.2.1

48

Work Breakdown Structure (WBS) Bridge Project

-
WBS
Level

Phases

Bridge
Constriction

(Tasks)

(Sub Tasks)

Components
(Jobs)

Work
Packages

I
Master

Bridge
Project

Project

Systems

Schedule
Level

Work Breakdown Structure

Foundation

Footings

Procurement

I & II
Master
Milestone

Safety Items

II & III
Milestone
Summary

Structure

Piles

Slab

Girders

Guard
Rail

Prepare and approve Shop Drawings

for footing rebar
Fabricate and deliver footing rebar
Forms & rebar
Pour concrete
1-15 days
Strip footing

Sign
Board

Piles

Piles

Driving Rig

III
Summary

Order and deliver piles

Mobilize pile driving rig
Drive piles (abutment)
Demobilize pile driving rig

IV
Detailed
Control

49

Sample Work Breakdown Structure (Work Packages)

) (
1 Hardware
1.1 Servers
1.1.1 Head Office Server
1.1.2 Branch Server
1.2 Network
1.2.1 Switches
1.2.2 Routers
1.2.2.1 Head Office Router
1.2.2.2 Branch Router
2 Software
2.1 Application
2.1.1 Portfolio Management
2.1.2 Real Estate Management
2.1.3 Asset Management
50

3. Licenses
3.1 Windows Server
3.2 SharePoint Portal
3.3 Office 2003.
4 Training
4.1 Windows Training
4.1.1 Windows Server Admin
4.1.2 Office Training
4.2 Application Training
4.2.1 DB Admin
4.2.2 Application Admin

)Sample Work Breakdown Structure (Work Packages

( )
.3 ( ) .
3 .1 .
3 .2 .
3 .3 . 2003

.4 .
4.1 .
4.1.1 .
4.1.2 .
4.2 .
4.2.1 .
4.2.2 .
51

.1 .
1 .1 .
1.1.1
1.1.2 .
1.2 .
1.2.1 .
1.2.2 .
1.2.2.1

.2 .
2.1 .
2.1.1 .
2.1.2 .
2.1.3 .

WBS is the Basis for Many Other Project Components

52

/
.
.
.
,,
.
,
.

.

.

Work Packages

The lowest level of the WBS

Work unit at level where work is
performed.
Discrete WBS tasks with :
A definable end result ( A specific
objective ).
Can be measured, for example, in
manhours.
Generally, the scope of biddable size.

Assignable to a single organizational

element ( Work Center ).
Measurable Schedule & Cost :
Duration is limited to relatively short
time.
Has scheduled start & end dates.
Has budget .SP/$ ,Manhours,
etc..

Integrated with engineering

manufacturing schedules.

&

.

.
.) (
/
.
,
. )(

:
:
:

.
.
/
......

53

WBS Dictionary

Control Account ID No :

Work Package No :

Date of Update

Responsible
Organization/Individual

Work Package Description

Acceptance Criteria ( How to Know if the Work is Accepted )
Deliverables for the Work
Assumptions
Resources Assigned
Duration
Schedule Milestone
Cost
Due Date
Interdependencies :
Before This Work Package
After This Work Package

Approved By : Project Manager :

54

WBS Dictionary

:
) )
( ) :
:
:
:
:
:
( ) :
:
................................................. :
................................................. :

.
55

5.3 Create WBS

3.5
Inputs
1. Project scope
statement
2. Requirements
documentation
3. Organizational
process assets

Inputs
. .1
. .2
. .3

56

Tools & Techniques

1. Decomposition

Tools & Techniques

. .1

Source: PMBOK Guide Fourth Edition, page 115

Outputs
1. WBS
2. WBS dictionary
3. Scope baseline
4. Project document
updates

Outputs
.
.
.
.

.1
.2
.3
.4

5.3 Create WBS

3.5

1. Project scope
statement
2. Requirements
documentation
3. Organizational
process assets

.1
.
. .2
.3
.
57

Decomposition

It is the subdivision of project

deliverables into smaller, more
manageable components until
the work and deliverables are
defined to the work package
level.
Decomposition of the total
project work into work packages
generally involves the following
activities:

Identifying and analyzing the

deliverables and related work.
Structuring and organized the WBS.
Decomposing the upper WBS levels
into lower level detailed
components.
Developing and assigning
identification codes to the WBS
components.
Verifying that the degree of
decomposition of the work is
necessary and sufficient.

. ) (

:
.


.

.

.

58

5.3 Create WBS

3.5

1. Work
Breakdown
Structure (WBS)
2. WBS dictionary
3. Scope baseline
4. Project
document
updates

. .1
.2
.
. .3
.4
.
59

Work Breakdown Structure

The WBS is a deliverable-oriented

hierarchical decomposition of the
work to be executed by the project
team, to accomplish the project
objectives and create the required
deliverables.
With each descending level of the
WBS representing an increasingly
detailed definition of the project
work.
The WBS is finalized by establishing
control accounts for the work
packages and a unique identifies
from a code of accounts.
A control account is a management
control point where scope, cost, and
schedule are integrated and
compared to the earned value for
performance measurement.

) WBS(




.


.


( )
.



.

60

WBS Dictionary

The WBS dictionary provides
more detailed descriptions of the
components in the WBS including
work packages and control
accounts. It may contain the
following information:

Code of account identifies

Description of work
Responsible organization
List of schedule milestones
Associated schedule activities
Resources required
Cost estimates
Quality requirements
Acceptance criteria
Technical references
Contract information

.


: .










.

61

Scope Baseline

The scope baseline
is a component of
the project
management plan.
The components of
the scope baseline
includes:
Project scope
statement
WBS
WBS dictionary

:
.
.

.
62

Other Breakdown Structures

The WBS should not be
confused with other
kinds of breakdown
structures, like:
Organizational
Breakdown Structure
(OBS)
Bill of Materials (BOM)
Risk Breakdown
Structure (RBS)
Resource Breakdown
Structure (RBS).

:

. )OBS(
. )BOM(

. )RBS(

. )RBS(
63

5.4 Verify Scope ( Controlling )

) ( 4.5
Verify Scope is the
process of formalizing
acceptance of the
completed project
deliverables.
Verifying scope includes
reviewing deliverables
with the customer or
sponsor to ensure that
they are completed
satisfactorily and
obtaining formal
acceptance of
deliverables by the
customer or sponsor.

.
64

Scope Verification Vs. Quality Control

Scope verification:
Concerned with
acceptance of work
results(Tied to project
objectives & WBS).

Quality Control :
Concerned with the
correctness of the work
results (Tied to product
quality tests and
standards).

:

(

. )

:

(

.)
65

5.4 Verify Scope

4.5
Inputs
1. Project management
plan
2. Requirements
documentation
3. Requirements
traceability matrix
4. Validated deliverables

Inputs
. .1
. .2
.3
.
. .4

66

Tools & Techniques

1. Inspection

Tools & Techniques

.) (.1

Source: PMBOK Guide Fourth Edition, page 123

Outputs
1. Accepted deliverables
2. Change requests
3. Project document
updates

Outputs
.1
.
. .2
.3
.

5.4 Verify Scope

4.5
1. Project
management plan
2. Requirements
documentation
3. Requirements
traceability matrix
4. Validated
deliverables

.1
.
. .2
.3
.
.4
.
67

Inspection
) (
Inspection includes
activities such as:
measuring, examining, and
verifying to determine
whether work and
deliverables meet
requirements and product
acceptance criteria.
Inspections are sometimes
called reviews, product
reviews, audits and
walkthroughs.

.




.
68

5.4 Verify Scope

4.5

1. Accepted
deliverables .
2. Change
requests .
3. Project
document
updates .

.1
.
. .2
.3

.
69

5.5 Control Scope ( Controlling )

) ( 5.5
Control Scope is the
process of monitoring the
status of the project and
product scope and
managing changes to the
scope baseline.
Controlling the project
scope ensures all requested
changes and recommended
corrective or preventive
actions are processed
through the Perform
Integrated Change Control
process.

.





.
70

5.5 Control Scope

5.5
Inputs
1. Project management plan
2. Work performance
information
3. Requirements
documentation
4. Requirements traceability
matrix
5. Organizational process
assets

Inputs

. .1
. .2
. .3
.4
.
.5
.
71

Tools & Techniques

1. Variance analysis

Outputs
1. Work performance
measurements
2. Organizational process
assets updates
3. Change requests
4. Project management plan
updates
5. Project document updates

Tools & Techniques

( .1
. )

Source: PMBOK Guide Fourth Edition, page 125

Outputs

. .1
.2
.
.3
.4
.
.5
.

Scope Change Considerations

Will the request to change project

scope affect the project schedule?
Will the request to change project
scope affect the project cost?
Will the request to change project
scope affect the project quality?
Is the total impact a significant
change to the project overall?
What is the impact of no change?
What are all the alternative
methods of accommodating the
requested change?
Does the individual requesting the
scope change have the authority to
approve resulting changes to
project cost, schedule, quality, or
other considerations?

( )




.

72

5.5 Control Scope

5.5
1. Project
management plan
2. Work performance
information
3. Requirements
documentation
4. Requirements
traceability matrix
5. Organizational
process assets

. .1
. .2
. .3
.4
.
.5
.
73

Project Management Plan

Scope baseline
Scope management
plan
Change
management plan
Configuration
management plan
Requirements
management plan

.
.
.
.

.

74

Variance Analysis
) (
Project performance
measurements are used to
assess the magnitude of
variation from the original
scope baseline.
Important aspects of
project scope include
determining the cause and
degree of variance relative
to the scope baseline and
deciding whether corrective
or preventive action is
required.

.




.
75

5.5 Control Scope

5.5
1. Work performance
measurements
2. Organizational
process assets
updates
3. Change requests
4. Project
management plan
updates
5. Project document
updates

. .1
.2
.
.3
.4
.
.5
.
76

Scope Change Control System

A scope change control
system is used to define
the procedures by
which the project scope
can be changed.
It may include the
paper work, tracking
systems, and approval
levels necessary for
authorizing changes.

.
(
,)
,

. ( )
77

Change Control Process

( )
Start

Assess Priority

Propose Change to
the Baseline

Identify Change

Assess Impact of
no Change

Negotiate Proposal

Raise Change
Control Form

Assess Impact on
Cost (Resources)

Urgent?

Yes

Assess Impact on
Schedule
Assess Impact on
Quality

No

Accepted
?

Yes
Change the
Baseline

No
Implement Change

File the Change

End

78

Change Control Process

( )

79

5.5 Control Scope

5.5

80

Questions?

81