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:

Project Definition
Defining project scope, roles, business case, etc.

Requirements Analysis
Defining in business terms the business data and business processes that are to be automated.

User Functions Design
Producing a system design that tells the users what the system will look like and what it will do.

IT Technical Design
Technical design of the system's internals, i.e. technical mumbo-jumbo that the user does not need to know about and wouldn't understand.

Build and Test
Build could be writing a million lines of new code or could be modifying a package or an existing bespoke system, and then testing that it does what the User Functions Design says it should do.

User Acceptance
The users say it's great and can go live.

  Stage 1

  Stage 2

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:

Business Need ---->

Project Definition

Requirements Analysis

User Functions Design

IT Technical Design

Build and Test

User Acceptance

Benefits Realisation

----> Happy Users

But if the team don't understand, your project will look more like this one:

   Business Need ---->

Wild Enthusiasm




Search For The Guilty

Punishment Of The Innocent

Promotion Of Non-Participants

----> Unhappy Users

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.

"A user is someone who tells you what they want the day you give them what they asked for."

Please click here to go to Project Management Book Chapter 3

project management book index    contact us    project management course  

Project Management Book
Copyright M Harding Roberts 2012 2013 2014 2015 2016 2017

Home   Sitemap   Contact Us   Project Management Articles   Project Management Book   IT Project Management Course