The most successful digital transformation projects don’t start with a solution

“Delivered on time and within budget” – but did it actually solve the problem?

It’s the phrase every project team wants to hear. Bugs are fixed, handover is complete, users are trained, and the closure report is signed off…success.  But six months later, spreadsheets reappear, processes are bypassed, and workarounds creep back in.   You missed something key, and your solution doesn’t actually solve the problem!   

For senior leaders, delivery metrics alone are meaningless if the outcome doesn’t deliver business value.  This happens more often than most steering committees would like to admit.   Poor adoption, eroded trust, and costly rework rarely stem from bad technology or underperforming teams. More often, they stem from a fundamental issue: the problem was never fully understood. 

Why does this happen?  Simply because solution-first thinking is easy, it’s comfortable, and it feels like progress when you skip past the problem and get onto talking about the solution. 

Why solution-first thinking persists 

The problem statement from a department, “our system is too slow,” kicks off the procurement process to replace their system with something newer, rather than examining why the system is slow, or who is affected, or when issues appear.  We frequently find that key stakeholders have already decided how to solve the problem ie: “we need ‘x’ named tool” or “we need a new portal” – and we go straight to comparing vendors, planning the architecture and setting scope. 

It’s made harder by how persuasive vendors can be.  Demos show you a lightning-fast system with a shiny new user interface and the future seems so enticing that the question of “what is the real problem?” is drowned out by “when can we go live?” 

Going a little slower, and being just a little more careful, is rarely incentivised.  From the very highest levels of executive management, under pressure to deliver, to the most junior user who wants the disruption to their day job to end, everyone wants to implement with the shortest timelines possible. 

The hidden cost of skipping problem definition 

The cost of jumping straight into the solution can be steep, but is often hidden. Sometimes the issue is picked up in time and scope creep and rework balloon the original project, but often the expense appears later.  This can be seen in subsequent projects needed to align the newly implemented system with the underlying problems that remain but is also likely to appear outside of capex.  These costs rarely sit neatly within the original business case. Instead, they surface later as increased operational spend, inefficiencies, and lost productivity. 

Beyond financial impact, failed initiatives erode confidence in the technology function’s ability to deliver strategic value.   Once lost, that trust can take years to rebuild.  Stakeholders will be less willing to use the proper process to kick off projects if they have no faith in the organisation’s ability to deliver, so even more Grey IT and process workarounds get put in place, and boards will be less willing to sign off business cases without extremely strong ROI figures that come with very high confidence levels. 

The Project Management Institute’s  ‘Pulse of the Profession’ research found that inaccurate requirements are the second leading cause of project failure, as cited by 39% of organisations. The only thing ranked higher was changing organisational priorities, which (unlike requirements) are much harder to control. 

How effective business analysis prevents solution-first failure 

When Business Analysis (BA) is done well, it works as an enabler for every part of your project.  It accelerates delivery, reduces risk, and ensures alignment between technology investment and business outcomes.  The problem is, it’s often done badly. If your BAs are producing requirements documents that nobody reads or process flow diagrams that are impossible to interpret, they’re little more than a drag on project resources, and it all becomes a tick-box exercise, performing tasks so arbitrary lines in a Gantt chart can be marked as complete. 

Well-structured discovery ensures the solution selected, and how it is implemented, directly addresses the underlying business problem.  It ensures decisions are evidence-led rather than opinion-led, protects scope with clearly defined boundaries established early on, increases stakeholder alignment, and crucially reduces the number of surprises when you get to delivery. 

In every programme, there’s value in challenging assumptions early. One of the most effective techniques is deliberately asking the “obvious” questions, because they often reveal hidden misalignment or untested beliefs – the ‘stupid questions’ that really challenge the things that everyone considers known and settled. I can’t think of a programme I’ve worked on where at least one of my ‘stupid questions’ hasn’t uncovered something that was wrong or that had some stakeholders unexpectedly disagreeing.  This obligation to ask questions goes beyond the simple, obvious stuff though, and extends through to challenging all sorts of theories and accepted wisdom. 

Even with smaller programmes, a little bit of Business Analysis can go a long way. 

What this means for business and technology leaders

If you’re investing in transformation, the critical question isn’t “what should we build?” it’s “what problem are we solving, and how do we know?” 

Taking time to properly define the problem is not a delay, it’s risk mitigation.
It’s how you avoid wasted investment, drive adoption, and deliver measurable outcomes.  There is real tension that must be managed here, where the board wants results quickly and budget windows are closing, more time on analysis can feel too waterfall, too old-school, and even a little indulgent.  It isn’t.  The later discrepancies are discovered, the more they cost to address.  The great news is that you don’t need a massive budget or a dedicated team of experts to get this right – you just need the discipline to understand the problem first. 

The most successful programmes don’t move fastest at the start, they move smartest. 

If you’re about to kick off a new programme, or need to work out why a current one is struggling, some Business Analysis expertise can make all the difference.