Project Health Check
An honest assessment of whether a project is actually on track, the schedule question people avoid, whether the plan reflects reality, dependency and decision latency, and the signals that predict trouble months early.
About the numbers here. Numbers here are thresholds the checklist proposes, not measurements.
Markdown. No sign-up, no email.
Run this monthly, or whenever something feels wrong and nobody can say what. It is written to surface the things a status report smooths over.
Project: _______________ Assessed by: _______________ Date: _______
1. The direct questions#
- [ ] Is the current end date one you would personally bet on? yes / no
- [ ] If no, has anyone been told? yes / no, when: _______
- [ ] Does the plan reflect what is actually happening, or what was agreed months ago?
- [ ] Would the team give the same answers as the project manager?
- [ ] Has any deadline moved in the last quarter, and was that visible?
The most common failure in project reporting is not lying. It is a series of individually reasonable "we will catch up next sprint" judgements, none of which is ever escalated, until the gap is too large to absorb.
2. Scope#
- [ ] Baseline scope is written down and findable
- [ ] Changes since baseline are recorded with their cumulative impact
- [ ] Cumulative schedule impact of approved changes: ____
- [ ] Out-of-scope list exists and has been used to decline something
- [ ] Nobody is adding work informally to individual team members
3. Progress#
- [ ] Progress measured by completed, accepted work. Not by effort spent
- [ ] "90% done" claims older than two weeks investigated
- [ ] Testing is progressing alongside build, not queued at the end
- [ ] Integration has been attempted, not deferred
- [ ] The riskiest work was done early, not left until last
The oldest item still "in progress": ____ days
Deferred integration and deferred testing are the two most reliable predictors of a late project, because both hide accumulated problems until the point where there is no time to absorb them.
4. The queues#
- [ ] Average time to get a decision: ____
- [ ] Average wait on an external dependency: ____
- [ ] Items currently blocked: ____, oldest blocked for ____ days
- [ ] Environments available when needed
- [ ] Anyone waiting on a single named person for more than one thing
Delay usually lives in queues rather than in the work. If the team is waiting a week for decisions, no amount of delivery improvement changes the outcome.
5. People#
- [ ] Team members are on this project the share of time that was planned
- [ ] Key-person dependency identified: _______________
- [ ] Someone else could continue if that person left tomorrow
- [ ] Overtime is not being used routinely to hold the date
- [ ] Turnover since start: ____
Sustained overtime is a schedule problem being paid for with quality, and it shows up two months later as defects.
6. Quality signals#
- [ ] Defect count trending down, not up, as the end approaches
- [ ] No large untested area
- [ ] Non-functional requirements have been tested, not just functional ones
- [ ] Known defects list exists, with severity agreed
- [ ] Technical debt taken deliberately, and recorded
7. Governance#
- [ ] Sponsor is engaged, attended the last two reviews
- [ ] Risks reviewed in the last fortnight, with overdue mitigations chased
- [ ] Decisions are being recorded
- [ ] Status reporting matches what the team would say
- [ ] Bad news reaches the sponsor without being softened at each level
When did we last tell the sponsor something they did not want to hear? _______
If the answer is "never", the reporting chain is filtering, and the sponsor is making decisions on a version of reality that has been improved on the way up.
Verdict#
| Confidence in the end date | high / medium / low |
| The one thing most likely to derail this | |
| What I would escalate today | |
| Action, owner, date |
A health check that produces no action is a status meeting. Leave with one thing that changes.