Why Digital Transformation Projects Fail

Too often, the answer comes too late, isn't given the importance it deserves, or gets assigned to someone without the capabilities needed to manage it.

I've accompanied organizations through transformation processes where the technology was well chosen, the project had good professionals, and there was a significant budget — on paper, everything seemed to be in order, and yet something wasn't working.

Over the years I've learned that transformation projects rarely fail for a single reason. They fail when an organization starts transforming part of the business without having sufficiently understood what it's trying to transform, why it needs to do it, and how it will affect the people who make that business run every day.

That's why, before talking about technology, I prefer to talk about three things: people, processes, and technology — in that order.

The first mistake: starting with technology

It's a conversation that repeats itself constantly:

“We need a new ERP,” “We have to implement a CRM,” “We should add AI,” “We need to automate this process.”

But a transformation shouldn't start with the solution — it should start with another question: what do we need to transform, and why?

When that question isn't sufficiently clear, technology ends up becoming the project instead of the enabler of the project. We then start measuring success by a tool's implementation, by meeting a schedule, or by the number of features delivered.

But an organization doesn't transform because a technology was implemented. It transforms when that technology manages to sustainably change the way people work, make decisions, and generate value.

The second mistake: not building the business case

A transformation requires investment, but the investment is not the business case.

Before starting, we should be able to clearly answer what problem we want to solve, what opportunity we want to seize, what value we expect to generate, and how we'll know we actually achieved it.

This seems obvious, but it isn't always.

When the business case isn't sufficiently structured, the project can move forward for months and end up being evaluated by its deliverables instead of by the value it was meant to produce.

It was implemented, delivered, the teams were trained, and it went into production — but did it actually transform the business?

The third mistake: looking at the project instead of the value chain

One of the most frequent risks is analyzing transformation as a set of isolated processes, but organizations don't work that way.

A change in sales can affect operations; in purchasing, it can alter inventories; in production, it can impact finance; a new data policy can change the way different areas make decisions.

That's why transforming a process means understanding its relationships with the other processes and, ultimately, with the value chain.

The question shouldn't be:

Which process are we going to change?

We should also be asking:

What else changes in the organization when this process changes?

That's where transformation really begins.

The fourth mistake: leaving change management for the end

This is probably one of the mistakes I've seen repeated the most — change management can't show up at the end of the project, once the decision has already been made, the solution has been selected, and the organization is about to receive a new way of working.

By then, many people have already built their own interpretations of what's happening. When people don't understand the change, fear, resistance, indifference, or simply fatigue show up.

For me, change management begins much earlier.

It begins when people understand why they need to change, what the impact of doing it well will be, and also what the impact of doing it poorly could be.

A few years ago, during an ERP implementation at a mining-industry organization, we went through a situation that left me with a lesson I still carry.

A person with a very important role inside the organization was fully involved in the project, and their intention was positive: they wanted to make sure every area of the business was correctly defined.

But little by little, that involvement started producing an unintended effect.

The people responsible for the different areas started losing interest and commitment. If a single person was defining much of what belonged to their areas, they started feeling that their own participation was no longer as necessary.

The problem wasn't the technology, nor that person's intentions — it was the human dynamic that had built up around the project.

We stepped in.

We talked with that person, reinforced their role, explained the impact the situation was having, and worked again with the other leaders — we created additional spaces to reinforce the importance of their participation and make the impact of their work on the final outcome visible.

The response changed, and so did the commitment.

That experience confirmed something I consider fundamental: involving people doesn't just mean having them inside the project — it means making them part of the transformation.

The fifth mistake: believing that communicating is the same as informing

There's an enormous difference between communicating a change and announcing it.

“We're going to implement a new system.” That's information.

“We're going to change the way we work because we need to solve this problem, and this will be the impact for you.” That's starting to be communication.

The organization needs to understand what's happening, but it also needs to understand why it's happening — it needs spaces to ask, question, contribute, and understand its own role.

That's why I believe communication has to accompany the entire transformation, not just its milestones — and in that process, the organization's leaders, especially its C-level, carry a responsibility they cannot delegate.

The sixth mistake: selecting a solution without understanding the context

A good technology is not necessarily a good decision.

The right solution depends on the business, its strategy, its processes, its organizational capacity, its data, its architecture, its constraints, and of course, the people who will have to use it and make it sustainable.

I've learned that selecting a solution isn't about comparing features.

It's about understanding what the organization actually needs and which alternative can best accompany it on the path it wants to take.

The question isn't:

What's the best technology?

The question is:

What's the best decision for this organization?

They aren't the same question.

The seventh mistake: thinking transformation ends when the project ends

A project has a start date and an end date. Transformation doesn't necessarily.

When implementation ends, an even more important stage begins: adoption, optimization, and continuous improvement.

A truly transformed organization doesn't go back to its old ways of doing things the moment the project's support team leaves.

Learn – Adjust – Measure – Improve, and above all, progressively lose the fear of change.

That, to me, is one of the most important indicators of a successful transformation.

When an organization starts embracing change as a natural part of its culture and enters a dynamic of responsible, purpose-driven innovation, something far deeper has happened than a simple technology rollout.

The organization has changed the way it relates to the future.

So, what should a CEO do?

The CEO doesn't need to become an expert in every technology. Their responsibility lies elsewhere: understanding the transformation, accompanying it, communicating it, inspiring it, and sustaining it.

They must understand its impact on the business, be willing to stand behind difficult decisions, and recognize the effort of the people who make the change possible.

Above all, they must lead by example.

Because it's hard to ask an organization to embrace change when its own leadership is still trying to protect itself from it.

The CEO must be a sponsor, but also a permanent communicator and inspirer — they must lead the cultural change and remember that transformation doesn't belong to the technology area; it's a matter for the whole organization's business, and it belongs to the entire organization.

Technology is important, but it isn't where it begins.

After many years, I'm more convinced than ever that digital transformation doesn't begin when a technology is selected — it begins much earlier:

It begins when the organization decides to look at its reality honestly.

When it understands what it needs to improve.

When it understands the impact on its customers, suppliers, and surrounding environments — not only inside the organization.

When it identifies how that improvement impacts its value chain.

When it builds a business case that allows for a conscious decision.

When it listens to the people who will have to make the change possible.

And when it understands that transforming doesn't just mean implementing something new.

It means learning to work, decide, and evolve in a different way.

That's why, whenever I think about transformation, I always come back to one simple idea: people, processes, technology.

But there's a principle that has to stay at the center: people. Because, in the end, technology can enable change and processes can give it structure, but it's people who make a transformation actually happen.

“Technologies change. A culture of innovation and change endures and evolves.”