Project Management Book

...chapter 14 continued

Work begins on the user functions design (a.k.a. functional spec, external design,...). Joint user/IT teams evolve the user-visible functions of the system: screen/web page layouts - should the 15 data items that comprise an order be input on one screen or several? Output document layouts - how should the 21 data items that comprise an invoice be laid out? The IT team design all the invisible user functions and the system's infrastructure.

At some point during the UFD step the techies, who will later do the IT technical design, do a quick preliminary technical design just to make sure what is being proposed in the UFD can be built. Indeed they may suggest changes to the UFD to make it simpler/easier/cheaper to build.

As each UFD section is completed it is inspected - users, other UFD designers, technical designers and test team members are all involved.

Once the UFD is finished, a major simulation exercise is undertaken. Someone pretends to be a customer accessing the order entry web page. Someone else writes down the data that the 'customer' entered (e.g. customer number 326-086). The simulation team perform the edits specified in the UFD. Data is stored on flip charts. Output documents are compiled and written out by hand. This is simply people pretending to be a computer, simulating what the machine will do when the code is written. Areas that caused concern when the business processes were simulated during the requirements analysis step are given special focus.

If you can do the simulation you probably have a reasonably good UFD. If you can't do a simulation because the UFD is vague, incomplete, wrong or incomprehensible, stop the clock, delay the end date of the UFD step and get the UFD right. If you carry on regardless you'll just have a much bigger delay later.

The quality leader is strong and ensures all the planned quality checks are conscientiously performed.

Midway through the UFD step an independent team come in and do a health check. They conclude you're pretty much on schedule, on budget and the evidence suggests the UFD will be a high quality document: complete and correct. The health check team give your project an A rating.

Six weeks or so before the end of Stage 1 what must you do? Start planning Stage 2 in detail, negotiating for resources, assessing risks, etc. You estimate the cost of Stage 2 bottom up and revise the top down estimate for Stage 3. You add those two numbers to what will have been spent on Stage 1 to get a revised total project cost.

And does it add up to £1M? Er, no. It comes to £1.3M. Do you wait until the formal go no go meeting at the end of Stage 1 to spring the surprise on the sponsor? Definitely not. You go and have a word with him now, a few weeks before the end of Stage 1. The extra £0.3M, however, is way beyond even his tolerance so he goes to the Board and manages to acquire the extra £0.3M.

You publish the UFD for sign off - which again should be a formality given the users' involvement in the inspections and the simulation.

Line managers commit resource via the Stage 2 agreement. You hold a post mortem and produce a stage end report for Stage 1.

Why is there a 2 week delay before the formal go no go meeting at the end of Stage 1? To allow for issue resolution, time to get sign offs, etc. But of course work begins on the IT technical design in the meantime.

At the formal go no go meeting you tell the sponsor you've achieved all the required UFD sign offs and there are no open issues (if only it were so!) and that Stage 1 actually cost £445K - just within tolerance. This figure does not come as a surprise to the sponsor as you will have been revising your prediction of this figure at each monthly status meeting.

You prove you're ready to start Stage 2 and the sponsor approves its budget of £600K plus or minus 10%. IT technical design and build run like clockwork because the UFD is complete, correct and stable. Integration test goes remarkably smoothly due to the very detailed planning dovetailing build, handover and component testing. In the penultimate monthly status meeting of Stage 2 you predict Stage 2 will probably come in a little under budget at around £550K.

At the end of Stage 2 the pattern is repeated. What is the implication of the fact there are no double arrows up to the 'Project Authorisation Body' at the end of Stage 2? You still think it's going to cost around £1.3M. The sponsor does not need to go back to the Board with his begging bowl.

But why might the sponsor cancel the project at this meeting? Because the projected benefits have evaporated - maybe somebody beat you to that market opportunity. This is why we should re-examine both costs and benefits at the end of each stage.

But our project's benefits are still there. Having shown you have Stage 3 planned, resources committed, etc you get the go and a Stage 3 budget of £250K.

However, a remarkable thing happens during Stage 3. The system test plan took no account of all that quality checking you invested in up front. System test finishes two weeks early as you have run out of bugs to find. And this is two weeks earlier than planned - probably a couple of months earlier than everyone was expecting given the usual slippages that such projects encounter.

System tests always overrun, don't they? Not if you really do get the design complete and correct. Users are trained, roll out is readied, system documentation is finalised.

...next

Privacy Policy and Cookies