How to read project health without reading code

On-time and on-budget are the default health metrics for software projects. Both are lag indicators by the time they show red, the underlying problems have been accumulating for weeks. More importantly, they measure the project's performance against a plan, not the plan's fitness for the actual problem.

A project can be on time and on budget and still be heading toward a failed outcome if the scope was underestimated, if the architecture will not support the required scale, or if the team's velocity is being maintained by accumulating technical debt that will slow everything down in six months.

Demo quality and regularity. A team that demos every two weeks, consistently, with working software that reflects recent decisions, is functioning well. A team that defers demos, presents mockups instead of working features, or cannot answer questions about what they showed two weeks ago is exhibiting the most common early warning sign in this industry.

Defect introduction rate. Ask your project lead: of the work shipped in the last four weeks, how much required a fix or rework in the following four weeks? A rate above 20 percent indicates insufficient testing, unclear requirements, or both. This metric is almost never included in status reports unless asked for explicitly.

Velocity trend, not point-in-time velocity. A team delivering 40 story points per sprint consistently is far less concerning than a team delivering 60, then 45, then 30. Declining velocity over more than two consecutive sprints almost always indicates an accumulating technical debt problem the codebase is becoming progressively harder to change safely.

Decision log freshness. Every project accumulates decisions: architecture choices, scope trade-offs, deferred requirements. A maintained decision log is a sign of a team thinking clearly about what they are building and why. An absent or stale log signals that decisions are being made without being recorded and will need to be reconstructed later, at cost.

Blocker age. How long does the average blocker sit unresolved? Items that remain unresolved for more than three working days without escalation indicate either that the team is not communicating dependency risks, or that a client-side bottleneck has been given up on. Either requires direct attention.

Three situations warrant immediate senior attention, regardless of what the status report says. First: a scheduled demo has been deferred or cancelled for any reason other than a production incident. Second: a scope change has been agreed verbally without a written change request following within 48 hours. Third: a key team member has changed without a formal briefing on the reason and a documented transition plan.

None of these are guaranteed failure indicators. All of them represent process breakdowns that, left unaddressed, reliably lead to the kind of outcome that is expensive to recover from and difficult to explain to stakeholders.