An estimate looks like a claim about time. Under any sizing method worth defending, it is mostly a claim about the people who will do the work, and time is what falls out at the end. That inversion is the reason estimation arguments so rarely settle. Two parties think they are negotiating a schedule while the thing actually in dispute is a capability assessment neither of them has agreed to run.
A European banking group's IT services subsidiary commissioned a post-mortem review after an offshore application build was stopped short of user acceptance testing. The review covered delivery approach, project management and the technical quality of what had been handed over. It read the contract and the statement of work, interviewed both sides, and read a sample of the source code in the client's own environment, including a difference test between two builds roughly ten weeks apart. It found no meaningful improvement between them.
Two things in that report sit in different halves of it and belong on the same page. The first is what the delivery team turned out to be. The second is the sizing method the review recommended everybody adopt next time. Put them side by side and the whole engagement reads differently.
The challenge
Start with the number nobody could defend. The client's own sizing put the scope at roughly 1,000 person-days, reached, it told the review, with a method it could name. The supplier's figure was in excess of 2,500. Inside the client organisation, the recorded perception was that supplier estimates ran two to three times higher than they should. The review went looking for the method behind the supplier's number and reported that there was no evidence of one. So one side had a yardstick it could produce, the other had a total, and the two stood a factor of two and a half apart on the same written scope.
An estimate with no method behind it cannot be wrong in any useful sense, because there is no step to point at. It can only be high or low, and a disagreement about high or low is a negotiation. So it was negotiated. The contract commenced at 2,576 person-days, and the difference the two sides never closed was handed to a profit-sharing clause in the statement of work to absorb.
Now the second half of the report, which arrived after the failure rather than before it. The code review found violations across every one of the object-oriented design principles the parties had agreed the software would be built on. It found patterns such as dependency injection, inversion of control and the observer pattern present in the codebase but not fully grasped, with subscriptions left unbalanced and synchronous and asynchronous code mixed in the same place. It found circular references between modules, which the report reads as a sign that layered design had not landed with the team. It found local caching used as shared memory rather than for efficiency, producing race conditions where a reader sometimes saw old data and sometimes new. Automated test coverage across the front end and the service layer was reported at roughly 10 to 15 per cent. A design document quoted at 140 person-days in the statement of work had no evidence of ever existing.
Behind all of it the review named the shape of the team: developers new to the technology they had been asked to build in, lacking experience and depth, and short of the grounding in object-oriented fundamentals that the agreed design principles assumed. The record shows the problem was visible from the start of delivery and was formally escalated within weeks, that individual faults were raised, tracked and closed by agreement, and that fundamental errors of the same kind kept appearing anyway.
The approach
The recommendation on estimation was to adopt a defined and mutually agreed sizing method, apply it to several early releases, compare what it produced against the numbers that had been reached without it, understand the differences, and only then make it the standard. The review named function points and use case points as candidates, both public methods that predate the engagement by decades, and it noted plainly that any such method still contains elements which depend on expert judgement rather than arithmetic.
What a defined method buys is not precision. It is a place to argue. A serious sizing method starts from the software, from how much functionality there is and of what kind, and then adjusts that answer for the conditions the work will actually be done under. One of those conditions is how experienced the delivery team is. That adjustment is not a footnote on the method. It moves the number by construction: the less experienced the team, the larger the estimate has to be.
Which means the review's central finding about the delivery team was not a discovery. It was an input. It was available at the point of quoting, to whichever party bothered to ask, and it was worth days on the number. Neither side asked. They argued about the total instead, and then found out by building.
This is the part worth carrying forward, and it is not a story about one method. Any sizing approach that adjusts for who is doing the work is a capability assessment wearing a schedule's clothes. Run it honestly and the answer to "how long will this take" and the answer to "can this team do this" arrive together, in the same units, before anyone commits. Leave that dial at its default, which is what happens whenever a team fills in a spreadsheet it does not believe in, and the method produces a number that assumes a team you do not have.
The outcome
What this engagement produced is findings and recommendations. The review recommended a shared sizing method with a back-test against real releases, a joint definition of pass and fail before the next build starts, a staff intake process with competency testing rather than a paper screen, and design and coding standards agreed up front with a sample of code reviewed against them and the non-conformance extrapolated. None of that was executed inside the review. No re-estimate was produced. The application had already been assessed by both parties as incomplete and unfit for acceptance testing, and the engagement had already ended.
The uncomfortable part is how cheap the missed step was. The capability question costs a conversation. Asked at quoting time it produces a larger number and a smaller argument, or a decision not to proceed with that team, which is the outcome the project eventually reached by a longer and more expensive route.
The same trap is open right now on a different kind of work. Teams are sizing their first retrieval-augmented builds and their first internal copilots against a schedule, with the same dial at the same default. Has this team built an evaluation set before, or will it discover halfway through that it has no way to tell whether the answers improved. Has it run a vector store in production, or only in a notebook. Does the data it plans to retrieve over have lineage anyone can follow back to a source, or is data readiness the unpriced work at the front of the plan. Those questions belong in the estimate, not in the post-mortem, and the MLOps discipline already built for models is where the answers usually hide.
Our Consult engagements open on exactly that arithmetic, and the Platform work that follows exists so the answers stop being opinions. An estimate is the first place an organisation writes down what it believes about its own capability. Most write down something flattering, then spend a year finding out.