The concept of a “project health check” is well known, and yet not widely applied. Which is strange, because in my experience it is one of the most powerful techniques for project assurance. Perhaps would-be practitioners don’t understand how to go about it? Or could it be seen as too much of an overhead? Maybe there is confusion between a health check and an audit – resulting in fear?
In this blog post, I will describe a simple and effective health check method; one that I have applied successfully dozens if not hundreds of times.
Performing a Health Check
The basic format is this. The reviewers sit down with the project manager for a 2-3 hour meeting, and hold a structured conversation regarding the project. During the course of the conversation, the most relevant issues facing the project are discussed in detail, and brief findings and recommendations are written down.
Reviewers should be experienced project professionals, of a level likely to inspire trust from the project manager. Although I have conducted health checks on my own, my preference is to have two reviewers – as an additional point-of-view is always useful. With a team of two, it is possible to have one of the reviewers from a completely different part of the business; for example a technical project manager reviewing a commercial project (or vice-versa) makes for an interesting conversation.
Any length of conversation can be useful, but experience shows that it takes a 2-3 hour duration to really drill into issues in sufficient depth to make meaningful progress. I try to insist on reserving a 3-hour timeslot, so that the discussion can take as long as needed without pressure to hurry up.
An important aspect is that of trust. The project manager needs to be open and honest. They need to share their concerns, and take full part in discussing alternatives. They need to understand that the reviewers are not looking to find fault, they are not “scoring points”, and their motivation is to ensure project success. Also, the project manager’s authority over the project is not in any doubt: whilst the reviewers can offer suggestions and advice, it is for the project manager to decide how to proceed.
The doctor/patient analogy is useful here: a doctor’s advice is best formulated based on a patient’s honest description of symptoms, and ultimately it is for the patient to decide whether or not to take the medicine. The best doctors often have excellent empathic skills, and they are more likely to ask “how are we feeling today?” than “what’s wrong with you?” Similarly project reviewers need to develop their bedside manner, by making it obvious that they have a shared objective with the project manager of ensuring project success.
I am often asked by project managers what they need to prepare in advance. The answer is: “nothing at all.” The project manager should bring with them whatever project management artefacts actually exist: the project charter, project plan, risk register and status reports. In practice, that means all they need to bring is their lap-top! It should not be necessary to create content specifically for the health check.
As a reviewer, the only thing I like to do by way of preparation is read the most recent project status report. That way I get a stakeholder perspective on the project, and an idea of topics to explore in more detail. It is a useful indicator to see whether the impression I have gained is consistent with what the project manager has to say. If not, then it points to a communications issue.
So what is the most effective structure for performing the health check? Regular readers already know the answer to this one: The Seven Essentials provides an excellent agenda for the meeting.
The Seven Essentials Health Check
|Benefits||Why does the project exist?
What benefits does it deliver?
Is the project on track to deliver the benefits?
|Scope and Quality||Is the Scope defined?
Is it documented?
Is it signed off?
Do you have agreed Project Success Criteria?
Do you have acceptance criteria against scope items?
Is the project on track to deliver against its scope and success criteria?
|Stakeholders and Communications||Do you have a clear (and empowered) project owner?
Is the project governance in place?
Are you getting what you need from your stakeholders?
Is the project communications (e.g. status reports) in place and effective?
|Plan||Do you have a project plan that delivers the expected scope?
Does the plan identify all relevant dependencies?
Is there sufficient contingency against risky items?
Is the team working to the plan?
Is the plan on track to succeed?
|Team||Do you have the resources you need (quantity and quality)?
Are they a high-performing team?
|Suppliers||Do you have the necessary suppliers (internal and external) lined up?
Do you have contracts in place (where needed)?
Are the suppliers performing to expectations?
|Risks||What are the main risks to the project?
Are the appropriate mitigation actions in place?
At the conclusion of the health check, it falls to the reviewers to write up some brief notes, containing:
- A “RAG” status against the Seven Essentials
- Actions to be taken, normally by the Project Manager (but could also be by the reviewers and/or the Programme Office)
I always send my notes to the PM to gain their agreement and buy-in to the recommendations, because if they are not in agreement then the actions simply aren’t going to happen!
It is important to distinguish between the RAG of the health check and that of the project itself. The health check primarily assesses whether appropriate project management practices are being applied. So it is possible, for example, for a health check to show “green” for risk management – showing that risks are being properly managed – and yet the project status report is at “amber” or “red” due to the level of risk.
What if an audit is needed?
It is both a strength and a weakness of the health check method that it relies on the goodwill of the project manager. In my experience, in over 95% of cases the project manager cooperates fully, and the health check adds value and helps them to deliver their project (and yes, I have conducted surveys of project managers that supports my view).
However, there are occasions when it does not go so well, such as:
- for whatever reason, the project manager tries to conceal the truth
- the project manager simply isn’t up to the job – perhaps due to lack of experience or expertise
- a vendor is running into contractual difficulty, and is protecting their position.
So occasionally, it may be appropriate to invoke a more formal audit. I still tend to follow the same Seven Essentials structure, but the differences are:
- No statement is taken at face-value. Everything should be evidence-based.
- Although “open and friendly” is still the best approach, the reviewer is in of a position of authority over the project and it is likely to become more confrontational (“Speak softly, and carry a big stick”, as Theodore Roosevelt puts it).
- The level of detail takes more time. 2-3 days instead of 2-3 hours. Multiple meetings, involving different parties, may be required.
- The discussion involves wider members of the project team – not just the project manager – including senior stakeholders. Statements of fact can be cross-checked between the parties.
- Findings and recommendations are formal, and should not be challenged by the project team.
If an audit of this kind is needed, it will have been triggered by significant problems. So it is likely to lead to fundamental changes in the project, including changes of scope, timescales, suppliers and personnel.