There are two key goals that your Change Management Plan should achieve:

1. It should identify the right decision makers
2. It should be agile. By agility, we mean that the decision should be made at the right level, commensurate with the magnitude of the change.

Satisfying the first goal will help satisfy the second. If you make your process flexible enough, you’ll be able to drive the decision down to the right level. Having decisions made at the right level will allow them to be made in a timely fashion; frequently decisions on change have a "best before” date, meaning that if a decision is not made in a timely fashion the project loses the benefit of the change. On the other hand, a multi-million dollar change must be made by the executive sponsor and/or project steering committee.

Communication

If you are a project manager who is fortunate enough to deal with a project team educated and experienced in a standard process, you can skip this paragraph, its intended audience is the vast majority of project managers who must deal with organizations unfamiliar with the PMBOK® approach to managing change. For those project managers, effective change management will call on your skills as a trainer and communicator. It is not sufficient to communicate your perfect plan for managing project change to the team; you must educate them on their responsibilities as described in your plan.

Your communications should reach the entire project team and should be consistent. One approach is to create a presentation that communicates the plans goals, objectives, and responsibilities. The presentation can be delivered to the entire team or to sub-teams, where the team is too large to communicate with in one session. Make sure the presentation communicates the reasons behind the process the plan puts in place. You stand a much better chances of compliance if the team understands the reasons for doing what you ask.

Training

The purpose of training the project team members is to ensure that they follow the process implemented in your plan and that those who have responsibilities to the plan, are familiar with and carry out those responsibilities. The process will be focused on the change request template. Team members should be familiar with all the information that must be captured in the template for any requested change. You’ll save a lot of time if you can avoid having to refer the change request back to the requester for more information or details about the change.

You will especially rely on subject matter experts to make your process work. The subject matter experts are the team members who are responsible for providing estimates for the requested changes. In the world of software development these people will be programmers or analysts. They must be trained to provide accurate estimates of the time and effort necessary to affect a requested change. They must also be able to identify the impact on quality activities of a requested change and should be able to identify any new risks the change would entail (or any existing risks the change would eliminate).

The Cost of Estimates

Every estimate your project provides costs the project in the time and effort of the subject matter expert providing the estimate. Every hour the SME spends on estimating a requested change is an hour they aren’t spending on project work. Your plan must acknowledge this cost. You must also make your project’s customers or clients aware of the cost. Estimates cost; if you don’t communicate that cost to your project’s customers, you may find you’re inundated with change requests and productivity suffers as a result.

Your process should provide a means of transferring the cost of these estimates back to the customer. When you’re dealing with an external customer, your process should have a provision for a Rough Order of Magnitude (ROM) cost estimate for estimating the cost of the change. This may sound unreasonable but you’re actually protecting your customer. If you go ahead with an estimate for a change which your customer believes to be a relatively minor one and it is actually a large change with a proportionally large estimation cost, you will astound the customer when you make them aware of the cost after the fact. Remember, the customer will pay for this cost up front or buried in the project costs. Providing the customer with a cost estimate for the estimate will avoid these surprises.

Projects done for a client internal to your organization our SMEs should set aside a reasonable amount of time for estimates. When this buffer is full, you’ll have to either decrease scope to increase the buffer, or shut the door on future requests.

Closing the Back Door

Eventually you’re going to experience the stakeholder who is familiar with your project team but unfamiliar with your process (or worse, contemptuous of it) who wants to deal directly with the team member to affect a change. Allowing this type of behavior to go unchecked will end in disaster for the project and for the team member who is victimized by the unplanned change. You’ll find out about the change when the team member fails to meet a delivery date and by that time it will be too late to prevent the change or recover the deliverable.

You must get the team onside to avoid this catastrophe. You do this by employing the carrot and stick method. The carrot is that by referring all change requests to you (or to the change coordinator) the team members avoid unplanned work and let you take the heat from the frustrated stakeholder. The stick is holding the team accountable for meeting delivery dates – no exceptions granted because they did a favor for a stakeholder and implemented a change unbeknownst to you.

Creating the Plan

Change Request Submissions

Submissions will be via a change request form which should be posted in a location that is accessible by the entire team, including your stakeholders. This section should also describe the type of information that should accompany a request.

Change Request Analysis

Describe the activities of the SMEs who are tasked with providing the cost estimates for the requests. Be sure to include their responsibilities for analyzing the impact on quality activities of any change in scope, and their responsibilities for identifying risks. You may want to separate this part of the process into "Change Management” and "Change Management Lite” to make your process agile. Provide for full blown analysis when the requested change calls for it and a scaled down version for less complex requests.

Decision Making Process

Identify your decision makers and the process used for making the decision. If the executive sponsor will be solely responsible for making the decision on requested change, capture that here. If a steering committee will make the decision, identify how they do that. Will the decision require unanimity? Will they reach a consensus? Determine the approach your project should take and describe it here.

Include the capture of the reasons for acceptance or rejection in the process. The reasons for acceptance amount to a small business case – the benefits of the change outweigh the cost of implementation. In the case of a rejected change, capturing the reason will avoid a bad relationship with the requestor.

The Decision Making Process should also be agile. If you determined that a two pronged approach is the best way to achieve this (as described in the Analysis section), define one method for "Change Management” and another for "Change Management Lite”.

Approved Change Requests

The activities will include communication, how the approved change will be implemented, and how the request will be archived. Don’t forget to describe how the baselines (scope, schedule, and budget) will be changed.

Rejected Change Requests

A rejected request will mean a disappointed stakeholder; the stakeholder obviously thought the change was worth doing or they wouldn’t have spent all that time and effort completing your change request template. Proper handling of rejected requests will go a long way towards alleviating the disappointment. Identifying the decision making process and decision makers will help. Communicating the decision and the reasons for it will also help.

Schedule