Project Management Book

...chapter 4 continued

5. Now define the project

Now and only now can we really begin to pin down the project that will need to be done in order to deliver the chosen solution.

Of course, one project definition stage could spawn a huge programme comprising a multitude of projects. Let's keep it simple: our project definition will result in one new system being developed. You now start hawking the proposed system around to potential users and they all get very excited: "what a great idea! And could the system also include reconciling physical stock with stock value in the accounts? And if we could handle international transfers we could use it in the Jersey branch too. And if it could do what we in Logistics have always wanted which is to..." And so the list goes on and on. And it dawns on you, the project manager, that if you tried to deliver everything that everyone would like in one go you'd be facing a big bang disaster project.

So you decide to break it into releases and you determine what will be included in Release 1. Why will that simple sounding step be a thousand times harder than anything we have done so far?

You must tell some very senior people that what they would like won't be in Release 1, it'll be in Release 3 - maybe. Will they say: "OK, that's fine"? Don't think so. They will escalate to the sponsor, threaten to withdraw support for the project, tell you you certainly aren't having any of their people for the project, brow beat and bully you, exaggerate the benefits of the things they would like included, claim their thing is a legal requirement, undermine, blackmail, bribe (if you're lucky), etc to get their pet things into that first release.

Will this be a pleasant way for the project manager to spend a few days? It certainly won't - these can be very bruising discussions. The temptation is obvious: avoid the question of scope altogether, leave everyone assuming that everything (including things they haven't even thought of yet) will be there on day one.

If it's a small project this will not be a problem - you can easily do everything in one go. If it's a large project you may have just secured project failure, or at the very least caused major grief during the project. This is where you can make or break large projects.

Take a tough line. Carve out a doable scope. In principle include in Release 1 only those things that are absolutely essential on day one, those things that constitute a useable system that can go live and at least run some part of the business.

Just possibly there is no useable sub-set, absolutely everything has to be there on day one and maybe it has to be done in one three year long big bang. If so, good luck. (And a pound to a penny says it ain't true - there's always some stuff you could leave till later.) But even here beware, for having concluded that all the headline functions must be there on day one, that may be construed as carte blanche to embellish those functions with quite unnecessary bells and whistles. Certainly, including in Release 1 unnecessary bells and whistles on functions that aren't needed in Release 1 is the most heinous sin of all. It really is quite easy to make a software project four times bigger than it needs to be, as the chart on the left suggests.

Any mug can be everyone's friend at the beginning and say: "You want that included? Sure, I'll put it in for you." Good project managers know how to say "no": politely, firmly, rationally: "no".

If we survive that, we now have what we believe to be a sensible scope for Release 1. That outline business case we put together earlier may now need considerable rework: we must produce a business case specifically for Release 1, maybe with high level cost benefit guesses for subsequent releases.

Obviously, therefore, there will in practice often be considerable overlap and iteration between this step and the previous one, to the extent that the previous step may be completely subsumed into this step and a business case only produced after the Release 1 scope has been thrashed out. As always these things can be almost infinitely variable in practice (which is all part of the challenge that projects present).

Whether or not we produced a rough business case earlier, we now have a more precise cost benefit case for Release 1 that we can take to the sponsor. Having said: "how much?", he takes the business case to the Board of Directors who having said: "how much?" approve (we will assume) Release 1 funding in principle.

Now we can get down to defining the other aspects of the Release 1 project:

• decide who should be on the steering committee
• define and agree roles (at least for Stage 1 of Release 1, which we will say is going to be Requirements Analysis and User Functions Design)
• determine the development approach, the manufacturing process: RAD, Waterfall, Extreme Programming, package modification...
• determine how the project will be managed: issue handling, change control, status reporting...
• etc

Serious discussions about resourcing can begin.

We are now in week seven of our ten week project definition phase. It is all beginning to come together. We now hold a pre-planned, per-diarised Project Definition Workshop (PDW). The attendees will be:

• project sponsor
• steering committee members
• person who will manage the project (will not necessarily be the person who is managing the project definition stage)
• other key role players (project IT manager, project user manager, project office manager...)
• independent facilitator to run the meeting

The aim of the PDW is simple: to ensure all of the above have the same understanding of the project. The agenda should therefore include:

• project's goals and objectives
• business case summary
• scope and contents of Release 1 and outlook for future releases
• outline schedules
• staging and go no/go points
• roles and responsibilities
• who will supply what resources when
• how status will be reported, how change will be managed, etc
• risks and how they will be managed

Imagine that in spite of six weeks hard work prior to this PDW, at the meeting nobody can agree to anything. Is that a success or a failure? A bit of both maybe, but on balance a huge success: you may have just averted a major disaster. And it happens: you thought everyone understood and agreed, but they didn't. Sometimes you can have a one-on-one discussion with someone about their project role and they will agree it. But repeat exactly the same words to them in a public meeting like a PDW and they start to get cold feet and back away. Hold their feet to the fire, get them publicly to commit to their responsibilities and accountabilities. Given that all the key role players are present some adjustment of roles may take place during the meeting.

If the meeting does fall apart because there are major disagreements there will be a few days of urgent lobbying to do and even a second PDW to be held. (This is a good example of the difference between theoretical planning and real world planning. In theory, because of all the preparation, when the PDW is held everyone agrees to everything, so the plan shows one PDW. In reality people don't agree and further work and a further PDW is needed. A real world plan allows for this: it doesn't have to assume the worst case in every case, but equally should not assume everything will work out perfectly first time every time.)

What is in a Project Definition Document (PDD)? Fundamentally the things we listed as the PDW agenda. Indeed, the minutes of the PDW meeting could become the basis of the PDD. In principle a PDD documents what all the key players have already agreed to. A Project Definition Workshop (PDW) is an affective way of ensuring you have that agreement. Never write a PDD in secret and surprise the world with it.

Every methodology has its own take on what a PDD should be called (Project Initiation Document, Project Charter, Project Definition Report, Project Terms of Reference, even Business Case) and what it should contain but they all boil down to more or less the same things. See the Appendix for a suggested PDD table of contents.

One point worth making here: always have a project organisation hierarchy chart in the PDD. Don't just list the roles and role players. The hierarchy chart makes it clear who reports to whom. (It is not unknown for this chart to be omitted because it might upset someone to discover they were reporting to a person junior to them in job grade terms. But that's projects. If the project is to get done the project manager (and others) may well need to have more senior people taking direction from them. Project-based companies take this for granted but it can cause real unease in process-based companies where there is a clear pecking order based on job grade.)


...next

Privacy Policy and Cookies