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
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?