White paper

Project health check

Discussing why and how a project health check should take place.

Two very much unconnected events caused me to think about why an organisation would want a project health check. The first was when a colleague used the Johari Window model to describe the findings of a systems and information mapping exercise. The Johari Window model was devised by two psychologists, Joseph Luft and Harrington Ingham, while researching human personality. It is a model for mapping personality awareness and uses a four box grid to show that there are aspects of our personality that we’re open about, aspects we keep to ourselves, aspects that we aren’t aware of, but others are, and aspects that are unknown to ourselves and others. My colleague applied the principles of this model to show that within an organisation there is data that is used that we may not be aware of, and opportunities for using data that nobody is aware of. It was these unknowns that piqued my interest.

The second event that got me thinking about project health checks was the offer of a medical health check from my company. Like most I’m aware that improvements could be made in my health; I’m not as fit as I used to be and I could lose some weight. Even with these misgivings I am relatively healthy. I’m rarely ill and despite an appalling family history of heart issues I’m not aware of any serious health problems with my own health. Therefore, why would I want a complete medical health check? Without getting too morbid, I know that some people would rather be ignorant of any serious health problems; especially if they can’t do anything about it. I’m not one of those people – I’d prefer to take the proverbial bull by the horns and use any information I gain in the most appropriate way.

So, how did these two unconnected events cause me to think about a project health check? As shown in the Johari Window model there is always information that is unknown by certain parties – this could be the project manager, or could be the project board, or individuals on the project board. There is the fact that there will always be information unknown by anybody. Most worryingly is when nobody knows that there is information unknown by anybody – the unknown unknowns. With a project health check, like a physical health check, you get a snap shot of what could be improved in the project; then informed decisions can be made on whether to use this information to make adjustments, or even to accept the position and carry on with a better and clearer understanding of any risks.

Why have a project health check?

As mentioned, the primary reason should be to ensure the project will be a success. There is less cost and disruption in identifying and preventing an issue than in fixing it once it occurs. A project usually expends a lot of resource, time and money that, if it fails, will incur costs (both financial and non-financial) that will pervade long after the project is completed. Common problems, particularly at the cultural level, may be uncovered by a project health check. This not only benefits the project being reviewed but also helps with the improvement of future projects and programmes.

Project health checks can be approached proactively or reactively. Neither approach is wrong, neither approach is right. It depends on the project complexity, the culture of the organisation, and the performance, or perceived performance, of the project. A project health check that is carried out proactively will agree at certain milestones or intervals when the checks will take place. The purpose of the project health check should not just be a box-ticking exercise to confirm everything is well and good. Instead, the purpose should be to find any potential issues before they actually become a problem. As no project is perfect there will be issues to be found - if none can be found the project health check has not looked hard enough. Issues found may be very minor, even pedantic, and this gives reassurance that in principle the project is healthy and on course for success. Conversely, major issues may be uncovered early that result in changes to the project that mean the project gets back on course for success. In either case reassurances are given and the project moves forward with a better awareness, and strengthened for success. There are times when a project is displaying symptoms that mean a project health check should be carried out reactively. Although easier said than done, the attitude towards and motivation for having a reactive project health check should be to identify opportunities for improvement and agree actions or a change of approach moving forward. Unlike proactive health checks, reactive health checks will usually identify areas for concern to initially investigate.

There are five broad categories in which, if there are warning signs, a reactive project health check would be warranted:

  • Business Case – for example, the objectives in the original business case are no longer being met by the project or the original objectives no longer exist.
  • Project Control – for example, the project costs are higher than the expected costs and/or deliverables are being delivered later than expected.
  • Risks and Issues – for example, risks are not visible and issues are occurring without warning.
  • Quality – for example, the quality of deliverables are consistently not to the standard expected.
  • Relationships – for example, project teams are not working well together, the sponsor commitment is low, and/or the relationship between third parties is becoming strained.

A word of warning though; because the initial focus may be on symptoms that initiated the need for the reactive health check, it should not ignore or gloss over other areas of the project. Serious, but less high-profile issues may exist that get missed if this happens. An example of this happened when I was asked to review a project that was about to start its user acceptance testing phase. The organisation was concerned about the resources that would be used to carry out the testing. They were right to be concerned for a variety of reasons; but none of the reasons were insurmountable. However, much more fundamental issues existed: even at this late stage the scope wasn’t understood. The scope had changed several times. Different people had different assumptions as to what was in scope and what wasn’t in scope. As there was no functional specification, even how this fluid scope would be met was not articulated, agreed or understood. If the focus had solely been on the concerns around resourcing, the issues relating to this would have been resolved. However, there is no way testing could take place and even if it did the expectations from the business would not have been realigned to what was now in the scope. A lot of work needed to take place from ensuring the business case was still viable to putting in place the missing elements. Without looking at the whole picture, the project, as challenging as it was, would have dramatically failed.

The process to conduct a project health check

The methodology applied follows four phases; initiate, understand, analyse and validate, and recommend.

1) Initiate
During this step the scope and approach of the health check should be agreed. This will include who and what should be included in any questionnaires, interviews, observations and desktop studies. At this stage the reasons for the health check should also be discussed and any existing concerns shared. In addition, the best way of communicating that a health check is taking place is agreed. This is particularly important when the health check is being initiated reactively.

2) Understand
This involves a data gathering exercise in two forms; subjective and objective.

Subjective Facts
Perception can be clouded based on an individual’s background and facts that are available to them, but should never be ignored; therefore it is important that subjective information is gathered. Three methods are used for this, all of which may be utilised as appropriate.

Project members and stakeholders are asked to complete a questionnaire which will ask for the individual’s opinion on areas such as the state of the project plan, resources, costs, quality. It will also ask about the workings of the project team, the sponsorship, and the business case and project objectives. Answers given are subjective, but common themes can quickly be identified if similar responses are provided by multiple parties.

Ideally good representatives from all aspects of the project are available for interview. Like the questionnaire, the purpose is to ascertain people’s thoughts on the project’s health and gain an understanding of each individual’s knowledge of their role and responsibility. Unlike the questionnaire, the interviews are not based upon a standard set of questions. Instead, as information becomes available either in previous interviews or during the interview, the interviewer may delve into areas that warrant further investigation. The interviewer’s objective should never be to trip the person up being interviewed, but to clarify facts and gain information. In my experience people being interviewed fall somewhere between two camps; those that welcome the opportunity to share their thoughts and experiences and those that need drawing out before they are willing to share their opinions. It is the responsibility of the interviewer to draw out the true perceptions felt. However, this process can be eased with good communication which should be planned during the initiate step.

It may be possible during the health check to sit in on project team meetings and/or the project steering meeting or testing sessions, in order to gain an insight into their structure. I believe these observations provide subjective information as the fact a health check is being conducted and the presence of the person carrying out the health check will usually result in a change of dynamics or even structure of the meeting. The changes can be both positive and negative, so any observations made need to take this into consideration.

Objective Facts
Desktop Study
During this step the project documentation is reviewed; this is the only objective information available. This will review project control documents such as logs of risks, issues, changes, actions, assumptions, decisions. It will also review the project plan and the tracking of costs. In addition, documentation created during the early processes of the project should be available. These will identify the business case, project objectives, and initial expectations. Minutes of meetings and progress reports are also reviewed. During this information gathering step, not only the existence of the documents is inspected, but also the accuracy of the documents against the current known position of the project, how often updates and reviews are made, where the documents are held and who has access to them.

3) Analyse and Validate
In parallel with gathering facts, validation and clarification of assumptions would take place through a comparison of responses against each other and against documentation that was available. By bringing together the facts gathered by the questionnaire responses, the interviews and the desktop study, sometimes it will reveal that perception does not agree with the facts available. Apart from documentation not being up-to-date or even in existence, the most common difference I find is between knowledge within the project steering board and the project team, where because information is compartmentalised no one group has all the facts so are working on assumptions or with miss-information.

When comparing the data collated an examination should be made of the intentions set out in the business case, whether those intentions are known and understood by the project team (including the project board), whether the intentions still hold true, and whether the business case is still relevant.

In addition, an analysis and validation of the facts held out in the following areas is important to give a true picture of the current state of the project:

  • Governance (also, whether the responsibilities are known by the individuals in their respective roles)
  • Planning
  • Risk and Issues Management
  • Project Status Reporting (to the project board, within the project team and externally)
  • Project Costs (costs to date and forecasted costs to the end of the project)
  • Change Management

4) Recommend
When it comes to recommendations based on the data gathering and analysis there is responsibility on both the person carrying out the project health check and on the project board responsible for the project.

The person carrying out the health check has a responsibility to be open and factual with their findings. Sometimes, in order to curry favour with the person who holds the purse strings, some may hold back if there are issues at the project board level; remembering you are being paid to do a complete and full job will help set aside these reservations. It is usually very easy to make obvious recommendations and for a project that is mostly on track, apart from some very minor observations, these obvious recommendations may be all that is required. However, if a project is on course to become a ‘shipwreck’, then the recommendations should steer the project away from disaster and towards success. Personally, I like to link any observations with recommendations so it is easy to see the reasoning behind the recommendations and is possible to measure the benefits to the project once these recommendations are implemented.

The project board has a responsibility to consider the outcomes of the project health check openly and honestly. Hopefully the outcome may be giving only minor recommendations as the project is on track for success. However, this may not always be the case; even companies that are experienced at delivering projects for their clients may struggle when it comes to internal projects. As illogical as this may seem, by having an honest look at your organisation very often this fact is recognised, and the unknowns become known. This is when the difficult facts need to be addressed. Albert Einstein is attributed by some as defining insanity as “doing the same thing over and over again and expecting different results”. The project health check may reveal underlying issues in one project that can be found in others because the same thing is repeated within an organisation. Change is difficult, but once identified it is needed, the brave organisation will make those changes and see the results.


Just like my physical health check, a project health check will ALWAYS find issues; some minor, but maybe serious ones too. There is no project that is perfect. There is no project manager that is perfect. There is no perfect project team – it is made up of fallible individuals from all levels, from the technical delivery level (for an IT project) to the project board. There is no perfect project sponsor. Therefore, caution and proper expectations need to be provided prior to undertaking a project health check. The primary reason for carrying out a project health check should be to ensure the project is a success. If this means a project health check meets political objectives that have nothing to do with the business case or project objectives then the premise for carrying out the health check is precarious. Conversely, if nobody is willing to apply the lessons learnt from the health check then the cost and disruption of the project health check will be counteractive to the project’s success.

A project, unlike business as usual activities, is a unique endeavour. It is undertaken to achieve planned objectives and has a clear start and finish. A project has a business case, which if its objectives are achieved will bring benefits to the organisation. Organisations that succeed are organisations that are successful at delivering projects.

Knowledge about how well a project is performing can give much needed insight, not only on how well a project is performing, but also on how an organisation operates – both from a process point of view and how individuals in a team interact. This insight not only helps deliver projects successfully, but can also strengthen an organisation overall to thrive amidst challenging and even volatile market conditions.

Webinar | De-risking software development practices

19 November 2020

We use cookies to ensure that we give you the best experience on our website. If you continue without changing your settings, we'll assume that you are happy to receive all cookies. However, you can change your cookie settings at any time. For further information about how we use cookies and how to change your settings, please read our Cookie Notice

I'm fine with this