Oh, alright, I admit it, that’s just a tad melodramatic. But when you have been working hard to deliver a project, having the goalposts moved can feel almost like a natural disaster, an earthquake knocking you down. This is only to be expected – we all like to think we have control of our work, so it can come as a genuine shock when circumstances prove us wrong.
But, as I have written before, project management can be described as being about managing change effectively. Normally, the change is what the project is trying to achieve, bringing about a beneficial change. A consequence of working with change, though, is that a project itself is almost guaranteed to undergo changes.
This doesn’t have to be a bad thing. Nor, of course, is it necessarily a good thing. But it is something that is going to happen, whether you want it to or not. There’s no point in pretending it doesn’t, or resisting it when it comes along. Far better to deal with the requests for change that crop up – you never know, they may actually make your project better.
So how can we handle these requests for change? Well, now that we have accepted they will occur, we need to make sure we capture them. A change request that comes in should be recorded. You must capture these requests, and make sure they are dealt with. But how they are dealt with can vary.
The first thing to check is – is this really a change? Has the person asking for this change misunderstood or misread the project requirements? Are we actually already doing this? Believe me, this happens far more than you’d imagine…
Now, if it really is a change, you need to prioritise the importance of it. This can vary from an absolutely vital change, to something which is a purely cosmetic change. Try to have a set of different levels. I’ve used a system of four levels before, those being:
- Vital – the output of the project will fail if the change isn’t made
- Important – not having it causes problems, but it could be put up with or worked around for a short period
- Desirable – the change would be beneficial, but the output can still be successful without it
- Cosmetic – unimportant, has no effect on the usefulness of the output
So, you’ve worked out the priority. Now you need to figure out what impact making the change would have. Obviously this is going to vary massively depending on the change, the project, the environment, and so on. But the best place to start from is by analysing what would actually have to change. By this, I mean analysing the change to understand which parts of the project work would have to be done differently, or again:
- What has to change?
- How much effort will this require from the project team?
- How much will it cost?
- Will something else in the project, or linked projects, have to be dropped or altered to make the change?
- What effect will it have on your project schedule?
- Will the change introduce new risks, or get rid of old ones?
- And, importantly, what effect does it have on the Business Case?
Now we have a judgement of the priority and impact of the change, we can start to make an educated decision about whether to make the change or not. But remember, you are working on behalf of the Executive – ultimately, any decision about change is their responsibility.
In general, if the priority is Desirable or Cosmetic, and the impact is low (i.e. can be done well within the tolerances you have been set) then I’d probably just go ahead and make the change, though I would make sure it was flagged up to the Executive. If the priority is higher, or if the impact is higher, I’d refer the decision up to the Executive, unless they have already put some other mechanism in place for approving change.
You may have realised that means I would refer up a decision that was of Vital priority, but very low impact. Why? Why would I not just go ahead and do it? Well, two reasons.
Firstly, if I believe a given change is very low impact but Vital priority, that suggests to me I may have missed something – I want to make sure I take advantage of the Executive’s knowledge of the environment and organisation to confirm my thinking before I go ahead with any Vital change.
Secondly, if the project has managed to get approved with what may be a major flaw like that, I want it to get a good looking at. Has the change request come about because of a dramatic change in the external environment? Has this environment change been factored in to the rest of the project? Did we capture this on the risk log? Do we need to re-evaluate the whole Business Case?
Basically, if there is a change request that is Vital, I want to make sure that we haven’t just been struck by an earthquake, that the ground we have been building our project on really is stable enough to carry on. And that’s a decision that needs the expertise and wisdom of the Executive – after all, it is their neck on the line if it all goes wrong!
What about you? How do you deal with changes? What tricks have I missed?
(Image courtesy of videocrab / Kevin Simpson. Some rights reserved.)