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 information source.

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:

Identification Number: 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.

Description: A 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: The 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/Source: The 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 change requests.

Current Owner: Identifying the current "owner” of the change request will expedite follow up on change requests which require expediting.

Total Effort: 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 consistency.

Schedule Impact: 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 parallel.

Decision: Either 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 following:

• 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 (unclosed status)
• Total number of change requests received by the project
• 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 requests
• Total change in schedule for all change requests
• Total change in schedule for accepted change requests

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 them.

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 the CCB. 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.