How early strategic decisions lead to overruns, misalignment, and underperforming products
The Hidden Origin of Digital Waste
When digital projects fall short, reviews often focus on execution: missed deadlines, scope creep, technical hurdles, or low adoption.
Research points to a deeper issue. A study found that, on average, initiatives ran 45 per cent over budget and delivered 56 per cent less value than anticipated. Similarly, about 70 per cent of digital transformations fall short of their intended objectives.
It may be tempting to blame these outcomes on delivery flaws. However, the central cause often lies deeper: strategic missteps made well before development begins.
The main source of digital waste is not sloppy execution. It is locking in poor choices even before the design phase starts.
What Do We Mean by “Digital Waste”?
Digital waste is not just about failed projects. In many organisations, the most costly waste is less obvious and harder to spot.
You can see it in platforms that launch on time but are not used regularly. It happens with automation tools that fix one problem but create new ones. It shows up in AI pilots that look promising but never make a real impact. It is also found in features that keep getting added but do not improve results.
Poor software quality and unsuccessful development projects cost hundreds of billions of pounds annually. The Standish Group’s long-running research into project performance continues to highlight unclear requirements and weak early alignment as major contributors to underperformance.
What people often call “poor requirements” is usually not just a problem with documentation. It is a strategic problem. Requirements fail when teams do not fully understand user behavior, real-world limits, or what success looks like. In short, they fail when there is not enough discovery.
In essence, digital waste is any investment that fails to produce lasting, measurable business or user value, and, crucially, most of it is baked in before any interface is designed.

How Waste Becomes Locked In
To see how this happens, it helps to look at the decisions made before delivery begins.
1. The Problem Is Defined at the Surface Level
Many initiatives begin with a seemingly clear statement: staff are inefficient; onboarding conversion is low; reporting is slow; operational costs must decrease.
These statements are usually accurate but describe symptoms rather than causes.
For example, people might blame slow reporting on a bad interface. But a closer look could reveal that the real issues lie in scattered data sources, manual steps, or unclear ownership. Reducing onboarding drop-off might seem like a UX problem, but the real friction could be about trust, unclear rules, or how users see the value.
When organisations do not dig into the real workflows, decision patterns, and what drives behaviour, they end up building the whole project on only part of the truth. Once that happens, everything else, the budget, architecture, and plans, follows the same path.
2. The Solution Shape Is Assumed Too Early
Often, teams decide on a solution before checking if it is the right one. They say, “We need an app,” “We need automation,” or “We need AI,” before really exploring other options.
From a technical perspective, early solution commitment hardens architectural decisions prematurely. Integration patterns are selected, data models are shaped, security boundaries are established, and infrastructure environments are defined. Each decision reduces optionality.
If the foundational problem framing later proves incomplete, the cost of reversing architectural commitments increases exponentially. What could have been a strategic adjustment during discovery becomes a major re-platforming exercise during development.
3. Success Is Defined as Delivery, Not Impact
Another way teams get locked in is by measuring success only by output. Projects are considered successful if they launch on time, stay within scope, and stay within budget.
These measures are important, but they do not guarantee value. True digital impact is reflected in changed behaviour and improved outcomes: reduced processing time, increased adoption, fewer manual interventions, improved data accuracy or accelerated decision cycles.
If teams do not set and agree on these metrics from the start, they focus on delivering features instead of real results. Once the project is moving, it gets harder to shift focus to impact.
Why the Risk Multiplies in Regulated and Complex Environments
This lock-in occurs across many industries, but it is especially strong in healthcare, finance, and utilities, where rules, legacy systems, and compliance shape early decisions.
Healthcare
In healthcare, transformation starts with policy, funding, or compliance requirements. These legitimate drivers can overshadow reality.
Clinical settings change often. Workflows vary between day and night, emergencies, and staffing levels. We have seen digital solutions designed for a perfect process, only to find that frontline teams use informal workarounds to handle real-world changes.
If discovery does not capture how care really happens, digital products end up improving only the ideal process, not the real one. This leads to low adoption, extra work, or unofficial systems being used alongside the main solution.
Aligning policy goals and operational realities early helps reduce this risk.
Finance
In finance, regulatory scrutiny and risk management understandably dominate early conversations. However, organisations sometimes over-engineer solutions to mitigate perceived risk rather than validated risk.
We have observed projects where architecture decisions were locked in around conservative compliance assumptions that later proved more flexible in practice. The outcome was reduced agility, slower iteration and increased integration complexity.
A careful discovery phase helps teams see which rules are truly fixed and where there is room to experiment. This keeps compliance strong while allowing for innovation.
Utilities
Utility companies often work with old, complex systems. Data quality, integration needs, and infrastructure can vary widely from one system to another.
When digital front-end solutions are commissioned before these dependencies are fully mapped, teams encounter unexpected technical friction during development. Data inconsistencies surface. APIs behave unpredictably. Performance constraints become visible only under load.
Robust technical discovery, data audits and integration mapping reduce future architectural volatility. Without it, investment risk rises each sprint.

The Role of Discovery in Reducing Digital Waste
Some view discovery as prep work before the real project. In reality, it’s where teams can make the most impact.
Key takeaway: thorough discovery is crucial. It ensures the problem is real, aligns stakeholders, clarifies user needs, and uncovers constraints, helping teams make well-informed decisions.
In practice, this often means challenging initial assumptions. We have worked with organisations that believed they required a full-scale platform rebuild, only to uncover during discovery that a targeted workflow intervention would deliver greater impact at a fraction of the cost. In other cases, early investigation revealed misaligned success metrics that would have rendered the initiative technically successful but commercially ineffective.
These insights usually do not come up during delivery. They appear during careful, early exploration.
For organisations already in the middle of a project, a focused product or product audit can bring the same clarity. By looking at usage data, workflow problems, integration performance, and which features are used, teams can spot where value is lost and adjust before spending more.
Warning Signs That Waste Is Forming
Every project is different, but some signs often show that digital waste is starting to form.
If stakeholders cannot agree on what success means beyond launch, alignment is weak. If the problem has not been checked with user research and real data, assumptions may be shaping the project. If technical limits are accepted without checking, the architecture may have unnecessary restrictions.
Treat these signs as an opportunity to gain clarity, not as reasons to stop progress. Doing so can help minimise digital waste and improve long-term results.
Conclusion
Most cost overruns, misalignment, and poor digital results are not simply delivery failures. They stem from early strategic decisions that were too quickly accepted and not rigorously questioned.
The takeaway: significant decisions and commitments, both financial and political, occur before design starts. To avoid digital waste, organisations must focus their strategic efforts earlier, question assumptions, and remain flexible.
The greatest opportunity to reduce digital waste lies not in accelerating delivery, but in strengthening the thinking that precedes it.
Before approving the next roadmap or setting the architecture, ask a tough question: Are we just improving how we deliver a solution, or are we sure we have defined the right problem? Discovery and Product Audits do more than help plan effectively. They protect capital, align stakeholders, and increase the probability that what is built will genuinely move the needle. To translate these insights into action, consider scheduling a discovery workshop with key stakeholders to reassess project objectives, reviewing current metrics to identify misalignments, and conducting a thorough product audit to uncover hidden inefficiencies and opportunities.