What to do

How to do it

1

Identify the driving project constraint

Typically, one or another project constraint (i.e., scope, budget, schedule, or quality) is more important than the others. As change is managed, the driving constraint receives overriding consideration. 

Acknowledge this in the Change Management Plan.

2

Determine the types of changes to be tracked

By default, every change to the project is tracked and approved.

Determine the degree of latitude the project team has in interpreting and implementing the product specifications or requirements. The latitude may be defined in terms of scope, budget, schedule, and/or quality. Within that latitude, changes do not need approval. Evaluation is still required to determine that a change falls within this latitude. Document the latitude in the Change Management Plan.

Note that some changes are not requested in advance. For example, a realized risk may result in a change. Such changes should be documented and evaluated. Adjustments to the project made because of them should be approved.

3

Estimate the probability and volume of change to project deliverables

Express this in terms of the project constraints: scope, budget, schedule, and quality.

For example, a vaguely defined development project is likely to be volatile, especially if it will be using unproven technology. In such a case, it is likely that requirements will shift and that the project team will need to work around shortcomings of the tools. 

(See also the FAQ change budget entry and Risk Management.)

4

Estimate total effort to manage and evaluate change requests

Estimate total project effort (e.g., staff, time, etc.) required to manage, evaluate, and approve change requests. Incorporate estimates into the project’s staffing plan, schedule, and budget.

5

Define change management roles, responsibilities, and competencies

Typical roles include:

• Change manager
• Change evaluator (lead)
• Change decision maker

Note any special expertise or level of responsibility associated with each role.

For large projects, responsibilities may be divided among several people based on their specializations.

6

Define logging, monitoring, and reporting requirements

Typical requirements include:

• Components of a change log record
• Change log mechanism (e.g., spreadsheet, automated change control system)
• Change log monitoring and reporting frequency

7

Define priority categories to be used

For most projects, only high, medium, and low priorities are required. 

For some projects with unusual constraints, other categories could prove useful. For example, in a project with very tight deadlines, expressing the priorities in terms of the schedule constraint could help in managing timely evaluation and approval. Priority categories such as “immediate” reinforce the appropriate focus.

Include these categories in the change request form.

8

Define evaluation process and principles

Define the evaluation workflow and the documentation to be produced by the evaluators.

Establish the principles to be followed in the evaluation:

• Evaluation priorities (e.g., dominance of one or more of these project constraints: scope, budget, schedule, or quality) and the depth and thoroughness of evaluation.
• Classification of change impacts (e.g., what is impacted, size of impact, criticality, etc.)

9

Establish guidelines for integrating changes into project documents

Change should be recorded clearly. Every change the project tracks results in a new baseline that defines the work the project team is to do. The guidelines in this action tell the team what documents to consult to ascertain the current baseline.

Example: A small extension in scope may be simply noted in the project change log and appended to the appropriate requirements document, then incorporated into the project schedule tracking document. A larger scope change may require adjusting and reissuing the project plan’s scope statement and requirements documents along with adjustments to schedule and budget documents.

10

Establish guidelines for communicating changes to the project team

Change should be communicated clearly. The team needs to know to consult project documents again to ascertain the current baseline. 

The plan that describes to whom and how this communication will occur should appear in the change management plan and again in the project’s communication plan (if only by reference).

Change Management Plan

Change Management Plan

Change Management Plan EZ

Change Management Plan EZ

Change Log

Change Log

Change Request Form

Change Request Form