Seventy percent is the most dangerous number in software delivery. It sits in the one band where a steering committee will neither stop the work nor look closely at it, because the number is high enough to justify continuing and low enough to explain why the remaining weeks feel hard. It is also, almost always, a number that cannot be checked by the people it is reported to.
A European banking group's IT services subsidiary had contracted the build of a regulated securities advice application to an offshore development supplier. The contract commenced at 2,576 person-days and ran across six sprints. Implementation was declared finished. Acceptance testing was scheduled to begin and did not. Two formal escalations had already been raised in the steering forum, one on code quality and one on data context, and a backlog had been accumulating behind both.
When the independent post-mortem review reached its verdict on the supplier relationship, it recorded the delivered application as incomplete, at a reported "seventy percent completed", error-prone and unfit for acceptance testing. The quotation marks are the review's own. It was a reported number, not a measured one, and the review was careful to keep it attributed. That detail is the whole case study.
The challenge
A percentage complete is a ratio. To mean anything it needs a denominator somebody has fixed and a numerator somebody has tested. This programme had neither.
The denominator first. The review found no evidence of the method used to arrive at the effort estimates the contract was priced on. The estimates existed, both parties had accepted them, and no document explained how the complexity of the work had been sized. One line inside that estimate is a fair sample of what the number was resting on: a system design document covering coding standards, design principles and the rationale behind the build, budgeted at 140 person-days, for which the review found no evidence it had ever been produced. If a named deliverable worth 140 person-days can be absent without moving the completion figure, the figure is not counting deliverables.
The numerator is worse. The two sides were not testing the same object. The supplier tested in silos, sprint by sprint, component by component. The client tested end to end. Both approaches are defensible in isolation and they produce incompatible definitions of done, because a component can pass every test written for it while the chain it belongs to has never been exercised once. The review recorded the silo approach as failing to account for dependencies, which is the mechanism by which a set of individually finished parts adds up to an unfinished system.
Team growth compounded it. The development team scaled from twenty to thirty in one step, and the review found the result was groups working on their own modular pieces without visibility of the whole. That is exactly the population that generates a high component-completion count and a low system-completion reality. Everybody's own square was green.
Seventy percent was a ratio with an unfixed denominator over an untested numerator, reported into a forum with no means of contradicting it.
Nothing above requires anyone to have acted in bad faith, and the review did not find bad faith. It found a reporting unit that no control in the programme could falsify.
The approach
The review did the one thing the governance cadence had never done. It read the code, and it read it twice.
The technical workstream ran an expert review with sample source analysis against a public software quality standard, then repeated the exercise on the build produced ten weeks later, at the end of a grace period granted specifically so the supplier could stabilise the application. That grace period is what the seventy percent figure actually bought: ten weeks of a full team's time, committed on the strength of a self-reported ratio, on the reasoning that thirty percent of a nearly finished thing is a manageable amount of work. It was not, and the second reading is what ended the argument rather than extending it.
The gap between the two builds is the practical lesson. Ten weeks is a long time to discover that a number was unfalsifiable. A gate that a machine re-runs would have said the same thing in an afternoon, every afternoon, from the first sprint.
Some of those gates were missing outright rather than merely unautomated. The supplier conducted neither a vulnerability assessment nor penetration testing on an application that handles investment advice, and the review said so plainly. That is not a percentage anybody has to argue about. It is a check that either ran or did not.
The outcome
The statement of work was ended and the work taken back in house before this review began. What the engagement produced is a findings pack, a set of recommendations and a phased plan. No software was repaired here, and the seventy percent figure was never independently confirmed, only quoted, qualified and shown to be unsupported by anything in the record.
The recommendation carries further than the programme it came from, because the reporting unit has not changed in the years since and the volume of code has. What should be reported is not percent-complete but evidence-complete: the count of things that have passed a check somebody else can re-run without asking the team that wrote them.
Almost all of that is now mechanical. Whether a build compiles, whether tests run in the pipeline rather than on a developer's machine, whether an end-to-end path through the advice flow completes on a shared environment, whether a security scan executed at all, whether the design document that was budgeted for exists in the repository. Each is a binary, each is dated, each is auditable, and none of them can be softened in a slide. A programme that publishes its gate list and reports which gates passed this week has told its board something true. A programme that reports seventy percent has told it nothing, at length, on a monthly cadence.
Two forces make this more urgent rather than less. Copilots are already raising the amount of code a team produces per week, and unverified output scales exactly as fast as verified output, which makes any completion figure derived from volume less informative every month. And the same discipline is now arriving from the compliance side: with political agreement reached on the European AI Act, assurance evidence for systems in regulated use will have to be producible on demand rather than asserted. Retrieval systems and early, carefully scoped autonomous experiments face the same question a build faces. Show the evaluation set. Show the lineage. Show what passed, and when.
Our Consult engagements now open by asking what a programme's completion figure is actually counting, because that answer takes an hour and it predicts most of what follows. The Platform work follows the same rule: the gate list is written before the delivery plan, and a number nobody can re-run is not permitted to appear in a status pack at all.
- 70%
- Reported completeness, quoted not measured
- 10 weeks
- Grace period bought against it
- 140
- Person-days for a design document with no evidence it existed
- None
- Vulnerability assessment or penetration testing performed by the supplier
The number was never the problem. Reporting in a unit that could not be checked, into a forum whose only remedy was more time, is what turned a difficult build into a terminated one.