The status list said it was missing. It had shipped.
A project status list said the offline layer was not built, so two rounds of work were commissioned for it. It existed. The list was wrong six times.
You plan your software spending from a status document. Ours listed the offline layer of a mobile app as an entire module not built, and noted the app worked only with a connection. On the strength of that entry, two rounds of work were commissioned to build it.
It already existed, and it worked. The status list described a state of the world that had been true once and had not been true for some time. That is real money: two rounds of effort spent rediscovering something already there. The only reason it was not three is that somebody checked before building.
Over the life of the project the list was found materially wrong six times. That is worth reading as a mechanism rather than a run of oversights, because six times is a system behaving as designed.
What was actually going on
Almost none of the stale entries were wholly wrong. Each had a real problem underneath a description that had stopped being accurate, and that is why they survived.
Two items commissioned as unbuilt had shipped weeks earlier, and each still had a genuinely missing half. Switching modules off was enforced on the server, but the app was still told about every module, so it showed menus that refused every click. The trial period was enforced, but it blocked reading as well as writing, and compared against the wrong calendar. An entry saying the notification module was absent was wrong: the module existed and had tests. The real open item was push delivery, a field on the device record with no way for a device to register and nothing to send with it.
A list entry that is half true lasts longer than one that is wholly false, because anybody checking it finds something real and stops. The fix is not to strike the row. It is to rewrite it to describe the half that is actually open.
There were also three planning documents, stale in three different ways. The status document listed three long-resolved priorities. The plan’s summary was three rounds behind, with two waves marked not started that had both shipped. The coverage document was so out of date that completion had to be worked out again from the code itself. Nothing in any one of them said which was current.
What we changed
Before building anything from the list, every round now starts by confirming it is actually missing: search the code, call the feature, run the checks. It takes minutes, and it changed the plan for at least three rounds. One turned into an audit-and-correct round rather than a build, and produced better work, because it fixed the halves that were broken instead of rebuilding the halves that were fine.
The same care applies to “not built”. One reconciliation confirmed a list of things to be genuinely missing, among them no document-generation component, no error-tracking service, no background job system and a single language file in each app, so the remaining gaps could be trusted rather than suspected.
The three documents were reduced to one official tracker, with the others pointing at it. That tracker carries a block separating what was confirmed working today from what was last recorded as working earlier.
What it did not fix
The half-open items stayed open when this was written: push delivery, the app being shown modules it could not use, and trial handling that blocked reading.
And the simplest rule was proposed in the list itself and not adopted: closing a gap must update the list in the same change that closes it, so the two cannot be separated by anybody’s memory. Until that is done, the list can drift again.
The pattern, for anyone who pays from a status report
Before you commission work, ask the team to show that the thing is missing, not just to say so. “Not built” is a claim about the product and deserves the same evidence as “built”.
Ask which document is the official one. Ask whether “confirmed working today” is kept apart from “last recorded as working”. And when an entry is corrected, ask what part of it is still open, because that is usually where the real problem was hiding.
Where this ends up
It is also why, on an ODC engagement, the code sits in your repositories under your review rules from the first day and the documentation is written as the work happens rather than assembled at handover. A status list kept in step with the work is the only kind worth planning against.