A project can be run correctly and still ship software that does not work. That is not a paradox, and on this engagement it is not even a surprise. The governance was close to exemplary. Every expected document existed, every meeting was minuted, every concern went up the escalation route it was supposed to go up. And the application did not work.
A European retail and private banking group had outsourced the first phase of a new web application to an offshore development partner, run into quality and schedule trouble, taken the work back in house before it was finished, and then commissioned an independent review of what had happened. The review read the contract and the project record, interviewed both sides of it role against role, and sampled the code. Three of those evidence streams, gathered separately and by different people, arrived at the same sentence.
The challenge
The first stream was the code. The technical section of the review recorded that the delivery team was new to the front-end framework the application was written in, that the team was young and inexperienced, and that the absence of a consistent technical architect across the project was a clear challenge on the supplier's side. That observation repays reading slowly, because it is unusually specific about what the missing person would have done. It names two jobs, not one: guidance to the team day to day, and technical stewardship of the project's direction.
Those are different jobs. Guidance is answering the question in front of a developer this afternoon. Stewardship is deciding what should exist at all, and then judging whether what got built is the thing that should exist. An organisation can staff the first out of whoever happens to be senior that week. The second has no natural occupant, and when it goes unfilled nothing announces it.
The second stream was the client's own account. On the review's feedback sheet, in the client's column and in the client's words, the first entry reads that the architect needed to be available throughout the project and not just for the transition. The entry beneath it asks for more senior people with more experience on the assignment. The client had worked the answer out without anyone prompting: the role had been scoped as a handover function, present for the knowledge transfer at the start, and then treated as finished.
The third stream was the money. The monthly headcount invoices, obtained and read as part of the same review, record architect days in the opening stretch of the build and then nothing at all across the eight months that followed. Nobody had to interpret those invoices. Both organisations had been filing them for ten months, and the pattern only became visible when somebody read the roles down the page instead of the totals across the bottom.
Code, testimony and billing are about as independent as evidence gets inside a single engagement. They do not usually converge. Here they converged on an empty chair.
The approach
The instructive part is that the chair was empty by design rather than by accident, and the design is legible in the sourcing model.
The review set out which roles typically sit on which side of an onsite-offshore split. Account management, functional architecture, technical architecture, team leadership, testing during the testing phase and project management are onsite-heavy. Development, from senior engineer down to junior, is offshore-heavy. The review's recommendation was that under a blended rate it actually works in the client's favour to have a higher proportion of the supplier's team onsite, and it recorded plainly that this was not what happened here.
Read that against the two jobs and the shape of the failure comes clear. The commercial arrangement priced production capacity, and production capacity is what it delivered. The roles that decide what should be produced are the expensive, onsite, hard-to-fill ones, and they are the first to thin out when a rate card is the thing being optimised. Nobody decided to run the project without technical stewardship. They decided to buy development efficiently, and running without technical stewardship is what that decision means once you write it out in full.
The consequences then surface in places that look unrelated. The client believed the supplier's estimates ran high, in some accounts by two to three times what the work should have cost. The review's diagnosis of that belief is not that somebody was inflating numbers. It is that the client had no well-defined method for estimating effort, so the numbers rested on gut feel on both sides, and judgement of that kind requires exactly the expert technical knowledge the project had not staffed. A dispute about numbers was a dispute nobody in the room was equipped to settle.
The same absence shows in the testing argument. Development ran iteratively while testing was managed as though it were a staged waterfall, which the review logged as an observation of its own rather than as a complaint from either side. Reconciling those two rhythms is a technical direction decision. So is deciding whether a team new to a framework should spend four weeks learning it before starting, which the supplier itself said in hindsight should have happened. Both decisions were available. Neither was anyone's job.
The outcome
What this engagement produced is a review: findings and a set of recommendations, put to the client in draft. No role was filled by it, no code was rewritten under it, and the contract in question had already ended. Several of the review's own finding sheets were still empty scaffolding at draft stage, which is the honest state of a first draft still circulating for completion.
The finding travels further than the engagement, and it travels in the opposite direction to the one most people expect.
Writing code is getting cheaper. Copilots in the editor now produce a working first version of most of what a competent developer would have typed, and the binding constraint moves off typing speed. The tempting conclusion is that a shortage of senior technical people matters less than it did, because the juniors are amplified.
The arithmetic runs the other way. When production capacity is scarce, the cost of an unowned direction is bounded by how much wrong code a team can physically produce. When production capacity is abundant, that bound is gone. A team with no technical steward and a fast code generator can build the wrong thing at a rate that was not physically available on this project, and both of the jobs the review named get harder rather than easier. Guidance is partly automatable, since the assistant in the editor answers the afternoon's question well and cites the file it came from. Stewardship is not, because it consists of deciding what should exist and then judging whether what arrived is right, and neither of those has a retrieval answer waiting in a vector store.
The practical form this takes is unglamorous. It is a named person who owns technical direction for the life of the work rather than for the transition, and an evaluation set sharp enough to let that person judge output at the rate output now arrives. Our Consult work starts with the first of those, because a client who cannot name the person has already answered the harder question, and our Platform work builds the second.
Governance will not rescue you here, and this engagement is the proof. The client's project management was, by the review's own assessment, hard to fault: the documents were all in place, the meetings all minuted. The one thing the governance apparatus had no slot for is the one thing the project needed, and running the process better would not have produced it.