The Change Log
The change request is the backbone of change management
information flow, but it isn’t the only tool you’ll find useful for managing
information to do with project change requests. The change log is a synopsis of
the information captured in each of the change requests received by the project
and if it is properly drafted and maintained it will provide the project
manager or change coordinator with all the metrics they need. The idea is to
identify all the information you want to report on, or that the project
stakeholders are interested in, transpose that information from individual
change requests to your log and use the log as your reporting tool or
A change log is not necessary or helpful on a project where
requested changes are limited to one or two but becomes increasingly useful as
the number of changes increases. On large, complex projects where there are
many change requests, many requesters, and many SMEs, a change log is a must.
The change log can be implemented with any number of
software tools. One of the simplest and most versatile is the Microsoft Excel
spreadsheet. This tool allows you to identify an unlimited number of fields and
to choose from several formats including numeric and text. Excel is also a very
versatile reporting tool. Should you decide to use an existing tracking tool
available to your project to capture change requests, you should investigate
the reporting properties of the tool and define reports with the necessary
fields. If you use Excel or some other spread sheet tool, define these fields:
Each change should be given a unique id as soon as it is logged in your system.
This number should be used to cross-reference the change wherever it is
referenced, including your change log.
one sentence description or title which summarizes the change is also helpful,
although not essential.
Date Received: The
date on which the change request was received should be logged.
status of the change request is also appropriate for the change log. This
information will be used, along with the date of receipt, to determine which
change requests need to be moved along to resolution. This information will
also allow you to identify those changes which are ready to be presented to
your CCB (Change Control Board) for their decision.
author of the change request may also be useful to know, as well as the
organization the author is from. This information can be used to identify
groups or individuals who are responsible for a disproportionate number of
Identifying the current "owner” of the change request will expedite follow up
on change requests which require expediting.
This is the sum of all the work estimates for the change. This may be expressed
in terms of hours, days, or weeks of work or in terms of money. The same
denomination (hours, days, weeks) should be used throughout the log to maintain
This information has to do with the amount that the change would lengthen or
shorten the schedule. This will be the output from your analysis of the
requested change after taking into account those tasks which could be done in
Accepted or Rejected.
There may be additional information you wish to capture in
your own log, but capturing the above will provide you with a useful tool to report
on change metrics for your project.
This information can be entered into the log manually, or
you could automate information capture and transference from individual change
requests, providing both the log and change requests are captured using
software. I have no personal experience with the automation of such a system so
will leave further discussion to those who have. The change log must be kept up
to date so information must be transferred at each milestone in the life of the
change request. It is particularly important to keep the owner of the change
request current so that follow-up is facilitated. Information on the total
effort and schedule impact should be completed before the change requests is
forwarded to the CCB for decision but need not be updated with the individual
analysis as the request works its way through the SME chain. The decision
should also be captured as soon as it is made.
You now have a tool which will provide you with just about
any metric you could want to know about changes to your project including the
- Responses which are overdue. Change requests
which have a forecast completion date for analysis in the past.
- Change requests which are ready for a decision
- The status of any change request (in answer to
the question "what about my change request, it’s been ____ days now and I
haven’t heard anything).
- How many change requests are in the queue
- Total number of change requests received by the
- Total number of change requests approved, by
group, by requester
- Total number of change requests rejected, by
group, by requester
- Total amount of effort for all change requests
- Total amount of effort for accepted change
- Total change in schedule for all change requests
- Total change in schedule for accepted change
These are just some of the metrics that your change log will
support with the fields described above. If your project requires more metrics,
simply alter the log to capture the desired information and then report on
Pay particular attention to the total change in the project
schedule metric as it is the one that tells you and your stakeholders how the
schedule has changed since the implementation of change management. This is the
total amount of time the schedule has been adjusted by with the approval of theCCB. We’ve all heard and read horror stories about projects which finished well
after their planned finish dates and don’t want ours to be included in this
list. A little more analysis of the requested project changes will determine
how much of the slip was caused by your client and how much by you. Changes to
the project, requested by you, to correct project problems are slippages you
must take responsibility for. Those that were proposed by your client,
customer, or stakeholders, to improve the product, or for whatever reason are
slippages you should not be held responsible for.The
tips and tricks described in this article implement some of the best practices
promoted by the PMI (Project Management Institute). These are taught in most
PMP® courses and other PMP® exam preparation training
products. If you haven't been certified as a PMP® http://threeo.ca/pmpcertifications29.php.
three O Project Solutions also offers a downloadable software based training
tool that has prepared project managers around the world to pass their
certification exams. For more information about this product, AceIt, visit the
three O website at: http://threeo.ca/aceit-features-c1288.php.