Project Health Check: Template, Questions and Checklist

A project health check is a short, independent review of a project that is already running, carried out by somebody outside the project team, that tests whether the project is actually in the condition it says it is in. It looks at plan, scope, resources, risk, finances, governance, and benefits, and it reaches a view based on documents and interviews rather than on the project manager's summary.

That is the last definitional paragraph on this page. The rest is how to run one: who is allowed to do it, what to ask, what evidence to demand for each answer, when to trigger an unscheduled check, how to score it without inventing a maturity model, and what has to happen to the findings before everyone forgets them.

Why health checks exist at all

Projects do not usually fail suddenly. They fail slowly, in full view, while reporting green. The reason is not dishonesty. A project manager reporting on their own project is being asked to grade their own homework in front of the person who funds it, and the rational response to that pressure is to report the plan as it should be rather than as it is. Small slips get absorbed into contingency that was never really there, and by the time the status turns red the options that would have helped are gone.

A health check breaks that loop by putting somebody in the room who has nothing to lose by saying the schedule is not credible. It is cheap relative to what it protects. Two people for three days on a project worth two million dollars is a rounding error, and it is the only routine in most delivery organizations that is designed to produce bad news early.

Who should run a project health check

The reviewer must be independent of the delivery of the project and must not report to its sponsor. That rules out the project manager, the delivery lead, and anyone whose bonus depends on the project landing. In practice the review is run by a PMO representative, a peer project manager from another part of the business, or an external reviewer, usually in a pair so that one person is asking while the other is writing.

Independence comes in tiers, and it is worth being honest about which tier you can actually staff:

Swipe to see more →

One rule protects all four tiers: the reviewer writes the findings, and nobody outside the review pair may edit them. Comment, dispute, and attach a response, yes. Edit, no. The moment findings can be softened by the people they describe, the check has become a negotiation and its output is worthless.

The evidence rule, which is the whole method

Most published health check templates are a list of questions with a five point scale next to each one. That produces a number quickly and tells you almost nothing, because the answers are opinions and opinions are exactly what the check was supposed to bypass.

Use one rule instead: every question must be paired with the artifact that answers it, and the reviewer must see the artifact. Not a description of the artifact, and not a slide summarizing it. If the artifact does not exist, is out of date, or nobody can find it inside ten minutes, that is the finding, and it is usually a more important finding than whatever the question was originally about.

Swipe to see more →

The last column is the part practitioners find most useful, because it turns a soft conversation into a specific observation. "Cost control is amber" starts an argument. "The cost report excludes 340,000 dollars of committed spend on issued purchase orders, so the reported underspend is not real" ends one.

A project health check template: the seven areas to score

Seven areas cover almost every project without turning the review into a methodology audit. Keep the structure stable across projects so results are comparable, and resist adding an eighth area for one project's special circumstances.

Swipe to see more →

Reviewers often ask why "team morale" is not an area. It is, but it is not a question you ask directly, because nobody answers it honestly to a reviewer with a clipboard. You learn it from how people talk about the plan in interviews, and it belongs in the narrative rather than in a score.

The project health check questions worth asking

Roughly twenty five questions is the working limit for a review that has to finish in days rather than weeks. These are the ones that most often change a rating, grouped by area. Each is written so it cannot be answered with yes.

• What has been delivered in the last thirty days, and how does that compare to what the plan said would be delivered?
• Show me the three milestones due next. What has to be true for each one to land?
• Which activities are on the critical path today, and were they on it last month?
• What is in progress right now that is not in the approved scope, and who asked for it?
• How many change requests are open, and what is the oldest one waiting for?
• Who are the named individuals on this project, and what percentage of their week is really available?
• Which specialist is shared with other projects, and who arbitrates when both need them in the same week?
• Which risk would you personally bet on materializing, and is it in the register?
• Which issue is currently escalated, to whom, and since when?
• What decision is the project waiting on right now?
• What does the sponsor believe the delivery date is, and does that match the plan?
• What is the forecast cost to complete, and what assumption would break it?
• How much spend is committed but not yet invoiced?
• What benefit will this deliver, who has agreed to be accountable for it, and how will it be measured?
• If you had to remove one third of the scope tomorrow, what would you cut and who would object?

The last question is the most useful one on the list. A team that answers it immediately has thought about priority. A team that cannot answer it has been treating every requirement as mandatory, which is the single most reliable predictor that the project will run late.

How to score a health check without inventing a maturity model

Score each of the seven areas red, amber, or green, and record a separate confidence level for each rating. Two dimensions are enough, and adding a fourth or fifth colour just moves the argument from the finding to the scale. The confidence level matters more than most reviewers expect, because "green, low confidence" is a genuinely different message from "green, high confidence" and it is the honest way to record an area you could not test properly in the time available.

Do not average the seven into a single percentage. A composite score of 71 percent invites the sponsor to feel reassured while the resource area is red, and a single red area is often sufficient to sink a project on its own. Report the seven, then write a one paragraph overall judgment in plain words. The paragraph is what people read.

Keep the scoring definitions written down and identical across reviews. Red means the area will prevent the project delivering unless something changes. Amber means it will cause damage that can still be contained. Green means it is genuinely fine, which reviewers use far less often than teams expect. This is the same discipline that keeps RAG status reporting meaningful, and the health check exists partly to test whether that self-reported status is being applied honestly.

When to run a health check, and the triggers that should force one

Schedule health checks no more often than quarterly for routine projects, because they consume real time from people who are not on the project. Run one at the end of planning before execution starts, which is the cheapest moment to change anything, and then at intervals that scale with size and complexity rather than on a fixed calendar for every project alike.

The scheduled checks are the easy half. The valuable half is the unscheduled one, and it only happens if the conditions that trigger it are written down in advance. Where triggering a review is a judgment call, calling for one is read as an accusation against the project manager, so people wait, and the review happens after the damage.

Swipe to see more →

Publish the trigger list alongside the rest of the delivery rules so it reads as a standing rule rather than a decision somebody took about a particular team. That framing is the difference between a health check people cooperate with and one they manage.

What has to happen to the findings

The failure mode of health checks is not bad analysis. It is a competent report that is presented once, acknowledged warmly, and filed. Six months later, when the project is in trouble, somebody rediscovers it and observes that the review said exactly this, which helps nobody.

Three rules stop that. First, findings go to the sponsor and the governance forum at the same time, not to the sponsor first for comment. Sequential distribution is how findings get softened before anyone independent sees them. Second, every finding gets one named person and a date before the meeting ends, because a finding owned by "the project team" is owned by nobody, and routing each action to a specific accountable owner rather than a group inbox is the unglamorous mechanic that decides whether any of this was worth doing. Third, the next review opens by reading out the previous review's findings and their status, which takes four minutes and does more for follow through than any amount of process design.

Findings that require a decision above the project manager's authority go to the steering committee as a decision request with options, not as a problem statement. A report that describes a difficulty without offering choices puts the work back on the busiest people in the room, and it will be deferred.

Status optimism gap: the metric that tells you if this is working

Health checks are easy to perform and hard to know the value of, because a good one produces uncomfortable conversations rather than a visible deliverable. One measure cuts through it. Track the share of projects self-reporting green that the health check downgrades to amber or red. Call it the status optimism gap.

Swipe to see more →

Those bands are operating rules to calibrate against your own history rather than industry constants, and the point of them is the direction of travel. A gap that shrinks over four quarters means reporting is improving. A gap that stays high while everyone insists reporting has improved means the reviews are the only honest signal you have, and you should be running more of them.

Health check, audit, gate review, and post implementation review

These four get used interchangeably and they are not the same activity. Confusing them is how a supportive review turns into something a team prepares defensively for, which destroys the information you were trying to collect.

Swipe to see more →

The practical difference is authority. A health check recommends and a gate review decides, which is why the two should not be run by the same people in the same session. If your stage gate review has quietly absorbed the health check, projects will arrive at gates having prepared for an exam, and you will have lost the one review that was supposed to surface problems between gates. The look back after delivery belongs to the post implementation review, and assessing the function that runs all of this belongs to a PMO assessment.

Five ways a project health check goes wrong

It is scheduled only for projects already known to be in trouble. Then the review becomes a label. Nobody volunteers, the arrival of reviewers is read as a verdict, and teams manage the review instead of using it. Run them on healthy projects too, on a published cadence, so being reviewed says nothing about you.

The reviewer accepts a briefing instead of evidence. A three hour walkthrough from the project manager is efficient and produces the same picture the status report already gave you. Ask for the artifacts before the interviews, and read them first, so the interviews can be spent on the gaps between the documents and the story.

Findings are graded on effort rather than outcome. "The team is working extremely hard" is true on almost every troubled project and belongs nowhere near a rating. Reviewers write it because the alternative feels harsh. It reliably converts a red into an amber and buys the project another quarter.

Everything gets a recommendation. A report with thirty two recommendations will produce zero. Rank them, cut to the five that would actually change the outcome, and put the rest in an appendix where they can be ignored honestly rather than dishonestly.

Nobody checks the previous findings. This is the most common one and the easiest to fix. If the last review's actions were never done, that fact outranks anything in the current review, and it should be the first line of the report rather than a footnote.

Frequently asked questions

What is a project health check?

A project health check is an independent review of a project that is already running, carried out by someone outside the project team, that tests whether the project is genuinely in the state it reports. It covers plan, scope, resources, risk, governance, cost, and benefits, and reaches its view from documents and interviews rather than from the project manager's summary.

Who should carry out a project health check?

Someone independent of delivery who does not report to the project's sponsor. In practice that is a PMO representative, a project manager from another program, or an external reviewer, usually working in a pair so one asks while the other records. The project manager may contribute evidence and dispute findings, but must not run the review or edit its conclusions.

What questions should be asked in a project health check?

Around twenty five questions across seven areas, each written so it cannot be answered yes and each paired with the artifact that proves the answer. The highest yield ones are what was delivered in the last thirty days against plan, which named person is a single point of failure, how much spend is committed but not invoiced, and what the team would cut if it had to lose a third of the scope.

How often should project health checks be done?

No more often than quarterly for routine work, since each one consumes real time from people outside the project. Run one at the end of planning before execution begins, then scale frequency with size and complexity. Separately, publish trigger conditions such as two consecutive missed milestones or a green to red status jump that force an unscheduled check regardless of the calendar.

What is the difference between a project health check and a project audit?

A health check asks whether the project is in the condition it claims and is intended to help it succeed. An audit asks whether defined rules and controls were followed and may carry consequences. Health checks recommend, audits report compliance, and the two should stay separate because teams prepare defensively for audits in a way that hides exactly what a health check needs to see.

How long does a project health check take?

Two reviewers for two to four days covers most projects: half a day reading artifacts, a day of interviews, half a day drafting, and a session to present findings. Large or troubled projects take one to two weeks. If it is running longer than that, the review has expanded into an audit and will arrive too late to change anything.

What makes a project healthy?

A healthy project has a baseline somebody signed, a plan whose remaining duration moves as time passes, named people with realistic allocations, a risk register that changed recently, decisions that get made within days rather than months, a cost forecast that includes commitments, and a business case whose benefits somebody still owns. Very few projects have all seven, and that is fine.

Can a project health check be done remotely?

Yes, and the document review half works better remotely because artifacts arrive in a shared folder rather than in a room. The interviews need more care: schedule them individually rather than as a group call, since people say considerably less about a project's real state when their delivery lead is on the line, and allow silence after a question instead of filling it.

Where this fits

The health check tests one project against evidence. The signal it validates is the self-reported RAG status that flows up through the portfolio status report, and the artifacts it demands are the ones created earlier: the project charter that set the baseline, the RAID log holding risks, assumptions, issues, and dependencies, and the change record that shows whether scope creep has been approved or absorbed. Where cost and schedule need testing together rather than separately, earned value management gives the arithmetic.

Upward, findings only matter if there is somewhere for them to land. That is the job of a project governance framework, with the project sponsor accountable for acting on what the review found, and risks that outgrow one project rolling into project portfolio risk management. At portfolio level the equivalent routine is the portfolio review meeting, which reviews the whole funded set rather than one project in depth, and the discipline all of it belongs to is project portfolio management.

Last updated August 2026.