Project Management Book

...chapter 14 continued

You, or more likely one of your project definition team, write the project definition document (PDD) to record what everyone agreed at the PDW.

At the PDW the Marketing Director (one of the steering committee members) said: "sure you can have 3 guys for 6 weeks to define detailed requirements". Fine. But you must now finalise agreements with their immediate managers which 3 people and precisely when they will be available. You will have spoken provisionally to the resource owning managers earlier so this should be a matter of firming up the outline agreement you've already got.

At the beginning of week 9 you hire your quality leader and set him to work with the project leader to make sure quality assurance tasks are solidly included in the plan. The detailed task by task plan for Stage 1 begins to crystallise - you can now estimate Stage 1 bottom up and by hook or by crook get a clearer top down estimate for the remainder of Release 1. You add it all up and hope the answer is still around £1M (it is - but if it wasn't, you'd need to tweak the business case and have a quiet word with the sponsor). The more you know about the project the higher the estimate will be - which is why any initial guesstimates must have large amounts of contingency in them to allow for things you couldn't specifically itemise that early on.

So where are we? You've just about got everything done. You've agreed scope, roles and resources. You have a detailed plan for Stage 1 and outline plans for Stages 2 and 3. The Finance guys have helped build the business case and perhaps prepare a month by month project budget. You've agreed which people will be available, and when, to work on Stage 1: users, IT and anyone else we'll need.

You now write the stage agreement for Stage 1: what Stage 1 will deliver and when (requirements document, UFD, Stage 2 plan, revised business case, testing strategy, etc); risks; milestones; and most important of all: resources - who when; and maybe things people have agreed to deliver to you: before the end of Stage 1 you'll need the technical development environment set up and ready to go. You get resource owners to sign the Stage 1 agreement.

In reality these last 2 weeks of project definition will entail an awful lot of problem solving, negotiation and issue resolution. There will also be a lot of setting up to do: office space, time recording mechanisms, change control procedures, etc. The setting up of all of these will of course have been tasks in your project definition plan.

In week 10 you get the team together for a post mortem. How did we do? Could we do future project definitions better? The team distil out lessons learned and capture them in the stage end report (SER). If you have been time recording during the project definition stage, you attach a record of where the hours went. You might even attach a bar chart showing the plan you would have produced for the project definition stage with the benefit of hindsight.

When planning a project it's quite useful to start at the end and work backwards. At the very end you'll need a user satisfaction survey - when should that be produced? You'll need a handover-to-production checklist - when should that be produced? You'll need test data and before that test scripts and before that a test plan and before that a testing strategy - when will each need to be produced? All of these things - and many, many more - will feature in your outline plan for Stages 2 and 3 of Release 1 and help you work out costs and when you will need people to join the team. Throughout Stage 1 keep revising this map of Stages 2 and 3 as new things occur to you (they will).

At the end of week 10 you have the summit signing ceremony - the formal go no go - with the sponsor and anyone else he chooses to invite, perhaps the Finance Director and IT Director.

Your presentation demonstrates the project is indeed well defined and everyone has agreed the project definition. If you have kept the sponsor in the loop it should be a matter of saying: "Sponsor, as you know, scope has been agreed, Finance have signed off the business case..." etc. But there is one bit of bad news you must tell the sponsor about. Having added up the hours everyone spent on the project definition the actual cost was £80K versus your budget of £60K. The sponsor wraps your knuckles, tells you not to do that again, but nevertheless says you've done an excellent job turning his vision into a solid project.

You then present your Release 1 plan: a summary of the detailed plan for Stage 1 and your outline plan for Stages 2 and 3. You estimate Stage 1 will cost £400K and Stage 2 and 3 very roughly £600K - but you stress this is not a commitment, just your best estimate on what is known at the moment. To demonstrate that you have resource commitments for Stage 1 you then call in the waiting line managers and at your behest the sponsor asks each in turn if they really can make available the bodies shown on the Stage 1 plan, and they all commit eyeball to eyeball to the sponsor and then sign the Stage 1 agreement. Back out of that commitment if you dare.

The sponsor authorises £400K for Stage 1 and says: "As soon as you think it might cost outside a range of £350K to £450K come and tell me. Don't wait till you have overspent - is that clear?" Yes, sir.

And he gives you a cheque for £1000 - not for you personally but to take the team out to celebrate a project definition well done.

Did we take a risk by investing in all that project planning and for example in hiring the quality leader before we got the go ahead? Not really. In practice it becomes evident long before the end of project definition whether the project is going to fly or not. If, say, in week 6 it became clear the project was infeasibility, or would have a negative return on investment, or the company didn't have the people to do the project, you'd wrap it up then, hold a post mortem, produce a SER and get back in your car in search of a better brainwave.

You can perhaps see why a project definition stage for a large project needs careful planning. A lot of people have to do a lot of disparate things in the right order in a limited amount of time to get a project well defined. If project definition isn't carefully planned it will be chaotic and, more important, the project will not get properly defined or planned - and it's failing before it's even started.

But our project is well defined.

After the meeting the sponsor calls you back for a private discussion. He tells you that if you bring the project in on time, on or around budget and it works, he has agreed with the Board that you will be paid a large bonus and that another amount of money will be made available for you to disburse as bonuses to the project team at your discretion.

The project proper begins. You organise a kick off meeting. The sponsor tells the team - IT people and users together - the project is important and they, the team, hold a key part of the company's future in their hands and he wants it done on time, on budget and top notch quality. And if anything or anyone gets in the way of the project, just let him know. The team are enthused.

Ideally core members of the project team will have worked on the project definition so they have a good understanding of what's really needed from the project. Also, ideally, they will become the team leaders during the build and test stage and so carry that understanding right through the project.

The tough job of engineering or re-engineering business processes begins. Intensive workshops force the business users to define every item of data the system will have to handle (length, valid values, etc) and every operation to be carried out on these data (lookups, calculations,...), including exception routines, special cases, what happens when things go wrong, etc.

Luckily you have a tough business analyst running these sessions who calls a timeout whenever a user is unable to say exactly what is required and makes them go away and find out. This encourages them to come better prepared next time.

By the end of the requirements analysis step you must believe you won't need to ask the users anything else about what they want. Don't be tempted to leave tricky requirements to be defined later. To do this is to litter your future path with bear traps of your own making.

Every month you report status to the project sponsor in a monthly status meeting.

The team conduct thorough inspections of each section of the requirements document as it is finished. When the whole document is completed they run a simulation - pumping real test data through the business process, performing the validations and calculations, writing down the data that will appear on the outputs of the business process. Many problems are found. Most are gaps - the business process doesn't say what should happen in particular circumstances. It takes two weeks of stopping, plugging gaps and restarting to simulate the whole business process from end to end. Naturally this was in the plan.

The requirements document is published. The Stage 1 agreement will have said who will sign it off and how long they'll take (2 weeks?) to do it. One hopes they will have been involved all the way through the requirements analysis step and they or their people will have been involved in inspections and simulations so they know the requirements document is OK before they even get it.

...next

Privacy Policy and Cookies