Project Management Book

...chapter 11 continued

It's Not Easy To Estimate The Cost Of A Change

Estimating what a change might cost can be very tricky. Back to that house you are having built for you. At the design stage you want a window moving 3 feet to the left. The change won't cost much and it is very clear to the architect what the cost will be - he's just got to change the drawings.

However, when the house is nearly finished how much will that change cost? A lot of money - that's obvious. What is less obvious is this: the builder thinks he'll send someone with a large hammer to knock some bricks out of the wall, move the window across and brick up the other side - to you £1000. But when he's knocking the bricks out of the wall what does he discover? A water pipe or a power cable, so he has to get the plumber or electrician in. The change costs a lot more than he estimated. If he has given you a fixed price quote that's his tough luck, but in IT projects the user ends up paying one way or another whatever IT say the change will cost. People tend badly to underestimate the cost of changes that come along later in the project.

It is worth recording the estimated cost of each change and recording what each change actually cost and then working out by how much PCRs at each stage tend to be underestimated. These wobble factors can then be used as fairly crude adjusters next time around. So next time, you estimate a change during build will cost £2000 but you know you usually miss things and changes at this stage typically cost 50% more than estimated, so you quote £3000 as the estimated cost to try and give the user a more honest view of the likely true cost of the change.

The later the change comes in the more it will cost and the more it will tend to be underestimated, as illustrated by the graph. Beware of taking on changes during the later stages of testing - one small slip can cause significant delay and the change can cost many many times more than expected.

If you're managing a project where development is outsourced to a software house and you want a change that the software house knows you have to have, how much can the software house charge you for that change? Anything they like.

This should be a powerful incentive to get the requirements and the UFD right in order to avoid these potentially huge change costs. A fixed price contract is only a fixed priced contract if you don't change your mind. If you do keep changing your mind it will be the fixed price plus a very large amount of money. In the next chapter we will address how we might try and get it right at the requirements and design stages.

A software house can make a lot of money on change requests, so one might argue that maximising change is in their interest. Not necessarily so. There can be so much change that the project gets out of control and fails - that does neither client nor supplier any good. And even if the project eventually delivers, the client may feel they have been taken to the cleaners on change and go elsewhere in the future.

Being everyone's friend and saying yes to change is easy. Saying no isn't quite so easy. In a project some change will be essential to the user/customer/client. From the project manager's point of view all change is bad news: it is disruptive, tends to introduce errors and can have unforeseen consequences. Minimising change is in just about everybody's interest. But if we go back to our roles chart, which of our generic role players should be the first line of defence against non-essential change?

The Project User Manager. On a well set up project it might work like this. The sponsor says: "I understand we need to set aside 10% of the project budget for essential changes. Project manager, please come and account to me at the end of the project how you spent my change budget and woe betide you if you wasted it on flashing-on-and-off-pink type change requests." The project manager will exhort the project user manager saying: "you are closest to the real needs of the business, only allow through changes that really are essential."

A good user project manager is worth his weight in gold. He knows how to say the all important word: "no". Politely but firmly: "no" - unless it is essential or has an overwhelming business benefit. A good defence against potentially valuable but not absolutely essential PCRs is to make them candidates for a future release. The PCR is closed and an Improvement Request (or whatever you call such things) is raised which will subsequently compete for inclusion in a future release.

A good user project manager won't even let people raise a PCR form for trivial changes as they clutter up the works and cost money to administer, let alone to investigate.

For internal company projects approving change requests does not feel like spending real money, and user reps can end up approving change like there's no tomorrow.

In one case a large project had a project user manager and 5 business areas whose requirements would be met by the system under development. The project user manager and 5 user reps were the first level change control decision makers. Hitherto they had been approving any change that anyone felt was desirable and the project was being engulfed by a tidal wave of changes and sinking fast. A new process was instigated. At the first meeting the user project manager said: "who would like this change request included in the project?" Five hands went up. "Under the new process I must tell you that it will add £10,000 cost to the project, do you still want it?" Again 5 hands went up. "And under the new process I have to ask you: whose departmental budget is the £10,000 going on to?" No hands went up - nobody wanted it that much. Find some way of making it clear to those approving change that it is real money they are spending.

In weekly team meetings mention every change that has been approved in the past week. Someone may pipe up: "don't you realise that affects all the training materials I've developed?" And you didn't. Make sure the team know about all accepted changes.

Change can cause major difficulties if you're not careful. In one case on a commercial project the software supplier said they would charge to investigate PCRs unless the investigation would cost less than a man day, in which case the investigation would be done free. Good idea?

The project ran into difficulties. The project manager was replaced. The new project manager found 4,000 PCRs sitting on the backlog awaiting investigation, each of which it was reckoned would cost less than a day to investigate. What would you have done? Apparently the new project manager went to the customer and showed them a list on his laptop of the 4,000 PCRs. He said he was contractually obliged to investigate them for free but he said: "I'm not going to." And he then dramatically pressed the delete key and they all disappeared. He said if any were really important re-raise them - and sue if you want to - but otherwise they no longer exist.

Brave man! But everyone knew they were just so much clutter and were pleased to see that at last someone was prepared to take a hard line on this and other matters and get a grip on the project.

Are errors found in system test PCRs? If the system is not performing as per the user functions design that is an error - it is not a change request. If the system is performing as per the UFD but someone wants the system to do something different that is a Project Change Request (PCR) - even if the UFD is plain wrong it's still a PCR. The developers are contracted to deliver whatever it says in the UFD: if you want something else delivered that's a change and it will cost you. So get the UFD right. See the next chapter.

Finally,

• Be realistic, you'll always get some change
• Include a change budget in the overall project budget
• Make someone accountable for how the change budget is spent
• Design Issue and Change Control procedures that meet the needs of your project
• Good control is forward looking. Always ask: how much have we spent so far on change and therefore how much more do we think we will need to spend on change. If it becomes clear half way through that the change budget is nothing like big enough get more change budget now from the sponsor, don't wait till it's all been spent.
• Minimising change in a project is in just about everyone's interest.

Please click here to go to Project Management Book Chapter 12

Privacy Policy and Cookies