Why Are 52% of Digital Initiatives Still Missing Their Goals?

Why faster software development doesn’t necessarily deliver better business outcomes, and how an evidence-based approach can help organizations build the right software in the first place.

Artificial intelligence is fundamentally changing how software gets developed.

Developers can generate code in seconds. AI-powered tools can accelerate debugging, automate repetitive tasks, assist with testing, and help teams prototype applications faster than ever before.

Organizations are investing heavily in these capabilities, expecting faster development cycles, lower costs, and greater productivity.

And in many cases, they’re seeing real improvements.

But there’s a troubling statistic that raises an important question about whether we’re focusing on the right things.

According to Gartner’s 2024 research, only 48% of digital initiatives meet or exceed their business outcome targets.

That means 52% fall short. Think about that.

We have more sophisticated technology, more powerful development tools, and increasingly capable AI systems.

Yet more than half of digital initiatives still aren’t achieving their intended business outcomes.

Why?

The answer isn’t necessarily that organizations lack the technology or development expertise to execute their projects.

Maybe the problem isn’t how quickly we’re building software. Maybe it’s what we’re deciding to build in the first place.

The Difference Between Building Software Successfully and Building Successful Software

There’s an important distinction between delivering a software project and delivering meaningful business value.

A software development team might complete every feature in the requirements document.

The application might launch on schedule.

The code might be clean, secure, and technically sound.

The project might even come in under budget.

By traditional development measures, that sounds like a success.

But what happens if employees don’t adopt the new application?

What if customers find the software confusing?

What if the new workflows take longer than the processes they were intended to replace?

What if the features stakeholders insisted were essential turn out to be features nobody uses?

Or what if the application simply doesn’t solve the underlying business problem?

The software was delivered successfully.

But the business objectives weren’t achieved.

This is a distinction that too many organizations fail to make.

Building software successfully isn’t the same as building successful software.

And as AI continues to accelerate development, that distinction is becoming increasingly important.

What Gartner’s Research Tells Us

In November 2024, Gartner reported that only 48% of digital initiatives met or exceeded their business outcome targets.

The findings were based on a survey involving more than 3,100 CIOs and technology executives, along with more than 1,100 executives outside of IT.

The research highlights a persistent challenge facing organizations investing in digital transformation: delivering technology doesn’t automatically translate into delivering business results.

It’s important to recognize that Gartner’s findings don’t mean 52% of software projects were canceled, technically unsuccessful, or abandoned.

Rather, those initiatives failed to meet or exceed the business outcomes they were expected to deliver.

That’s an important distinction.

A digital initiative can be completed and deployed while still falling short of its original objectives.

And there are many reasons that can happen, including organizational resistance, poor change management, unrealistic expectations, technical challenges, and changing business conditions.

But one particularly important risk is failing to sufficiently understand and validate the problems a software initiative is intended to solve.

That risk deserves more attention, especially as organizations become capable of developing software at unprecedented speeds.

AI Is Making Development Faster. But Is It Making Product Decisions Better?

AI-assisted development is producing meaningful advances in software engineering.

Developers can use AI tools to generate code, identify potential defects, create automated tests, and accelerate routine development activities.

Product teams can create functional prototypes much earlier in the development process.

Organizations can explore ideas and build applications with fewer resources than previously required.

These are significant advantages.

But faster development introduces an important question:

Are we using these capabilities to build better software, or simply to build more software faster?

AI can generate an application based on a set of requirements.

But what if those requirements are wrong?

AI can help implement a complicated workflow.

But what if the workflow itself is unnecessarily complicated?

AI can accelerate the development of a new feature.

But what if users don’t actually need that feature?

The development process may become dramatically more efficient without improving the quality of the decisions that determine what gets developed.

In fact, faster development can amplify the consequences of poor product decisions.

If an organization builds the wrong thing in six months, it has a problem.

If AI allows that same organization to build several wrong things in six months, it may have an even bigger problem.

The speed of execution has improved.

The quality of the underlying assumptions hasn’t necessarily changed.

Too Many Software Projects Begin With Assumptions Instead of Evidence

Most enterprise software projects begin with legitimate business objectives.

A company wants to improve employee productivity.

A product team wants to increase customer adoption.

An organization wants to replace outdated systems.

Leadership wants to reduce operating costs or create new revenue opportunities.

Those are reasonable goals.

The problems often begin when organizations start defining the solution.

Executives have ideas about what the application should do.

Product Managers gather feature requests from customers and internal stakeholders.

Sales teams advocate for capabilities they believe will help close deals.

Developers identify technical opportunities.

Designers begin creating interfaces.

And eventually, those ideas become requirements.

But how many of those requirements have been validated with actual users?

How much time has been spent observing how people currently perform their work?

Has anyone measured where employees lose time?

Have the most significant usability problems been identified?

Do the requested features address real user needs, or are they based on assumptions about what users want?

These questions are often overlooked because organizations are eager to begin development.

And now that AI is making development faster, the pressure to start building may become even greater.

But moving quickly in the wrong direction doesn’t get you closer to your destination.

The Hidden Cost of Building Features Nobody Uses

One of the clearest examples of the disconnect between software development and actual user needs is feature adoption.

In its 2019 Feature Adoption Report, Pendo analyzed product usage data from 615 customer subscriptions and found that approximately 80% of software features were rarely or never used.

That doesn’t mean every underused feature was unnecessary. Some features support infrequent but critical tasks, and usage frequency alone doesn’t establish business value.

Nevertheless, the finding raises an important question about how organizations prioritize software development.

Why are so many features receiving relatively little use?

In some cases, users may not know the functionality exists.

In others, the features may be difficult to find or use.

And sometimes, the features simply don’t address a meaningful user need.

Consider how software feature requests often originate.

A customer requests a particular capability.

A competitor introduces a new feature.

A salesperson believes a missing feature is preventing a deal.

An executive wants the application to do something that another product can do.

These requests may be valid.

But they’re not necessarily evidence that the proposed functionality will deliver meaningful value.

Before committing development resources, organizations should understand the problem behind the request.

What is the user trying to accomplish?

Why is the existing software preventing them from accomplishing it?

How frequently does the problem occur?

How significant is its impact?

And is the requested feature actually the best solution?

Sometimes the answer is to develop something new.

Other times, the best solution is to simplify an existing workflow, improve discoverability, automate a repetitive task, or eliminate unnecessary complexity.

The goal shouldn’t be to deliver more features. It should be to deliver more value.

Why User Research Should Come Before Development

One of the most effective ways to reduce the risk of building the wrong software is to validate assumptions before committing significant resources to development.

That begins with user research.

Not simply asking users what features they want.

Not relying exclusively on stakeholder interviews.

And not assuming that experienced employees can accurately describe every inefficiency in their existing workflows.

It means understanding how people actually work.

Observe real users performing real tasks

People often become so accustomed to inefficient software that they no longer recognize its limitations.

They memorize complicated procedures.

They develop workarounds.

They maintain spreadsheets outside the application.

They copy information between systems.

They perform unnecessary steps because that’s how they’ve always done it.

When asked what they want improved, they may request a new button, report, or feature.

But observing their behavior may reveal that the real problem is much broader.

Perhaps the entire workflow needs to be reconsidered.

Perhaps the information architecture doesn’t match how users think.

Or perhaps a task that currently requires 12 steps could be accomplished in five.

These opportunities are difficult to identify when product teams rely primarily on assumptions and feature requests.

Identify the problems that matter most

Not every usability issue deserves the same priority.

A confusing icon may cause occasional hesitation.

An inefficient workflow used hundreds of times each day may create significant operational costs.

An unclear validation message may lead to errors that require manual correction.

A poorly designed onboarding process may prevent customers from adopting the product.

User research helps organizations understand which problems have the greatest impact.

That allows product teams to prioritize improvements based on evidence rather than opinion.

And when development resources are limited, prioritization can be just as important as execution.

Prototyping and Usability Testing Can Reduce Expensive Rework

One of the advantages of modern UX design tools is that organizations don’t need to build a complete application to evaluate whether a proposed solution works.

Interactive prototypes can simulate important workflows before production code is written.

Representative users can then attempt realistic tasks while researchers observe where they succeed, hesitate, make mistakes, or become confused.

This provides an opportunity to identify problems early.

For example, usability testing might reveal that users don’t understand a proposed navigation structure.

Or that an important function is difficult to discover.

Or that a redesigned workflow requires information users don’t have available when they need it.

These findings can lead to changes before development begins.

That’s important because modifying a prototype is generally less disruptive than reworking an application after its architecture, business logic, integrations, and interfaces have been implemented.

Of course, prototyping and usability testing don’t eliminate every risk.

Some problems only emerge during implementation or real-world use.

But early validation can help organizations avoid investing heavily in solutions that users struggle to understand or that fail to address the intended problem.

The objective isn’t to slow development down with research. It’s to prevent development teams from spending time building the wrong solutions.

An Evidence-Based Approach to Software Development

At UX Team, we developed our EVIDENT™ methodology around a straightforward principle:

Important software design decisions should be informed by evidence, not simply assumptions or opinions.

EVIDENT™ combines user research, insights, UX design, prototyping, and validation to help organizations understand what should be built before significant development resources are committed.

Our approach focuses on five connected activities.

1. Research: Understand users and their work

We begin by understanding the people who will use the software, the tasks they need to accomplish, and the problems they encounter.

This may involve stakeholder interviews, user interviews, contextual observation, workflow analysis, and evaluations of existing applications.

The objective is to understand the problem before designing the solution.

2. Insights: Identify opportunities supported by evidence

Research findings are analyzed to identify patterns, usability problems, unmet needs, and opportunities for improvement.

This helps distinguish actual user problems from assumptions about what users want.

It also provides a foundation for prioritizing improvements based on their potential impact.

3. Design: Create solutions around real user needs

With a clearer understanding of the problem, we design interfaces and workflows intended to help users complete their tasks efficiently and effectively.

Design decisions are informed by research findings, usability principles, accessibility requirements, and business objectives.

4. Prototype: Make solutions testable before development

Interactive prototypes allow users and stakeholders to experience proposed workflows before the application is built.

This creates opportunities to evaluate ideas, identify misunderstandings, and refine solutions without committing to full implementation.

5. Validate: Test whether the solution actually works

Usability testing helps determine whether users can complete important tasks successfully.

We evaluate where users encounter difficulties and use those findings to improve the design.

The result is a more informed foundation for development.

Not a guarantee of success.

But a process designed to reduce uncertainty and avoid preventable mistakes.

AI and Evidence-Based UX Should Work Together

There’s an important distinction between using AI to replace UX research and using AI to support a research-driven process.

AI can be valuable throughout UX design.

It can assist with organizing research findings, identifying patterns, exploring alternative designs, accelerating prototyping, and supporting analysis.

These capabilities can make the UX process more efficient.

But AI-generated recommendations still need to be evaluated against real user behavior and the specific context of the product.

An AI system may suggest a familiar interface pattern.

That doesn’t necessarily mean the pattern is appropriate for a specialized enterprise workflow.

It may recommend a feature based on common software conventions.

That doesn’t establish whether the feature addresses a genuine business need.

It may generate a polished interface.

That doesn’t demonstrate that users can complete their tasks successfully.

AI can help accelerate the process of finding and implementing solutions. But evidence is still needed to establish whether those solutions are right.

The most promising opportunity isn’t choosing between AI and traditional UX methods.

It’s combining the efficiency of AI-assisted tools with the judgment, research, and validation required to make better product decisions.

Measure Business Outcomes, Not Just Development Output

If organizations want their digital initiatives to deliver better results, they also need to reconsider how they define success.

Traditional software project metrics often focus on delivery.

Was the application launched on time?

Did the team stay within budget?

Were the planned features completed?

How many development tasks were finished?

These measures are useful for managing a project.

But they don’t necessarily indicate whether the software delivered meaningful value.

A more complete evaluation should include measures tied to actual user and business outcomes.

User adoption

Are employees and customers using the software as intended?

Are they adopting important functionality?

Or are they continuing to rely on existing tools and workarounds?

Task completion and efficiency

Can users successfully complete the tasks the software was designed to support?

How long do those tasks take?

Have unnecessary steps been eliminated?

Error rates

Are users making fewer mistakes?

Has the software reduced the need for corrections, rework, or support?

Training and support requirements

Can new users become productive more quickly?

Are support requests declining?

Are employees less dependent on training materials and informal workarounds?

Business value

Is the software producing the operational improvements, cost reductions, revenue opportunities, or other outcomes that justified the investment?

These measures should be considered before development begins.

That way, the team can establish a baseline and evaluate whether the resulting software actually improves the experience and business performance.

After all, a project that delivers 100% of its planned features but fails to achieve its business objectives shouldn’t automatically be considered successful.

Faster Development Makes Better Product Decisions Even More Important

AI-assisted development will continue to improve.

Organizations will be able to create more sophisticated software with fewer resources and shorter development cycles.

That’s an enormous opportunity.

But it also creates the potential to accelerate mistakes.

When the cost and effort required to build software decrease, organizations may be tempted to spend less time validating whether the software should be built in the first place.

That would be a mistake.

The faster development becomes, the more important it is to establish a clear understanding of user needs, business objectives, and the problems being solved.

Because the greatest risk isn’t necessarily that developers will fail to implement the requirements.

It’s that the requirements themselves may not reflect what users and the business actually need.

And no amount of development efficiency can fully compensate for building a solution to the wrong problem.

The Bottom Line: Build the Right Software, Not Just Software Faster

Gartner’s finding that 52% of digital initiatives miss their business outcome targets should prompt organizations to reconsider how they approach software investments.

The statistic doesn’t prove that inadequate user research causes most digital initiatives to fall short.

But it highlights the importance of focusing on outcomes rather than simply delivering technology.

AI is making software development faster.

That’s a good thing.

But speed alone doesn’t guarantee usability, adoption, efficiency, or business value.

Organizations still need to understand their users.

They need to validate assumptions.

They need to identify the problems worth solving.

And they need to test whether proposed solutions actually work.

That’s where an evidence-based UX approach can make a meaningful difference.

Because the most expensive software mistake isn’t necessarily building something badly.

It’s building the wrong thing really well.