Project Management Book

...chapter 10 continued

Stage authorisation

At the start of each stage the sponsor gives the go ahead and approves the stage budget. Sometimes whether we go or no go isn't in doubt - there's no choice - and it's not so much a meeting to decide go or no go as to demonstrate readiness to begin.

If we're not as ready as we should be the sponsor may give a conditional go: "well, you can start but I'm not satisfied you've got necessary resources properly committed. Get it sorted out and come back and see me in a week's time. And let me know if I can help." We are starting with more risk than we would ideally like, but that's the real world. And as we said earlier, having to present at these meetings is a powerful incentive to get things properly planned.

When we reach the end of Stage 1 we have two things to do: prove we have finished Stage 1 and invite the sponsor to take out his chequebook and fund Stage 2.

For illustration: "Sponsor, we have finished Stage 1. I said it would cost $300K, it actually cost $315K - a bit over budget but well with tolerance. We finished the stage on schedule and we have delivered everything we committed to deliver (UFD, Stage 2 plan, revised business case, testing strategy, etc). We have all the requisite sign offs (here they are...) and there are no issues open on any of the documents we have produced." If that's all true the sponsor says: "Well done, I agree you have finished Stage 1."

But if by contrast the project manager says: "The end date of Stage 1 has arrived. We have published the User Functions Design document and there are currently 99 open issues and everyone has refused to sign off..." Have we finished Stage 1? Certainly not. We must demonstrate that we have finished the work and met the completion criteria specified in the stage agreement.

Without this kind of discipline what happens? Nobody signs off the UFD, work continues regardless and when the system is delivered everyone complains that it's wrong and isn't what they wanted. This is completely unacceptable. If people will not sign off the UFD we must crystallise the issue and deal with it or we must stop work while people make up their minds. The premise being that every day you delay signing off the UFD delays delivery by a day. This is another nuclear deterrent. You hope you never actually have to stop work but the threat must be credible and fully backed by the sponsor. This gives you power to twist arms: either sign off or tell me clearly why you cannot sign off or we will stop work and wait until you make your mind up.

As an example of this. At the end of the design stage of a project the business users, in Finance, just would not get around to reviewing and signing off the design document. After the usual channels had been exhausted the matter was escalated to the IT Director. The IT Director phoned the Finance Director on Friday lunchtime and said: "unless your guys get their fingers out and sign this thing off, or tell us what's wrong with it, as of Monday morning I'm reassigning the technical design team to other work. We're not going to deliver this thing and then have you tell us IT got it wrong again." This was a fairly brave thing to do because at the time the IT Director reported to the Finance Director! The sign off was forthcoming within the hour.

If we persuade the sponsor that Stage 1 has been finished we then seek authorisation for Stage 2: "Sponsor, four months ago at the beginning of the project we gave you a top down estimate of $1M for the whole project. Having finished Stage 1 and re-estimated we now think the project will cost $1.4M. The benefits are, however, much greater than we first thought so I recommend we continue despite the estimated cost increase."

Why might the sponsor cancel the project at this meeting even if the cost estimate has not increased? The anticipated benefits may have dribbled away - we're better to cut our losses and cancel the project now. We are forcing the sponsor to make a decision: carry on or stop. Without this, some projects simply roll on under their own momentum even though their raison d'etre has long since evaporated.

In theory Stage 2 should be authorised before any work is done on Stage 2. In practice the rule might be that you can proceed 2 weeks into Stage 2 before it is formally authorised. In other words there are 2 weeks to sort out any issues and get things signed off. When you're one week and 4 days into Stage 2 the arm twister then becomes: "If you don't sign off by Friday the rules mandate that I must go to the sponsor on Monday morning and ask him to stop the project and redeploy the team onto something else while you make your mind up." Address and resolve issues, don't sweep them under the carpet and have them explode all over you at the end of the project.

Without the go no go meeting with the sponsor - the summit signing ceremony - it is much easier to fudge these things, drift from one stage to the next and leave UXBs (unexploded bombs) all over the place.

Definitions

Checkpoints and milestones are not the same thing. A milestone denotes an achievement: a workshop has been held, a document has been published, a document has been signed off - the last of these being the best sort of milestone as it signifies real achievement. Publishing something is easy, getting it signed off is much more significant.

A checkpoint is a point at which one checks things, e.g. a status meeting in which one checks whether milestones have been achieved or not.

Original plan, baseline plan, latest plan, latest approved plan, current plan... It's amazing how many names people will invent for various versions of the project plan. One way of using some of these terms might be:

• Original plan. The plan you started the stage with. By definition this plan can't change. At the outset, since there is only one version of the plan, the original plan, baseline plan, latest approved plan, etc are one and the same thing
• Latest approved plan. If during the stage the sponsor approves a change to the stage's commitments (revised budget, different dates, etc) the plan that supports these new commitments is the latest approved plan. Some would call this the baseline plan or the new baseline plan or the latest baseline plan.
• Latest plan. The project manager and team leaders will have a working level plan that shows when individual work tasks will be done. This plan can be changed quite substantially without affecting commitments made to the sponsor. This 'latest plan' is the one against which the project team is tracking its progress. If they achieve it they will achieve commitments made to the sponsor.

If you speak to ten project managers you will probably get eleven different opinions of the above, but whatever you call them there will usually be several versions of 'the plan' scudding about. As long as you're clear what they all are, call them what you like - though consistent naming within your company would obviously be a good idea.

Objective, factual reporting

Objective, factual, numerical reporting makes it much harder for the project manager to hide problems and much harder for senior managers to ignore painful reality.

Having to present status face to face means the project manager has to know what's going on in his project.

All (large) projects should report using the same reporting template - senior managers soon tune in to the language of the numbers.

Most businesses employ fewer than 10 people but must report numerically in their annual report and accounts. Many projects employ more than 10 people. Look upon these larger projects as a small business: they require the same sort of entrepreneurial flair, leadership and control that a small business requires.

Before your project begins you must decide what you will track and how you will control. For a small project a Gantt chart on a whiteboard with the plan as green bars and the actual as red bars may be all you need. For large projects you will need something of the sort we have described. For very large and complex projects you may well require sophisticated critical path analysis software to guide you through the maze. Decide what's appropriate for your project, design controls accordingly and allow time in the plan for gathering, analysing and reporting status data.

In a large project that does not have any factual status reporting data the following does, and will continue to, happen:

• On Friday afternoon the IT team prove to the IT team leader that the project is dead in the water, and it is, but there are no numbers to prove it.
• On Monday morning the IT team leader tells the IT project manager: "there are major problems, we aren't going to make it", but there are no numbers to prove it.
• On Tuesday morning the IT project manager tells the project director: "there are some big problems, it looks rather doubtful", but there are no numbers to prove it.
• On Wednesday morning the project director tells the project sponsor: "IT have some problems, but they always say that don't they?".
• On Thursday morning the sponsor tells the Board of Directors: "it's business as usual, it'll probably be OK."

It's gone from being dead as a dodo to probably OK because each person changes the message a bit on its way up. But if even the sponsor when reporting to the Board must show the sort of numbers we have seen, that can't happen. The Board can read the numbers as well as we can - probably a lot better than we can. However high the reporting goes some numbers should be presented. Just like company accounts.

And finally

• You cannot control unless you have a plan
• Good control detects problems early
• Early detection makes resolution easier
• If in doubt assume the worst case until something better is proven
• With facts it's harder to hide the truth and harder to ignore the reality

Please click here to go to Project Management Book Chapter 11

Privacy Policy and Cookies