[Agency Name]

[Project Name]
Change Control Process

Version: (n)

Date: (mm/dd/yyyy)

Document History and Distribution

1. Revision History
Revision #

Revision Date

Description of Change

Author

2. Distribution
Recipient Name

Recipient Organization

Distribution Method

Change Control Process

Table of Contents
1. INTRODUCTION......................................................................................................................................1
2. STEPS TO CONTROLLING SCOPE CHANGES................................................................................1
3. DEFINING A CHANGE CONTROL PROCESS...................................................................................2
4. CHANGE REQUEST FORM...................................................................................................................2
5. CHANGE REVIEW OR EVALUATION...............................................................................................3
6. CHANGE PRIORITY AND CLASSIFICATION..................................................................................5
7. CHANGE APPROVAL.............................................................................................................................5
8. RECOGNIZING SCOPE CHANGE........................................................................................................6
9. FINDING SCOPE CHANGES..................................................................................................................7
APPENDICES...............................................................................................................................................11
APPENDIX A:
APPENDIX B:
APPENDIX C:
APPENDIX D:

PROJECT CHANGE REQUEST FORM (SAMPLE)..................................................................12

CHANGE REQUEST STATUS REPORT (SAMPLE)................................................................14
CHANGE REQUEST LOG (SAMPLE)..................................................................................15
CHANGE PROCEDURE (SAMPLE).....................................................................................17

4/20/2014 11:19 A4/P4

Change Control Process

1. Introduction
Its a fact - project changes are inevitable!
A project will undergo changes during some point in the software development life cycle (SDLC).
The key is controlling the changes to manage the impact to the project plan, budget, and
implementation schedule.
Some changes will be unavoidable instances where changes have to be made to comply with
legal, federal / state regulations, policy changes, compliance with changes in the business direction
of the enterprise, or where technology may dictate change. Other non-essential changes can be
avoided through management of a formal change control process.
The number one cause of project schedule and cost overruns is project scope change!
If scope changes are not controlled the project schedule and budget will be destroyed before the
project manager recognizes that anything has happened. A well though out change control process
will assist the project manager and team in controlling this scope creep nemesis.
Scope changes (sometimes referred to as creeping functionality) are the continual addition of
functional enhancements to the product requirements throughout the software development life
cycle. Excessive scope changes are directly related to poorly defined product requirements and
specifications.
The formal, approved requirements document is the first task that a project undertakes to start out
in control of the project. Placing the agreed-to requirements document under strict change control
(configuration management) helps a project stay in control.

2. Steps to Controlling Scope Changes

Three (3) steps are necessary to control scope changes:
1. Establish the baseline product.
2. Obtain agreement from the project approvers.
3. Enforce a formal change control process.
1. Establish the baseline product
Establishing the baseline product means describing the product (business functional
requirements) in detail early in the software development process. The product specifications
define the product to the level of detail that allows all project groups to perform their activities
04/20/14

11:19 A4/P4

Change Control Process

productively. The product specifications define what the product being built looks like. When
the product is properly defined the project manager and team members know what is in and
what is out of the project scope.
2. Agreement from the project approvers or sponsors
Get the agreement from the right people, or organizations, on the business functional
requirements of the product being built. All groups dependent on complete and accurate
product specifications must approve the document to ensure that it meets their needs. When
the product being built meets the needs of the users fewer changes need to be made.
3. Enforce a formal change control process
The software development process is never static. Some changes are to be expected during the
product build, and a formal process must be defined and followed to make sure all changes to
the product are made in an orderly manner.
As scope change requests are made, a change control process is necessary to insure that the
following occurs:

Only necessary changes are made,

Changes are communicated to all affected parties, and

Changes are implemented in an orderly fashion.

3. Defining a Change Control Process

There are many change control methods a project manager may use. Any good change control
methodology will have four (4) components or subsystems. These subsystems are:
1. Change Request Form
2. Change Review and Evaluation
3. Change Priority and Classification
4. Change Approval
Figure 1 illustrates a typical change control process flow. Please note that there are two (2)
separate reviews that occur during the change control process. These reviews are:

First, to validate the change proposal is justified, and

Second, to access the impact of the change on the project.

4. Change Request Form

Evaluating the impact of a proposed change takes time. Therefore, it is important that change
requests be well thought out before being submitted. The project manager is the filter point at
which unnecessary and ill thought out change requests are rejected.
04/20/14

11:19 A4/P4

Change Control Process

A project change request form should be created and approved prior to the projects startup. At a
minimum, the change request form should contain the following information:
Originators name and phone number,
Submission date,
Description of the problem that the change addresses,
Description of the change,
Justification for the change,
Date the change is needed (if applicable),
Change category (type of change or reason for change)1,
Impact write-up addressing the affect the change has on project schedule and
budget,
Approval disposition (accepted or rejected boxes),
Project Managers signature and date,
Project Sponsors approval, signature, and date, and
Date change is updated into the Change Request Log and updated into the project
plan.
Under all circumstances, the project manager is the channel through which Change Requests are
funneled. Any Change Request that does not have the project managers signature is immediately
returned to the submitted. A sample Project Change Request form is attached as Appendix A.

5. Change Review or Evaluation

A change review committee, or board, must be established to evaluate all change requests. The
number of participants on the committee, or board, is dependent upon the project size and
complexity. On a small project, the project manager may review and approve change requests. On
larger complex projects, a review committee or board may be more appropriate.
The change review committee or board is made up of a cross selection of technical team members.
Review committee members should be selected who have the expertise to truly assess the impact of
the change request on the projects scope.
A set turnaround time must be established for the review process from submission to acceptance
or rejection. This ensures that an approved change, along with the appropriate activities or
tasks, is entered into the Project Plan in a timely manner.
The review committee evaluates the impact of the proposed change on the project. Factors to
consider in reviewing change requests include:

Skill level of personnel required to complete the proposed change.

Impact of the proposed change on the project schedule.

Impact of the proposed change on the project budget.

Typical change types are requirement or design flaws, legal or regulatory requirements changes,
techniques, change in business direction, policy changes, or technology approach (design) changes.
1

04/20/14

11:19 A4/P4

Change Control Process

Risk levels of the proposed change.

Does the proposed change require project rework?

Does the proposed change require additional resources (e.g., computer time,
materials, tools, people, and technology)?
The change review committee documents these factors on the original change request form and
returns the form to the project manager for further action.
Using a current version of the Project Plan, the project manager adds the changes (tasks to be
complete) into the project plan to assess the impact the proposed change has on the project budget,
schedule and resources. A copy of the revised version of the Project Plan and work breakdown
structure is reviewed to graphically assess the impact on the project components.
NOTE: At this point the project manager is playing What If with the Project Plan. The
proposed change should not be committed to the baseline plan. If it is necessary to commit the
change activities or tasks to the project schedule plan to see its affect, the project manager (or
project administrator) should do a File/Save As and save the baseline plan under a secondary file
name. Approved changes will require that a re-baselined project plan be created.

Change Proposal
Change Proposal
is written
is written

Rework
Change Proposal
Change Proposal
is reviewed
is reviewed

Rejected

Rework Proposal
Rework Proposal

Stop

Accepted

Change proposal is
Change
proposal
is
designed
and
designedand
andan
documented,
documented, and an
implementation
implementation
schedule
is created
schedule is created
Rework Proposal
Rework Proposal
Change Proposal
Change Proposal
is reviewed
is reviewed

Rejected

Stop

Accepted
Change Proposal
Change Proposal
is implemented
is implemented

04/20/14

11:19 A4/P4

Change Control Process

Figure 1. Change Control Process Flow

6. Change Priority and Classification

Change requests should be assigned a change priority classification code based on a set of
standards. A sample set of standards is as follows:
1. P1 Critical: A critical priority change request is considered to be imperative to the success
of the project, and likewise, may have a detrimental impact to the project if not addressed
promptly. This type of change request is mandatory and must be completed. The timeframe
for estimating the effort and cost required to implement a critical change request should be one
(1) week or less. Examples of critical change requests are legal mandates, functionality to meet
core business process requirements, or data integrity with respect to database content.
2. P2 High: A high priority change request is considered to be important to the success of the
project. The timeframe for estimating the effort and cost required to implement a high priority
change request should be two (2) to four (4) weeks. Examples of high priority change requests
are issues and problems resulting from data integrity, legal mandates, and add-ons to improve
data quality.
3. P2 Medium: A medium priority change request has the potential to impact successful
completion of the project but is not an immediate help nor hindrance. The timeframe for
estimating the effort and cost required to implement a medium priority change request should
be four (4) to six (6) weeks. Examples of medium priority change requests are requests that
improve workflow processes.
4. P3 Low: Low priority change requests need to be addressed if the time and budget permit.
Low priority changes requests are managed, as resources are available. The timeframe
guideline for estimating the effort and cost required to implement a low priority change request
is more than six (6) weeks. Examples of low priority change requests are cosmetic changes or
fixes that do not affect business functional requirements or deliverables.
A sample Change Request management information status report is attached as Appendix B.

7. Change Approval
After the change request evaluation, the project manager schedules a change decision meeting.
Participants in the change decision meeting include the project sponsor(s), the change review
committee or board members, the project manager, user management, and the originator of the
change request.

04/20/14

11:19 A4/P4

Change Control Process

The project manager presents the proposed change and the results of the evaluation, including a
copy of the proposed revised project plan illustrating the impact of the change. The requestor may
speak in behalf of the change (if necessary) and the evaluators may defend their evaluation (if
necessary). The project manager acts as a neutral observer. The project manager gets involved
only if the evaluation indicates that the proposed change would have a significant impact on the
project increasing costs, schedule, or project risk.
The change control criteria that was set forth in the Statement of Work (SOW) or Requirements
document is used to measure the acceptability of the proposed change. The change control criteria
defines the boundaries, or range, within which changes will be accepted, and at what level the
change request gets escalated to higher management for the final decision.
Remember: All change requests alter the scope of the project in some manner; thereby effecting
the project completion date and the project budget.

The following are examples (samples) of boundaries or ranges for change requests are:

The change does not alter the completion date or increase the project budget.

Executing the change request takes a maximum of h hours of staff time to

complete.

The cost of the change is less than $$$ dollars.

The benefit of the change must always exceed the projected cost of the change.

Caution: The project should be careful when specifying a specific dollar amount as change
criteria. Each dollar amount adds up and before the project manager and sponsors realize it, the
project budget has been significantly enhanced.
When project change requests are rejected, the rejections are final for the duration of the project,
unless the environment in which the change was originally evaluated is altered significantly. This
rigid approach saves time that would be wasted in re-evaluating old issues.
An example of a Project Change Control Procedure is attached as Appendix D.

8. Recognizing Scope Change

In order to manage scope changes, you must be able to recognize the forms that scope changes can
take. They come in many disguises some are easy to recognize, some are not. Scope changes
may be:

04/20/14

11:19 A4/P4

Change Control Process

Overt client requests. These are the easiest to identify. The client makes a formal request for
an additional function to be incorporated into the product.
Covert client requests. These scope changes sneak in when the project manager isnt looking.
Someone on the client team makes an informal request of someone on the project team (e.g.,
one more report, one more inquiry view, or a new area of functionality).
Smuggled requirements. These scope changes need a sharp ear to catch. The changes are
introduced as part of normal information gathering / status reporting processes and usually
reflect overlapping areas of the software project. For example, your team is conducting a
workshop to determine detailed requirements for a purchasing system and among the
requirements discussed is a set of requirements for calculating vendor payables. The scope of
purchasing has just been expanded to encompass accounts payable.
Project team enthusiasm (design changes). These scope changes represent the Wouldnt it be
nice if. things or functions introduced by the enthusiasm of the project team that involve
over design, over build, or unapproved testing of new design techniques.
Problem Reports. These changes are the result of system incident reports (SIR) or problem
resolution reports that identify a non-compliance to the business functional requirements or the
detailed design document. Problem reports will usually result in a change request.
Issues. System issues will be created during the entire system development life cycle. Issues
must be reviewed, estimated, and approved by management. Some issues may result in a
change request. Other issues may be deferred to future releases or rejected outright.
Primary emphasis: If the activity is not listed in the business functional requirements document,
the baseline project plan, or the detailed work breakdown structure (WBS), the activity is a scope
change.

9. Finding Scope Changes

Now that you see some of the disguises scope changes can hide under, how does a project manager
catch and control change requests? To manage scope changes a project manager needs to build
team sensitivity to change requests. By using a few consistent practices, the project manager can
build team sensitivity to recognizing scope change requests. These steps are:
1. Repeat, repeat, and repeat again the project scope. Make sure everyone on the team
understands and accepts the project scope. Make it a habit to reiterate the project scope at

04/20/14

11:19 A4/P4

Change Control Process

meetings. The more the project scope is etched in the teams and customers minds, the easier
it is for them to recognize a scope change when it comes up.
2. Make sure the project scope is visible to everyone on the team. Use mottoes, posters, or other
advertisements to ingrain the scope into the team mindset.
3. Ensure the project scope is included in any orientation materials given to new team members.
4. During weekly team meetings, conduct a separate roundtable to review scope change requests.
5. Whenever you or any technical leaders need to make a project decision, make sure the project
scope is included as one of the factors contributing to the decision.
6. During periodic reflections on the project, include the project scope as a subject for review.
Reviewing Scope Changes Considerations
The number one consideration as the project manager and change review committee assess the
proposed change request is:
What effect will this change have on the projects outcome?
To understand this question, it is best to conduct a trade-off analysis by:
1. Understanding the pressure the change will exert on the project, and
2. Clarifying how the change will affect later tasks and milestones.
The following are considerations for understanding the impact of various options when
implementing a change request:
Determine the underlying rationale for the change. Is the change motivated by
rational thinking, or a political agenda?

Does the change really make sense?

Is the change necessary?

What is the justification for the change?

Is it necessary in this release of the product?

Can it be delayed?

Are the project goals still appropriate or will the change also affect the eventual
outcome of the project? (Note: make sure the product will still be the desired product
when completed.)

04/20/14

What project groups are impacted by the change?

Does the change affect the likelihood of completing the project successfully?

How will project dependencies, risks, and schedules be impacted?

11:19 A4/P4

Change Control Process

Is there a more effective and preferred change to the one proposed? (Hold the
budget and objectives constant and then evaluate how you can accommodate the
change.)
Is there an alternative way of handling the change request that would not impact
the project? (Look for alternatives, tasks that can be deleted or shortened, or dollars
that can be moved around in the project.)
Understand the skills of the team as you consider trade-off options. Do you have
the skills on the team to handle / complete the requested change? If not, what will it
cost you?
How and when can the change best be made with the least negative impact to the
project?

The bottom line to every change request is that it adds additional overhead to the
project.
There is no way out of this fact - so it is imperative that all areas of the project (e.g., additional
project management time, quality assurance, testing, documentation, contingency planning, risk
management) be assessed when defining the total/true impact of the change request to the project
cost and schedule.
Tracking Change Requests
Two (2) things need to happen after the change request has been accepted. The project manager
must:
1. Update the project plan with the new activities and tasks created by the change request and
adjust the project schedule, plans, dates, deliverables, and dependencies.
2. Log the change request into the projects Change Request Log and tracks the change through
task completion.

When change requests are made, regardless of their disposition (acceptance / rejection), they
are entered into the Change Request Log and their disposition is tracked to project completion.
When the change request is accepted, the tasks and activities required to execute the change are
entered into the project plan and work breakdown structure (WBS), along with other pertinent
data. A re-baselined project plan is then distributed to all team members.
The Change Request Log as well as the Change Request Form become part of the Project
Notebook and are used to indicate the state of the scope change approved or rejected.
Key information the Change Request Log tracks is:
- Change request number,
- Date submitted,
04/20/14

11:19 A4/P4

Change Control Process

Short description of the change,

Priority for change (high, normal),
Estimated Cost,
Approval or Rejection column,
Date approved/rejected,
Date project schedule plan updated, and
Comments (options).

Track all change requests using the Change Request Log. A sample Project Change Request
Log is attached as Appendix C.

04/20/14

11:19 A4/P4

10

10

Change Control Process

Appendices
Appendix A: Sample Project Change Request Form
Appendix B: Change Request Status Report
Appendix C: Sample Change Request Log
Appendix D: Change Procedure Sample
Change Request (Excel Spreadsheet Version)

04/20/14

11:19 A4/P4

11

11

Change Control Process

Appendix A: Project Change Request Form (sample)

[Department/Agency Name]
[Project Name]
Project Change Request
SECTION A: CHANGE REQUEST DESCRIPTION
Request Date: mm/dd/yyyy

Change #: nnnn

Type of Change:

Priority: P-n
Non-Compliance

____ Functional/Design Change

____ Requirements Change

____ Regulatory

Requestor: _______________________________
Description of the Requested Change (Long Description):

Reason for Change:

04/20/14

11:19 A4/P4

12

12

Change Control Process

SECTION B: IMPACT ASSESSMENT

Change Request (Short Description):
Workgroup(s) Impacted by the Change:
Estimated Impact to budget, work effort and schedule:

Total Estimated Cost:

Estimated Revised Completion Date:

SECTION C: PROJECT MANAGEMENT APPROVAL

Status: Open / Closed
Reviewer: _____________________________________________
Comments:

__________________________________________________________ _________
[Requestor]
Date
__________________________________________________________ _________
[Project Manager]
Date
__________________________________________________________ _________
[Project Sponsor or Approver]
Date

04/20/14

11:19 A4/P4

13

13

Change Control Process

Appendix B: Change Request Status Report (sample)

Cumulative Change Request Summary Report
As of MM/DD/YYYY
Severity

New

Open

Deferred

Duplicate

Closed

Total

Critical
High
Medium
Low
Total
%

04/20/14

11:19 A4/P4

14

14

Change Control Process

Appendix C: Change Request Log (sample)

[Department / Agency Name]
[Project Name]
Project Change Request Log
CHANGE
REQ.
NO.

04/20/14

DATE
SUBMITTED

11:19 A4/P4

DESCRIPTION OF CHANGE

Priority
(Normal or
Urgent)

ESTIMATED
COST

REVISED
COMPLETION
DATE

15

APPROVED
/REJECTED

COMMENTS
DATE

Change Control Process

This page intentionally left blank

04/20/14

11:19 A4/P4

16

Change Control Process

Appendix D: Change Procedure (sample)

Change Procedure
This change procedure is to be followed when any change or modifications to the activities or
deliverable that have been identified on the project plan or Statement of Work is requested.
The change procedure consists of three activities:

Change Request Initiation

Change Request Review

Change Request Approval

Change requests may be of either of two (2) of the following types:

Design changes Any changes that modify the project work effort scope, as
outlined in the Business Functional Requirements or Statement of Work (SOW).
Non-compliance changes Changes that result from a lack of resources planned
for a specific project work effort segment, or a delay caused by failure of an individual
or group to meet a responsibility outlined in the Statement of Work.
1. Change Request Initiation
Change requests can be initiated by a manager who is a:

Customer of the project.

Member of the project management staff.

Project sponsor.

Proposed user of the system.

All Change Requests must be made in writing, using a standard Change Request Form.
As part of the initiation of a change request, each Change Request Form must:

04/20/14

Identify the name of the individual requesting the change request.

Identify the name of the individual submitting the change request.

Clearly describe the requested change.

Identify the estimated dollar cost to implement the change request.

Identify the estimated revised completion date.

On a detailed summary (to be attached to the Change Request Form):

Identify all of the resources (including system and people) required to implement
the change.

11:19 A4/P4

17

Change Control Process

Identify the estimated time required to implement the change.

2. Change Request Review

All Change Request Forms will first be provided to the Project Manager for:

Initial review of the nature and substance of the change request, and

Review of estimates of work plan schedule and cost impacts.

The Project Manager will assign a sequential number to each Project Change Request Form
received, for purposes of tracking change activity on the project. All change requests will be
logged on the Project Change Log. Change request sequence number will be numeric, and for
each project, will begin with the number 1.
3. Change Request Approval
All Project Change Request forms must be reviewed and approved by the Project Manager.
All change requests will be subject to Change Approval Criteria included with this Statement
of Work. Change Approval Criteria specify the categories into which changes will be
classified, and the approval hierarchy for change requests.
All approvals will be given by a written signature of the approving individual on the Change
Request Form.

Change Approval Criteria

The following criteria will apply to all requests for changes to this project. All requests for
changes must be submitted in writing, using a Change Request Form. All requests for changes
must follow the standard Change Request Procedure.
Change requests must be assigned a change priority classification code and change level based
on the following set of standards:

P1 Critical: A critical priority change request is considered to be imperative to the success

of the project, and likewise, may have a detrimental impact to the project if not addressed
promptly. This type of change request is mandatory and must be completed. The timeframe
for estimating the effort and cost required to implement a critical change request should be one
(1) week or less. Examples of critical change requests are legal mandates, functionality to meet
core business process requirements, or data integrity with respect to database content.

P2 High: A high priority change request is considered to be important to the success of the
project. The timeframe for estimating the effort and cost required to implement a high priority
change request should be two (2) to four (4) weeks. Examples of high priority change requests
are issues and problems resulting from data integrity, legal mandates, and add-ons to improve
data quality.

P2 Medium: A medium priority change request has the potential to impact successful
completion of the project but is not an immediate help nor hindrance. The timeframe for
estimating the effort and cost required to implement a medium priority change request should

04/20/14

11:19 A4/P4

18

Change Control Process

be four (4) to six (6) weeks. Examples of medium priority change requests are requests that
improve workflow processes.

P3 Low: Low priority change requests need to be addressed if the time and budget permit.
Low priority changes requests are managed, as resources are available. The timeframe
guideline for estimating the effort and cost required to implement a low priority change request
is more than six (6) weeks. Examples of low priority change requests are cosmetic changes or
fixes that do not affect business functional requirements or deliverables.

LEVEL I Changes (L1):

Level I change are changes that will require:

Fewer than x hours total work effort, AND

A total cost impact less than $$$.cc, AND

No revision on the project completion date (e.g., does not impact any activities on
the projects critical path).
After review of the Project Manager, the decision to implement LEVEL I change will be subject to
the approval of the manager whose budget must pay for the requested change.
LEVEL II Changes (L2):
Level II changes are changes that will require:

More than x hours total work effort, or

A minimum total cost of $$$.cc, or

Extension of the project completion date for more than x days longer than the
originally estimated completion date.
After review by the Project Manager, the decision to implement LEVEL II changes will require the
approval of the Project Sponsor.
Change Requests submitted by the Project Sponsor will require the review and approval of the
Change Review Committee as defined in the Statement of Work.
Disagreements that cannot be resolved will be forwarded to the project steering committee for
resolution. Two (2) days will be provided for resolution response.

04/20/14

11:19 A4/P4

19