Control changes

Where are we?

Almost as soon as the project begins to take shape (during the definition as well as during the delivery) you may have to change it. The simple act of trying to write down a project plan will cause you to challenge some of the main characteristics of the project.

For example, you may feel that you cannot possibly fit in an extra piece of work that the sponsor has mentioned, as it is just too much to undertake within the timeframe.

Once the project is running you will discover things that will force you to consider changing the project. Maybe a resource assigned to help you cannot do the work, or you go sick, or you suddenly see that the job is much bigger than you had thought.

You will recognise the need for some changes yourself, but it is often true that the sponsor will be the main source of requests for change.

This could give you a real problem as the sponsor probably outranks you in the organisation, and you feel (and maybe the sponsor feels too) that ‘what they say, goes’.

Now to some extent this is right, but many times the sponsor will not have a detailed understanding of the project (remember Project Management Law number 1), and so can feel free to make requests without taking feasibility, risk, budget, timescales and so on into account. The sponsor needs you to analyse the potential impact of any requests for change, and to come back with a sensible and constructive response.

So some of the facts of (project) life are:

All projects are subject to requests for change (you can’t stop the world just because you want to run a project)
Requests for change are usually good things, as they show that someone out there knows that you exist, and they want to get the best out of your project.

All we need is a system for managing changes. With no system, however simple, you will be at the mercy of the person with the most stripes on their sleeve, and you will be dragged around as your project changes shape in an uncontrollable manner.

The baseline

Managing changes starts at the definition phase. Once the scope and schedule has been agreed and signed-off by the sponsor and project manager it enters a special status known as ‘baseline’. This means that although it can be changed, every change must be agreed and signed-off by the same people who signed-off the original document. So, the ‘project definition baseline’ is established during project definition.

This baseline feeds into the change management process.

Roles and authority

In a large complex project certain key players will be delegated the authority to accept or reject requests for change, and this ‘change board’ may meet on a regular and frequent basis to keep the project rolling. On smaller projects the change authority will reside with the sponsor, never the project manager. You will not be able to change the contents of the project at your own discretion. The sponsor owns the business outcome, and therefore owns the right to decide about changes to it.

The role of the project manager is to inform and direct the decision-making process. This means that you will have to analyse the potential impact of the request for change and make a recommendation to the sponsor about whether the change should be accepted or rejected (or sometimes deferred to a more convenient time).

The process

Most textbook change management processes say that all requests for change must be submitted in writing by the person who wants the change. This is often a feeble attempt to cut down on the changes to a project, and is completely unrealistic. Not many junior project managers will be able to tell their Chief Exec to “put it in writing or it doesn’t get considered”!

The better way of stating this is that all requests for change must be written down before they can be analysed for impact on time, cost and risk. In the last resort this gives the project manager the leeway to write some of them down him or herself.

Many organisations have change request forms, and these should be used wherever possible. Once you receive a change request you must:

Make sure you understand it; send it back for more explanation if necessary.
Start an entry in the change log.
Compare the change to the existing baseline documentation and estimate the changes impact on time, cost and risk.
Document this analysis together with any assumptions and recommendations you make.
Meet with the sponsor, explain the change and its implications, and make your recommendation for acceptance or rejection.
Implement the sponsor’s decision; this may mean:

Explaining to the originator why the request was rejected.
For an accepted change making relevant changes to documents, publishing the new versions of the documents to all concerned, and making the new documents the new baseline.

And, in essence, that’s it. However, you may wish to consider a few small sophistications.

Tolerance

You may be able to create some room to manoeuvre in your project by agreeing some tolerance with the sponsor. Sensible tolerance (for example, some time and budget tolerance) may allow you to recommend acceptance of some requests for change as their impact is contained within an agreed tolerance.

Change log

You may find it instructive to record all incoming requests for change in a simple list or spreadsheet. Obviously such a log will make sure that requests for change are not lost or forgotten, but you can also learn much from just reading the log on a regular basis.

For example, you may find that you are receiving many requests from one group of stakeholders in your project. Maybe this is telling you that you missed them off a distribution list for a key project document.

In this way you may discover communication issues long before they become damaging to the success of the project.

You may also get some feedback about the quality of your own work. Many requests to change your design for a new office layout may indicate inadequate consultation on your part earlier in the project.

Note that the change log is simply that – a log. It may not contain the full details of the change, and it may hold the details of the implications in terms of time, cost and risk. These details will be held in your working papers. You may wish to refer to these working papers in the change log entries, just to preserve a cross-reference between all the details of the request for change.

This change log will also be useful input to the lessons-learned review at the end of the project.

The change log for the Lake project is shown in below:

Summary

Changes will occur. Publicise your change management system so that everyone can see that you are treating changes positively. Be fair with your estimates of potential impact, and always explain to the authors what happened to their requests. Feed the changes into the lessons-learned review.

Checklist

Publicise your change management system at project definition stage	And agree a process for reviewing requests with your sponsor
Make time to understand every request for change before you analyse its impact	You can turn this into a positive stakeholder management activity, as it shows that you are taking care over such requests
Analyse the potential impact on time, cost and risk	And there could be a potential impact on the eventual achievement of business benefit
Make your recommendations to the sponsor	The sponsor owns the decision
Implement the sponsor’s decision	Good communication with the originator is essential
Document your approved changes	Publish new baseline project definition, schedule, risk plan etc. as appropriate