One hundred and forty person-days is not a rounding error. Against a contract that commenced at 2,576 person-days it is about one part in eighteen, roughly seven months of one person's working time, priced and agreed for a single deliverable: a system design document setting out coding standards, design principles, and the reasoning behind how the software would be built. A European banking group IT services subsidiary commissioned an independent review after the build failed and the statement of work was terminated. The review looked for that document and found no evidence it existed. It also found no dispute over payments.
Both of those findings matter, and the second is the one worth sitting with. An unproduced deliverable nobody chased is a deliverable nobody was waiting on. The waste here is not documentation. Documentation is how a build stays comprehensible to whoever inherits it. The waste is documentation no decision depended on, because a deliverable no decision depends on can go missing for an entire engagement without anyone noticing.
The challenge
Read the technical findings and the missing document stops being an administrative gap. What the review found in the delivered codebase was a list of design decisions that had been taken silently and never written anywhere.
Classes carrying too many unrelated concerns, against a design standard the contract had explicitly committed the supplier to. Dependencies left implicit and resolved automatically rather than stated. Synchronous and asynchronous code mixed in one place. Subscriptions opened without matching teardown. The framework's own source modified in place instead of extended through the mechanism it provides for exactly that. A client-side cache used not for efficiency but as shared memory across the application, written asynchronously with no signal to the reader that the data had arrived, so the order of reads and writes came out random. Static variables on the server holding session state, which means one user's session could reach another user's data. Defensive conditionals wrapped around statements to stop exceptions surfacing, so failures stopped being visible and started being deferred.
Every one of those is a decision. Not an accident, a decision, taken by somebody, for some reason. The system design document was where those reasons would have been written down and argued with before the code existed. It was scoped. It was priced. It was not produced. The effects showed up one by one in a defect register instead, months later, as symptoms rather than as choices.
The same absence shows up at the other end of the contract. The review looked for the method behind the effort estimates and found none recorded. The client had reached roughly 1,000 person-days using a method it could name; the supplier's figure exceeded 2,500 with no method recorded behind it; the contract commenced at 2,576. The two most consequential documents in the engagement, the design rationale and the estimate rationale, are the two the record cannot produce.
Meanwhile the paperwork that did exist was plentiful and on time. Status reporting ran, a risk register existed, steering met twice a month, and the project was controlled by an experienced client project manager. Code quality was flagged early and escalated formally in the steering board. None of that machinery asked whether the design deliverable had arrived, because none of it had a decision waiting on the answer.
The approach
The review did what the governance cycle never had. It read the code, then read it again. A technical review of the build that stood at the start of the grace period was followed by a difference test against the build produced at its end, roughly ten weeks later. No improvement in quality or stability sufficient to allow user acceptance testing had appeared.
Ten weeks, and the difference test could not locate the improvement. That result promotes the missing document from a contract irregularity to a cause. To improve something you need a standard, and none was in force. Automated test coverage across the two stacks sat at roughly ten to fifteen per cent, so the tests were not it. The design document did not exist, so it was not it either. What remained was individual judgement, applied by a delivery team scaled up mid-build, and individual judgement does not converge on its own.
One thing did change permanently, and it is the most useful sentence in the pack. Circular references between modules were found in the codebase. They were fixed, and a module loader was introduced so that a circular reference now raises an error instead of an unpredictable load order. That is the only design principle in the engagement that stopped being negotiable. Nobody had to read it, remember it or agree with it. Breaking it stopped the code from loading.
That is close to what the review itself recommended: agree design and coding standards before the work starts, specify the pattern guidelines explicitly, put automated tooling in place to check compliance, run peer review as a discipline rather than a courtesy, and define jointly and upfront what pass and fail mean and what a status colour is allowed to rest on. Those were recommendations with a phased plan behind them, measured in weeks and months. They were not results. The application had already been terminated and taken back in house by the time any of them could be acted on.
The modern version of that hundred and forty person-days is not zero. It is the same content, delivered somewhere a decision touches it. Coding standards become checks that run on every commit. Design decisions become short records committed alongside the change that implements them, so the reason and the code age together. Coverage, defect density and build health become numbers the pipeline emits rather than numbers a supplier asserts in a slide. Lineage runs from a requirement through to the commit that satisfied it, which makes a difference test between two builds a routine measurement instead of a forensic exercise. The Platform work we do starts at exactly that point, because a delivery estimate that cannot be checked against delivery evidence is a negotiating position, not a plan.
There is a temptation, in the current wave of cautious pilots, to point a language model at a codebase and have it write the missing document. That produces the document. It does not produce the decision. The bottleneck here was never authorship, and generating unread pages faster is no improvement on paying for unread pages slowly.
The outcome
The engagement produced a findings pack, a set of recommendations and a phased plan for acting on them. It did not repair an application, and by the time it reported, the work had already moved in house.
The build's own commercial record is the uncomfortable part. It came to approximately EUR 551K in total after the penalty clause was applied, with no dispute over payments or credits and no overflow beyond the contracted amount. Nothing went wrong with the invoicing. Every control that reports in currency behaved as designed. What went wrong sat upstream of all of it, in what was being bought.
So the test to apply to any deliverable is not whether it is defined, priced or scheduled. All three were true of the design document here. The test is: which decision does this let someone make, who is on the hook for making it, and what happens to the work if it never arrives. If the honest answer to the last question is nothing, the line item is decoration, paid for because a template listed it. If the answer is that the build cannot proceed safely without it, buy the enforcement rather than the artefact, because the artefact is produced once and read never, while the enforcement runs on every change.
Our Consult engagements open by walking a contract's deliverable list and asking that of every line. It is usually the shortest conversation in the assessment and the one that changes the most.