|
|
If you saw a stage agreement like that, signed by the resource providers, to which was attached a plan of the sort we explored in chapter 7 you would probably have this feeling: the project manager knows what he's doing.
Suppose there was a rule in your company that before any stage could start you, the project manager, had to make a 20 minute pitch to the sponsor essentially presenting the contents of the stage agreement to demonstrate that things were planned, resources committed, etc. Would you go to that meeting saying: "er, the plan isn't quite done yet, we haven't got any resource commitments yet and the costs are being looked at by Finance..."? You wouldn't. As the date for that sponsor presentation approaches it focuses the mind wonderfully and is a real incentive for the project manager to get off his backside and get things sorted out.
How would you persuade the sponsor that resource owning managers had committed resources? Show him their sign offs (in most organisations an email suffices as a sign off). Even better than that, bring those managers to the meeting and have them commit eyeball to eyeball to the project sponsor (and then sign). Much harder to renege on that commitment.
And in this short meeting, how would you persuade the sponsor that the plan is viable and realistic? Present a one page summary plan signed by every team member as evidence they think they can do it. That is very persuasive. Compare it to past projects. Show evidence that project support have looked at it and OKed it. And bring a ton of backup charts showing every single work task and threaten to show them all if he still doesn't believe you!
But what if a few days before you are due to make this presentation to the sponsor you email G Smith, the HR Manager inviting him to sign the stage agreement to confirm his verbal agreement. There is no reply, so you go to see G Smith but you can't get hold of him. You find his boss who says: "resource commitment? That's news to me you need to talk to G Smith." Tomorrow morning you are due to make the presentation to the sponsor either to ask permission to start the stage or to explain that start must be delayed because you haven't got G Smith's sign off.
You ring the sponsor asking if you can delay the meeting as you haven't got G Smith's written resource commitment. A half decent sponsor, satisfied that you've done what you can and now facing a delay to the start of his project will say: "leave it with me".
G Smith gets a call from the sponsor asking whether he will be able to supply the 2 people as verbally promised. If you were G Smith would you now want to be saying: "I'm sorry, I know I promised them but I didn't really think about it and actually I can't supply them." You would not want to be in that position.
But if you knew that would be the consequence of making empty promises you'd probably think a lot harder about it before making even a verbal promise.
As project manager you want to find out before you commit whether resources really are going to be available or not. In the example, if those 2 HR people really cannot be made available the go no go meeting will have to be delayed while you do some speedy replanning, see what can be done with resources that can be made available - which may mean higher costs and later delivery dates - and then go to the sponsor with a revised, well founded plan that you have a reasonable chance of achieving.
In reality we all know people in our own organisations whose promises we know will be fulfilled. And we may know people who will promise almost anything we ask for without really thinking about it. If you suspect the latter, you would not leave it until a last minute panic, you would be talking to that person a week in advance, helping them think about their resources, other commitments, etc helping them understand whether they really can support your project, so that when they do promise you're fairly confident they will be able to deliver.
If there is a rule in place: 'no sign off no start', it does focus minds and make it less likely your plan is built on sand. When you commit it's based on rock-like commitments made to you. Written commitments won't guarantee resources will actually turn up as committed, but it does make it a lot more likely. 'No sign off no start' is like a nuclear deterrent: you hope you never have to use it but the threat must be credible.
Either the resource is committed and the project manager commits on that basis or the resource cannot be made available and the project manager replans and commits on some other basis.
For large projects it is worth considering having the project sponsor send the stage agreement out requesting
resource commitments with a covering note saying something like: "Thank you for agreeing to support this key
company project. Please confirm your commitments as documented herein to me in writing within 2 days." So
resource providers commit in writing to the sponsor - they will probably be less inclined to renege than had
they committed to the project manager. Of course, the project manager has drafted the sponsor's note and all
the sponsor has done is agree that the note can go out in his name.
Programmes
We have described how the project manager demonstrates readiness to start a stage by a short presentation to the project sponsor.
The same principle can be applied by managers of programmes: before each stage of each sub project can begin the sub project manager makes the same sort of presentation to the programme manager. If several sub projects are starting at the same time have all the sub project managers present at the same meeting. This will sometimes identify overlaps and gaps: two sub projects thought it was their job to produce the UAT plan - or worse, nobody was going to produce it.
It may well be that in practice there is no option but to start, so the presentation becomes a readiness review. But if you were the programme manager and a sub project manager came to you seeking the go for a sub project, but it is abundantly clear that the plan is half baked, estimates are vague and no firm resource commitments are in place you might:
Benchmark, foresight, relationship to PDD
The stage agreement also provides a benchmark against which the project manager's performance can be measured: he has said very clearly what will be delivered at what cost by when and with what resources.
If you were a line manager and a project manager asked you for two people to do some testing starting
tomorrow morning, you might try and do what you can to help but politely point out to the project manager
that next time would he please give a bit more notice. A stage agreement mandates and formalises that
notice.
|
|
In a large project or programme there will be an overall PDD which outlines the many sub projects, stages, etc. If you are managing one of those stages you have to pin things down in much more detail than the overall PDD ever will.
Time goes from left to right in the picture on the right. This project/programme has three sub projects and 8 stages in total so will end up having 8 stage agreements.
Sub project 1 has no IT involvement. In Stage 1 of sub project 1 the business will consider how they might re-engineer the manual part of their processes and Stage 2 of sub project 1 - if approved - would implement those changes (new office layout, cross-skilling, training, etc.).
Sub project 3 is a fairly large software development project. Note that in this sub project Stages 3 and 4 will run in parallel. Stage 3 (technical design, build and unit test) done by the IT team, and in parallel with that Stage 4 (preparing for and performing system test and implementation) performed by a separate team made up of user and IT people.
In a project with two stages, the PDD and the Stage 1 agreement will be produced at roughly the same time towards the end of project definition, and there will be a degree of overlap in their contents - senior role players will be listed in both. By the time the Stage 2 agreement is produced a few months down the track, even some of the senior role players may have changed.
In small projects which only have one stage, do not produce two separate documents.
A combined PDD/stage agreement is all that is needed, the added ingredient
when compared to a PDD alone is the sign off from resource owning managers. This is a good example of
scaling the project management controls to the need of the project. Indeed, in very small projects
a couple of sides of A4 may serve as the PDD/stage agreement/project plan all rolled into one. Don't smother
those tiny ones with unnecessary bureaucracy.
Monitoring commitments
Suppose it's March and your stage agreement contains a resource commitment for June - three months away. Between now and June it may be a good idea to bump into the resource owning manager every now and again and say: "Are we still OK for Fred Smith in June...?"
And if the manager moves and is replaced, go see the new manager and get him to re-sign the stage agreement - otherwise when June comes he'll say: "Sorry, that's news to me..."
Clearly, there will need to be sanctions against those who commit resources in writing but still renege. If a manager signs to commit a resource then at the last moment refuses to supply the body for no good reason (up to that point having told the project manager the resource will be available as promised) it would be quite unreasonable for the pain to be inflicted upon the project manager - assuming he has done all the right things to secure the resource. In this case the sponsor should ensure that the reneging resource owner feels the pain via his next appraisal.
A stage agreement is in essence a summary of the stage plan and the minutes of the meetings you
had with resource owning managers. It is a tool to be used by the project manager to make it more likely
the project will succeed. Put other things in the stage agreement if that will help you.
Leave suggested things out if there is no need to including them. This is a document to help you succeed,
not a bit of bureaucracy to keep the methodology police happy.
Stage agreements help in several ways
|
|
"I know that you believe that you understand what you think I said but I am not sure you realise that what you heard is not what I meant."
Please click here to go to
Project Management Book Chapter 9
Project Management Book
Copyright M Harding Roberts 2006 2007 2008
www.hraconsulting-ltd.co.uk
Home Sitemap Contact Us Project Management Articles Project Management Book IT Project Management Course