Project Management Book

...chapter 13 continued

At the end of the project

Finally you reach the end of the project. Or more precisely, you reach the planned go live date - the project may not end there as we shall see.

Before the new system goes live there should be a mandatory presentation to the project sponsor, at the end of which the sponsor has to make a decision: whether it can go live or not. This should be done for both in-house and outsourced projects.

Think for a second - if you were the sponsor and your part of the company's business was due to be run by this new system as of Monday morning what would you want the project manager to show you before you'd give approval for it to go live?

Perhaps these sorts of things:

• evidence everything promised has been delivered
• evidence all required sign offs (as specified in the PDD and/or most recent stage agreement) have been achieved, e.g.
  • users
  • IT operations: they're happy to install and support it
  • help desk manager
  • audit
• users have been trained
• a fallback plan exists in case the system doesn't work
• disaster recovery is in place
• evidence the project manager has spent the change budget wisely and hasn't wasted it on 'flashing on and off pink' type change requests
• evidence that the system and other deliverables are fit for purpose
  • evidence that quality has been managed throughout the project
  • evidence that testing is complete as opposed to the end date has arrived
• a prediction of how many (unknown) errors might be in the system which will be found during live running - plus that number multiplied by the typical cost of fixing an error in live running

Let us consider the penultimate item on the list. How would we persuade the sponsor that testing had actually finished? Here is an example of the sort of chart we might show the sponsor:

Testing took 8 weeks and a total of 132 errors were found. The message of the chart is that no errors were found during the last two weeks of testing (and we would need to present data showing that testing was still being done in weeks 7 and 8).

If by contrast the chart looked as follows, have we finished testing?

Clearly not.

If you had to predict how many as yet unknown errors might emerge over the first few months of live running, how would you do it? At the simplest you could look back at past system and user tests and see what percentage of the bugs they usually find. So say for example it's normally around 90% and you found 180 bugs in testing this time, you might expect there to be around 20 in live running and you would bring a chart like this to show the sponsor:

Bugs @£10K predicted in live running

And the sponsor might invite you to put that chart up on your office wall and every now and again he would saunter past looking for the green line, the actual number of errors found in live running. If the chart looked like this after six months the sponsor would probably be quite happy:

Errors predicted vs actual in live running

But if you were the sponsor and you saw the chart at the end of month 2 and it looked as follows, what would you conclude?

Errors predicted vs actual in live running

You were conned at the go live approval meeting.

The appraisal of the project manager should remain open for a couple of months post cutover so that he knows quality will at least be an equal partner with cost and dates when determining his next pay rise. If right from the beginning of the project the project manager knows he will have to predict the number of live errors at the go live approval meeting he has an incentive to manage quality properly so that a) he will be able to predict a low number and b) he will be able accurately to predict the number: his appraisal depends upon both of these things.

...next

Privacy Policy and Cookies