The silent killer in projects

The Space Between the Contracts 2021, I signed off on a data transformation project involving four vendors. Each was technically capable. Each came with credentials, references, and a delivery team that could hold a room. The contracts were tight-I spent considerable time with legal to ensure that. Milestone charts glowed amber-to-green across the programme dashboard. On paper and on screen, everything was moving. What I didn’t model was the space between them. I’ve spent twenty years in financial services-across risk, compliance, regulatory technology, and now AI infrastructure. In that time, I’ve seen projects fail for the reasons you’d expect: bad data, underqualified teams, scope creep, budget overruns. But the failure mode that has cost me and the organisations I’ve worked with the most is quieter, harder to name, and almost never appears on a risk register. It lives in the ungoverned gaps between parties who are each individually performing-and collectively, silently, coming apart. — The Situation By month four of the 2021 programme, something felt off. Not catastrophically off. Just the low-grade friction that experienced programme leads learn to read: slightly defensive status updates, meetings that ended without clear owners, a vendor delivery lead who had started cc’ing more people than necessary on emails. When I pulled the thread, this is what unravelled. Vendor A had been claiming credit in steering committee for work that Vendor B had actually delivered. Not maliciously-they genuinely believed the integration work fell within their remit. Vendor B said nothing, partly because they didn’t want to cause friction, and partly because they had problems of their own. Vendor C was six weeks behind schedule and had told no one. Not their internal team lead, not the programme manager, not me. They carried the delay quietly, hoping to recover it before anyone noticed. And Vendor D-the one I want to linger on-was waiting on a dependency that no one had formally assigned. That’s when it stopped me. Vendor D’s dependency wasn’t hidden. It wasn’t classified. It was simply sitting in the ungoverned space between two statements of work, belonging clearly to neither, assumed by everyone to be someone else’s problem. When I traced it back through the documentation, I could see exactly how it happened. Each contract had been written precisely. Each party had agreed to their scope. And in the clean borders between those scopes, this dependency had fallen, silently, into nothing. The programme wasn’t technically failing. Every individual status report looked reasonable in isolation. The programme was failing relationally-in the assumptions, the silences, and the incentive structures that made it easier for each vendor to manage their own position than to flag an inconvenient truth. I had governed each contract. I hadn’t governed the trust between them. — Three Things I Understood Afterwards **The risk register captures what vendors agreed to measure-not what is actually happening.** This sounds obvious when written down. It isn’t obvious when you’re twelve weeks into a programme and every RAG status is green. Risk registers in multi-vendor programmes are a product of negotiation. What gets tracked is what parties consented to track. What doesn’t get tracked-the informal dependency, the missed handshake, the assumption left unverified-is invisible to the register by design. The absence of a red flag isn’t the same as the absence of a problem. I’ve written about related blind spots in AI and data governance [in this piece on AI deployment challenges in banking](https://lakshvaswani.com/post-of-ai-deployment-issues-as-senior-banking-executive-in-grc-space-how-we-overcame-them-going-beyond-pocs-real-issues-and-solutions-humor-engagement-and-end-with-laksh-vaswani-so-it-will-com/). The pattern is consistent. Systems optimised to report compliance aren’t optimised to surface failure. **The greatest risk in multi-vendor transformation isn’t technical-it’s the misalignment of incentives.** Each vendor in a complex programme is optimising for their own commercial outcome. That isn’t a moral failing; it’s rational behaviour. Vendor A had every incentive to claim the integration work-it strengthened their renewal case. Vendor C had every incentive to stay quiet about the delay-admitting it early would have triggered penalty clauses. None of them had a commercial incentive to flag the problem in the white space between their scopes, because that white space wasn’t in their contract, and solving it wasn’t in their interest. The irony, which I fully appreciate, is that I spent months negotiating contracts to create accountability-and the contracts themselves created the conditions for strategic silence. Tighter legal language doesn’t solve a misalignment of incentives. It can make it worse, by giving each party more to protect. **The person with no commercial reason to flag the problem is your real early warning system.** This is what I’d tell my 2020 self. Before a multi-vendor programme begins, map the dependencies-not the technical ones in the architecture document, but the human ones. Who is relying on whom? Where does one vendor’s success depend on another’s delivery? Then ask, for each of those dependencies: who has a commercial interest in flagging a problem here, and who doesn’t? The person with no incentive to raise the flag is exactly the person you need to build a direct line to. That might be a junior integration tester. It might be a mid-level project manager on a fixed-price contract. It will almost never be a vendor account director. — What This Means for Your Organisation If you’re running a transformation programme-or sitting above one-the question to ask isn’t “are all vendors delivering against their milestones?” The question is: who in this programme has both the visibility to see a cross-vendor problem and absolutely no commercial reason to surface it? If you can’t name that person, you don’t have an early warning system. You have a reporting structure. Those aren’t the same thing, and in month eight, when the gap you missed in month three becomes impossible to ignore, the distinction will matter considerably. The same principle applies, by the way, to internal programme governance-something I touch on in a broader reflection on executive accountability [here](https://lakshvaswani.com/test-post-from-london/). The structure that makes you feel in control isn’t always the structure that tells you the truth. — The risk that kills programmes doesn’t live inside the contracts. It lives in the