"If there's a 50% chance of something going wrong then 9 times out of 10 it will."
Why do projects fail? Usually because they weren't planned properly, risks weren't managed, roles were unclear, etc. In other words inadequate project management tends to be the underlying cause rather than technical failure.
The aim of project support is to help projects start out with things adequately planned and to provide
advice during project execution. In this chapter we will consider what project support do at the start of, during,
and at the end of project stages. We will also look at things they may do at any time.
At the start of a stage
Unless a project is very small we would recommend a rule that the project plan must be reviewed by project support before the sponsor is asked to make the go no go decision. It takes a couple of hours to go through:
The aim is not to catch the project manager out, it is to help him ensure that the project is, in the broadest sense, properly planned and therefore more likely to succeed. This is not a box ticking exercise: have you got a document called a Risk Management Plan? Yes? Tick in the box. Next.
This is much more: talk me through how you're going to manage risks. "Yes, that sounds good and would it also help to assign each risk to someone to look after...?" This comes down to consulting an expert who can add value. It is not the methodology Thought Police checking bureaucratic compliance.
If the project manager has got the project adequately planned the review won't take long. If the project manager is inexperienced the review may add a lot of value. But the fact that everyone running any significant project must go through the review means fewer projects start with half-baked plans. And common sense would, one hopes, make it occur to less experienced project managers to invite project support to advise them while they are doing the planning so there are no surprises at the mandatory plan review.
So, in the round, project support help project managers start each project stage with better plans than might
otherwise have been the case. A project support review does not mean the plan is perfect and guaranteed to succeed
- it only that were possible!
During a stage
We will describe two types of independent reviews of projects: health checks and informal reviews.
|
|
|
Health checks - which projects and when
The Board or project sponsors decide which are their most significant projects and designate these as key projects. These will tend to be the large, business-critical or high risk projects.
The rule then is that any project designated as a key project must plan in at least one health check. For a software project, half way through the UFD step is a good time to do a health check: there's enough track record from which to draw conclusions and, one hopes, enough time to rectify any shortcomings. Long projects may have a second health check planned in, perhaps half way through the build stage.
Note that the health check is planned in - this is not a surprise dawn raid by the secret police.
We shall see that the health check aims to offer advice to the project manager and also provide the sponsor
with independent verification of project status. It will also become clear that health checks only really work
if project managers see them as adding value and therefore do not hide things from the health check review team.
Health checks - who does them
Our favoured approach is that the health check team consists of 3 people:
There are (at least) two other ways of building review teams each with pros and cons:
1) 3 people from project support and/or internal audit or similar groups conduct the review. The pros might be that they get very good at doing reviews but they are open to the criticism: "what do they know about the realities of running projects, stuck up there in their ivory tower?"
2) 3 project managers or project leaders from other projects. The pros are that they should be able to offer good, pragmatic advice given that they are also running projects in the real world, but the old pals act may mean problems don't get into the health check report and senior managers are none the wiser.
The mixed team approach ensures consistency and rigour - that the process is followed and problems are reported - and that some real world pragmatism is injected.
A week or so before the health check, the project support person who will lead the review meets with the
project manager to discuss possible areas of project weakness. It is then the job of the project support person
to choose review team members who can add most value in those perceived areas where improvement is most needed.
So, if the change control process seems to be causing problems project support seek out someone with expertise
in that area who is best placed to offer good advice.
Health checks - typical schedule
For very large projects, and those scattered across many sites, it may take longer than this, but the schedule
above gives an idea of how long it might normally take. Bear in mind two things: health checks are only done
on larger projects and the work entailed in being reviewed is in the project plan.
Health checks - what is checked
Imagine this. On the Monday afternoon the written records reveal that the stage is half way through and tasks completed so far have all, on average, cost 25% more than expected.
On Tuesday morning you ask the project manager: "what are you doing about this overrun of 25% on task costs to date?" And the project manager replies: "Oh, that's interesting, I didn't know about that...". What might you write in the report? (And keep it clean!)
The temptation is to say: 'The project manager is not managing the project' or 'the project is out of control' or something like that. Both may be true, but never write anything like that in the report. If you say the project manager is not controlling the project he may say that he is, but in a different way. The point is: keep the findings factual and unarguable. So you might say: 'the project manager did not know that completed tasks were on average 25% over budget.' That is a fact which, one hopes, the project manager will not dispute.
What recommendations would you make to the project manager? Perhaps:
A health check report might contain a dozen or so findings - each a sentence or two long - and a bulleted list of
recommendations for each. So the report is not a huge document and may even be in the form of presentation charts.
So the review team check that the planned quality tasks (see the quality management chapter) are being properly
performed despite pressure on dates.
And you may be thinking of a dozen other things you would want to look at if you were conducting the health check review.
One thing health check reviews do not do is to examine work products (such as the requirements document) to
try and assess their correctness and completeness: the health check review team neither have the time nor the expertise
to do that. What they do examine is whether those who were planned to check these products for correctness
have actually done so.
Project Management Book
Copyright M Harding Roberts 2006 2007
www.hraconsulting-ltd.co.uk