Project Management Book

...chapter 2 continued

Manageable Chunks

We come to the last bit of this chapter (fear not, most other chapters are shorter). Manageable chunks or more formally Management Stages. You need to grasp this next bit or you'll be all at sea for the rest of the book.

Suppose you have a project that's five weeks long and employs you and one other person. Having spent a couple of days defining and planning the project would you feel reasonably confident about committing to the cost and end date, give or take a bit? Please say "yes". How about if you were the sponsor, would you be happy to give the project manager the whole budget for that little project in one go and say "see you when you've done it?" You would. From a control point of view our five week project has one Management Stage.

But your next project is rather different. It takes ten weeks just to define and plan it and you realise it will require many releases and Release 1 alone will take about 12 months and will employ around 100 people at the peak. At the end of the project definition stage would you commit head-on-the-block to the cost and end date of Release 1? Probably not. You might conclude that you can only really estimate and plan with confidence up to the end of the User Functions Design step, and only when you have done the UFD could you plan and commit the rest of the project. The project looks like this:

The project consists of two Management Stages. (And arguably three: if the Project Definition step is going to take ten weeks we might well want to manage that as a formal stage too.) You can now see why we have hitherto been using the term step (Requirements Analysis step, UFD step, etc.): to differentiate them from Management Stages. In our project the Requirements Analysis step and the UFD step make up Management Stage 1. Equally stages are not the same as releases: in our example Release 1 consists of two Management Stages (three if Project Definition will be a formal stage). From hereon we will usually refer to a Management Stage simply as a stage.

Before each stage begins the project manager commits to the cost and end date of that stage and gives an outlook for any later stages. Before each stage begins risks will be formally assessed, a detailed plan and schedule for the stage will be built, roles will be defined and assigned and resource commitments for the stage will be obtained. At the end of the stage the project manager must re-evaluate project costs and benefits and go to the sponsor for authorisation to do the next stage.

How long in elapsed time should a stage be? If stages are very short you'll spend your whole life assessing risks, defining roles and getting authorisations and get completely bound up in red tape. But by contrast if stages are too long you'll be trying to predict the unpredictable. As always in project management the answer is: it depends. Many factors will influence how long stages should be. But perhaps something between 2 and 6 months would be reasonable with stages typically 3 or 4 months long?

One might say that before each stage begins the project manager makes a fixed price contractual commitment to the project sponsor. We are beginning to apply the same sort of disciplines to internal company projects that would be applied to outsourced projects.

If at the start of Stage 2 the sponsor does not authorise Stage 2 in writing what is the project manager obliged to do? Stop work and send the team home. And wait for the sponsor to make his mind up either to commit the funds for Stage 2 or to cancel the project. This is not so much a discipline imposed on the project manager as on the project sponsor, to force him to make an informed business decision: is the project still a good investment for the company or not. Arguably too few projects get cancelled in this way, they roll on under their own momentum like a giant snowball even though the need for the project has long since melted away.

This principle of dividing projects into Management Stages for control purposes, and most of what follows in this book, applies to just about any sort of project that goes through steps such as design and build. If you wanted a new theatre built in your town you might get a fixed price quote from an architect to produce all the designs, then you'd get a fixed price quote for the construction.

(If this was a methodology textbook we would now invent a fancy name such as "Linear Contiguous Stratification" for this simple idea of dividing a project into Management Stages. Not only does it sound impressive, it would also mean we could set an exam which asks "what is Linear Contiguous Stratification?" and if you picked the correct multiple choice answer we could accredit you in our methodology and you could claim to be a qualified project manager. We could even trumpet to the world that we had a "new" way of managing projects, whereas what we actually would have done is coin a new term for a universally used technique - which is essentially what all methodologies do. We will resist the temptation.)

In conclusion, if the project team understands the work steps the project will use - the manufacturing process - and they understand the control mechanisms wrapped around that work you have a fighting chance your project will look like this:

Though we are quite sure you will not recognise any of these characteristics from your own experience. This kind of disaster project usually has one simple underlying cause: the project manager didn't do his job properly.

Privacy Policy and Cookies