Project Management Book

...chapter 13 continued

Occasionally as a project's end date nears it becomes apparent that the quality won't be right by the planned end date - there isn't enough time left to get the bugs out. An emotional debate about quality can ensue.

With good quality management something a little more rational becomes possible. "Sponsor, sorry, but if we go live on the planned date of June 1st there will be 100 or more errors in live running and it could cost us £1M to sort out the mess. If we delay by 6 weeks to mid July it'll cost £100K in extra test costs but there should then only be 15-20 errors in live running. What would you like us to do?"

The sponsor might say: "Go live on June 1st as planned. We have a one off opportunity in June to win £500M of new business - we'll bear the £1M failure cost." Or he might say: "Delay till mid-July. The last thing we need is for this thing not to work properly and get us a bad reputation in the market place - that could cost us dear. Get it working properly asap then come back and see me."

The debate becomes more business-like. In extreme cases going live with systems that don't work can drive a company into bankruptcy.

When does the project end? In the PDD or final stage agreement be clear about this. You might say: 'the project ends on the day of cutover.' Or you might say: 'the project ends 2 weeks after cutover' which implies the project team stay together for a couple of weeks to sort out any production problems.

Final stage end report

We mentioned stage end reports earlier. At the end of the last stage the final stage end report should look back over the whole project and record total project metrics as on this template:

It then becomes relatively easy for project support to distil out some of the rules of thumb we saw in the estimating chapter such as the percentage of project effort that is spent in the requirement, UFD, IT technical design, build, test and UAT steps and the relationship between IT effort and user effort in each of those steps.

And project support can do simple things like emailing project managers every now and again saying things like: "you might like to know that our best quality projects invest around 12% of the hours in the UFD step in inspections and simulations. Also, rework following UFD inspections is usually around 9% of the time it took to produce the work in the first place." It is surprising how quickly the knowledge level rises and people begin to assume all humans are programmed at birth with the knowledge that post-inspection rework is around 9% (surely everybody knows that...?). In the buzz phrase we become a 'learning organisation'.

User satisfaction survey

Maybe some time after the end of the project users should be surveyed to see how they feel about the new or enhanced system. The survey might ask questions such as:

• Does the system meet the business need?
• Were you or your representative adequately involved in defining the business requirements?
• Were you or your representate adequately involved in reviewing and approving the system design?
• Is the system easy to use?
• Is help and support available when you need it?

And no doubt you can think of a host of other thinks we should ask the users, including 'how could the system be improved?'

Questions such as 'Were you or your representate adequately involved in reviewing and approving the system design?' may prompt the reaction: 'gosh, should we have been involved in reviewing the design? That would have been a good idea!' which could lead to better user involvement in future projects.

If the project manager knows right at the very beginning of the project that this survey will be done at the end, and the results will feature in his appraisal, he'll probably look at those questions at the outset and try and ensure the project does the things that will yield positive responses to the survey - like involving the users properly at the appropriate time.

...next

Privacy Policy and Cookies