Project Management Book

Chapter 9 - Project Support

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:

• estimates: how were they arrived at?
• schedule: does it exist, has the team signed up to it?
• risks: have they been assessed, is there a plan to manage them?
• stage agreement: are resources committed?
• change and issue procedures: are they set up?
• reporting: are adequate tracking and reporting mechanisms in place, is it clear who will communicate what to whom?
• quality: are quality assurance activities included in the schedule?

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 - if 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:

• a project support person to lead the review
• a project manager from another project
• a team leader from another project

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

• Monday afternoon. The review team trawl through the project's written records: plan vs actual data (such as we saw in the planning chapter), change logs, risk register, etc.
• Tuesday morning. The project manager makes a full disclosure presentation of status, problems and planned actions, issues, major risks, and so on. Warts and all.
• Tuesday lunchtime. The review team go into a huddle and begin to formulate their assessment and identify further information they need.
• Tuesday afternoon. Vitally, the review team is empowered to speak to anyone they wish to: the project sponsor, the users, trainee developers, or whoever. Essentially this is fact finding.
• Wednesday morning. The review team discuss their findings and recommendations with the project manager.
• Wednesday afternoon. The review team write the health check report.

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

• The project plan. Remember, the health check review is being conducted half way through a stage. A project plan must exist - we know this because project support saw it before the stage began. But sometimes the plan looks great on paper but when you go back half way through and talk to the team members it's obvious they don't really understand what the plan is telling them to do and they're ignoring it. So the review team establish whether the plan is as good as it looked, is being followed and is being updated as the project progresses.

  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:

  • every week sit down with the team leaders and review the numbers coming out of the tracking tool: there is valuable information which is currently not being exploited.
  • revise the plan to reflect the cost overrun to date.
  • go and have a chat with the project sponsor as it looks on current trends as though the project budget will be exceeded.

  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.
  
  

• Change. Is it being controlled? And even if it is, is so much change being taken on board that project success is being jeopardised?
  
  
• Quality management. When dates start to slip what tends to get sacrificed? (No, not the project manager...) Quality. All those finely planned quality checking tasks in the plan get skipped. And quality problems go undetected until later in the project and then they cause much bigger delays.

  So the review team check that the planned quality tasks (see the quality management chapter) are being properly performed despite pressure on dates.
  
  

• Roles. Are role players stepping up to their responsibilities?
  
  
• Resources. Are promised resources being supplied?

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.

...next

Privacy Policy and Cookies