Managing Project Change
Considering the effort that it takes to gather requirements, assemble a team, get approvals, and put your project down on paper, it's hard to welcome change within any element of your project. But change is a reality in any project situation. To begin with, projects occur over a span of time, and with the passage of time, underlying circumstances and conditions can change. In addition, projects are completed by people, and people have new ideas, recognize mistakes and change their minds. Under these circumstances, it would be unwise, if not impossible, to proceed with any project without recognizing, accepting and preparing for the possibility of change.
The key to effective project change management is not to prevent change, but to control it. This is the essence of project change management - to identify, evaluate and adopt changes so that project results are enhanced. To that end, project should be managed with a structured process designed to accept positive change and avoid negative change.
And, any effective process for project change control needs to consider the two primary types of change:
Reactive Change: when changes are necessary to respond to project problems (i.e. delays, technical failures, funding shortages, resources issues, etc.). In all likelihood, reactive changes are not optional as long as you wish to sustain or salvage the project.
Requested Change: when changes to project requirements, scope, deliverables or related management plans are requested by end-users or other project participants. These changes can arise from new ideas, new information, or new perspectives, and usually are requested by project customers (i.e. your end-users). In any event, requested changes are usually discretionary, and therefore, are difficult to control. While certain changes can enhance and improve a project, if left uncontrolled, excessive change can lead to problems. Excessive project changes can overwhelm a project to the point where original benefits are lost, and the project can no longer be completed as expected. The trick to change control is to continually balance change requests against original project goals, ensuring enhanced value, without diminishing schedules and results.
Steps - change management planning
What types of changes will be allowed?
In order to properly control changes for any given project,
you must set change boundaries - to establish and limit
the types of changes you will consider. Obviously, if
a change is required to sustain or save a project, that change
must be accepted. But if change is discretionary, then
that change needs to be weighed against established boundaries.
To set realistic, flexible change boundaries the following variables must be analyzed and considered:
Value and Priority. If a project is very visible and important, you may need to limit discretionary changes to very small levels to avoid unwarranted risks.
Timing. If the change request arrives at an early stage in the project, that change can probably be absorbed, but if the project is more than 50% complete, that same change may actually interfere with timely completion.
Cost. Project changes can increase (or decrease) project costs. In order to properly manage changes, you should set limits on change related costs, so that your budget is appropriately maintained. In addition, for large projects, separate change budgets (also known as a contingency fund) should be established to set limits for change costs outside of the original budget. In effect, your initial budget establishes expected costs, and your change budget controls the costs of subsequent changes.
Impact. In order to maintain proper control of project change, you will need to assess change impact - i.e. how will a given change impact your project? Will the change impact scope, deliverables, schedules, resources, or some other project element? With this detailed understanding, you can set appropriate, yet flexible limits as a guideline for change review and approval.
How will changes be incorporated into project plans
and deliverables?
Once change requests are processed, reviewed and approved, the
corresponding changes have to be incorporated into the ongoing
project. Depending on the specific type of change, one
or more elements of the project may be affected, and this may
necessitate changes to project plans, technical designs, resource
assignments, budgets or other project documentation. No
matter how many areas of the project are affected, changes should
be recorded to ensure that original documents and plans are
maintained as a baseline, with changes clearly identified.
Most automated project planning tools will track changes to
plan, and will produce reports of all variations. However,
as time passes, and with multiple projects underway, these reports
may not provide sufficient "lessons learned" information as
to the "whys and wherefores" of change approval, and the related
change results.
To that end, a "Change Impact Statement" can be used to record change reasoning, execution and consequences, documenting approved changes from several perspectives:
#1 What was the nature of the change?
#2 Why was it approved?
#3 How was it executed?
#4 Were the anticipated consequences realized?
#5 Was the change positive or negative, and what can be learned
for the future?
ITtoolkit Navigation Guide
Start at the Home Page
Find White Papers and Project Templates
Explore More How-To-IT Topics and Content