A status report is a claim about a project. Deploy frequency, cycle time, rework and the shape of the remaining list are evidence about it. When the two disagree, the evidence is right. You do not need to read code to look at any of it.
The question worth answering is not "are we late", because almost every software project is late against its first estimate. The question is whether this is a hard problem being worked on steadily, or a project that has quietly stopped moving. Those look identical in a meeting and completely different in the record.
Key takeaways
- Late and stalled are different diagnoses: One needs scope cut, the other needs intervention.
- Look at artefacts, not reports: Deploys, closed items and the remaining list are produced by the work itself.
- Four weeks of history beats one conversation: Single data points are arguable, trends are not.
- A growing remaining list is the clearest warning: More than any date that moves.
Signal 1: how often anything reaches production
Ask how many times code has been deployed in the last four weeks. Any team can answer this in a minute; the number comes out of their own tooling.
There is no universal right figure, and a project still in early build may legitimately deploy rarely. What matters is the direction. A team deploying several times a week and then nothing for a month has hit something. A team that has never deployed at all, several months in, has a delivery problem that will surface as a very unpleasant surprise near the deadline.
Signal 2: how long one item takes from started to live
This is cycle time, and it is the single most useful number on a software project. Pick five items finished recently. For each, how many days between someone starting it and it being usable?
If most items take a few days, the team has broken the work into pieces it can finish, which is the main predictor of a project landing. If items routinely take three or four weeks, the work is not being broken down, and estimates on a project like that cannot be trusted in either direction.
Signal 3: whether the same areas keep coming back
Ask which parts of the system have been reworked more than once, and why. You are listening for two different stories.
"We changed the pricing logic three times because the business rules changed three times" is a scoping problem and it is usually yours to fix. "We rewrote the order module because the first version did not hold up" is a quality or a skill problem. Both are worth knowing. Repeated rework is the most common reason a project consumes budget without visibly advancing.
Signal 4: whether the remaining list is growing or shrinking
Ask for the list of remaining work, in writing, one line per item. Ask again in two weeks.
A list that shrinks is a project closing. A list that grows while work is being done is a project still discovering what it is, which is normal early and alarming late. A list that stays exactly the same length while items are ticked off means new work is arriving at the same rate it is finished, which is the definition of a project that will never end without a decision.
This is the signal that most often reveals a stalled project, because the date can hold while the list quietly doubles.
Reading the four together
| What you see | What it usually means | What to do |
|---|---|---|
| Regular deploys, short cycle time, shrinking list | On track, possibly late against a bad estimate | Cut scope to the business result |
| Regular deploys, growing list | Scope is not controlled | Freeze the list, decide what ships |
| No deploys, long cycle time | Blocked or overwhelmed, often on infrastructure | Find the blocker, consider help |
| Good reports, none of the above visible | The reports are not describing the work | Get someone technical to look |
The last row is the uncomfortable one. If the narrative is healthy and none of the four signals supports it, the gap is the finding.
What to do once you know
If the project is hard but moving, the answer is almost always to cut scope rather than add people or pressure. Decide the smallest version that delivers the business result you originally wanted, and ship that. Everything else becomes a second release, which is a much easier conversation than a missed launch.
If the project has stalled, no amount of reporting will restart it. Someone technical has to read the actual work and say what is true, which is a different exercise from a status meeting. We describe what that involves in what a technical audit covers.
Ali Boran Gazel