There are two key goals that your Change Management Plan
should identify the right decision makers
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
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.
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
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
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
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.
need to identify realistic deadlines for the activities described in the rest
of your plan and then stick to those deadlines. This includes deadlines for the
SMEs on your team for completion of analysis. If you have defined a "Change
Management” and "Change Management Lite” approach to managing change, make sure
all the activities in both paths are identified and scheduled.