Project Management Book

"If there's a 50% chance of something going wrong then 9 times out of 10 it will."

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:

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 Check----->

Health Check----->


Project Definition 


User Functions

IT Technical

Build and


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

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 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
This book must not be copied either as is or in modified form to any website or other medium

Home   Sitemap   Contact Us   Project Management Articles   Project Management Book

Privacy Policy and Cookies