Every expensive project reset I've encountered in capital markets has the same root cause. Not technical failure. Not budget overruns in the build phase. Not delivery team turnover.
The root cause is always a version of the same thing: someone started building before they understood where the problem actually lived.
The brief was based on assumptions. The assumptions were reasonable, built from experience, informed by conversations with stakeholders, grounded in a genuine understanding of the market. They were also wrong, or incomplete, or addressed to a version of the problem that turned out not to be the most significant one.
The build proceeded. The system delivered what was specified. And when it was deployed, the people who were supposed to use it found that it solved the problem they'd described but not quite the problem they had. The friction moved rather than disappeared. The workarounds adapted rather than went away.
This is not an unusual outcome. It's the default outcome when diagnosis is underfunded relative to delivery.
What skipping diagnosis actually costs
The costs of inadequate diagnosis are distributed across an engagement in a way that makes them hard to see in real time.
The most obvious cost is the reset, the moment when it becomes clear that the build has solved the wrong problem and needs to be substantially reworked or replaced. In large programmes, this can represent months of effort and significant budget. It also tends to arrive at the worst possible moment: late in the delivery cycle, when sunk cost dynamics are at their most powerful and the appetite for honest reassessment is at its lowest.
Less visible is the cost of building to wrong assumptions throughout the programme. Every architectural decision made against an incomplete diagnosis is a decision that may need to be undone. Every integration built to connect systems in a way that turns out not to reflect how the workflow actually runs will need to be rebuilt.
There's also a subtler cost that's rarely quantified: organisational credibility. A technology programme that doesn't deliver what was needed is expensive in political terms as well as financial ones. The next programme to address the same problem will face more scepticism, more resistance, and a harder time securing the budget and buy-in it needs to succeed. Organisations that cycle through failed transformation programmes progressively deplete the organisational will required to change.
Why diagnosis gets compressed
Given what inadequate diagnosis costs, it seems irrational to underinvest in it. But the decision to compress it is almost always made for rational reasons in the moment.
Time pressure is the most common driver. The problem has been visible for a while. The decision to act has taken time to reach. By the time the programme is commissioned, there's an urgency to demonstrate progress. An extended discovery phase feels like delay.
Budget allocation is another driver. Discovery doesn't feel like it produces tangible outputs proportionate to its cost. A four-week discovery phase that produces a workflow map and a friction analysis doesn't feel like it's worth the same investment as four weeks of build work. The comparison is misleading where the discovery phase determines the value of everything that follows, but it feels real.
And there's a confidence problem. Commissioning executives often believe they already understand the problem well enough to begin designing the solution. They've been living with the issue. They've discussed it with their teams. They believe the diagnosis is substantially done.
This belief is almost always overconfident. The difference between understanding a problem conceptually and understanding it with the precision required to build a reliable solution is significant.
The discipline of investing in diagnosis
Treating diagnosis as a genuine investment, rather than overhead to minimise, requires a different mindset about what constitutes progress.
Progress in a technology engagement isn't measured by lines of code written or features deployed. It's measured by the probability that what gets built will solve the actual problem. A rigorously conducted discovery phase that takes twice as long as expected but produces a precise, evidence-based understanding of where the friction lives is more valuable than a rapid discovery phase that produces assumptions.
This also changes what you're looking for in a delivery partner. A delivery partner that is eager to start building quickly, that treats discovery as a formality, that produces a set of requirements in a matter of weeks and moves swiftly to architecture, that is a firm optimising for delivery speed at the cost of diagnostic accuracy. The programmes they run tend to produce the resets and rewrites that the industry has come to accept as normal.
They don't have to be normal.
The offer worth taking
The most efficient entry point into a change programme in capital markets is not an ambitious scope document. It's a precise diagnosis of where the actual friction lives.
Get that right, and the business case writes itself. The priorities become clear. The architecture follows naturally. The build proceeds against evidence rather than assumption.
Get it wrong, and everything that follows is guesswork dressed up as delivery. The system works. The problem doesn't go away. And in eighteen months, someone is commissioning the next programme.
Invest in the diagnosis. The rest becomes executable.