Why digitalization projects fail (and it is rarely about the technology)

Most digitalization projects do not fail on technology. They fail because no one in the organization was allowed to care about the whole.

I have seen the same pattern in three different worlds: in a startup with ten employees, in public sector with a thousand, and in a large corporation with a hundred thousand. The technology was rarely the reason things went wrong. The mechanism that broke the system was structural, and it was the same in all three.

The pattern: everyone is doing their job, and the result is still wrong

Take a typical procurement of a new operational system. Procurement buys the cheapest option that meets the spec, because those are the guidelines they are measured against. The operations manager pushes for the system that is easiest to implement, because rollout risk lands on their desk. The IT manager prefers the most secure option, because that is the column they will be audited on. The end user, when the system finally arrives, does whatever actually works in daily life, which often means using the new system as little as possible and keeping a parallel Excel sheet alive.

Every one of these people is acting rationally inside their own role, with their own incentives, and against the metrics they will be evaluated on. The problem is that the sum of their rational choices is a system nobody actually wants.

This is the part that surprises new managers and stops surprising experienced ones. There is no villain. There is no incompetence. There is just a set of mandates that were never designed to add up to a working whole.

The normal distribution argument

There is an argument I find myself coming back to that I call the normal distribution argument. In a startup with ten people you can, in principle, assemble ten brilliant minds. In an organization with ten thousand employees, the collective intelligence converges toward the mean. That is not an insult to anyone. It is statistics.

What it means in practice is that decisions in large organizations are rarely very good or very bad. They are mediocre, in the literal sense of being near the middle. The system that gets chosen is not the system that is right. It is the system that is not wrong, because every stakeholder has been given a partial veto and no one has been given the responsibility for whether the thing actually works end to end.

I want to be careful here, because this sounds like a critique of large organizations. It is not, or at least not in the way people usually mean it. Large organizations exist for good reasons, and they do many things small organizations cannot. But on this specific question (how a complex tool gets chosen and adopted), the structural odds are stacked against a good outcome unless someone deliberately fixes the incentive picture before procurement starts.

Suboptimization is the default, not the exception

The technical word for this is suboptimization. Each part is optimized in isolation, and the whole is worse than it could be. In my experience this is not an occasional failure mode in large organizations. It is closer to how they work most of the time, which is why it is so easy to miss when you are inside one.

You notice it most clearly when you move between contexts. The same person who would say “let us just try it for a week” in a startup will, in a corporation, sit through three months of stakeholder workshops about the same decision, because their incentive structure has changed even though they have not.

Now add AI on top of that

The most common narrative I hear from leadership right now is that AI will make processes more efficient, remove friction, and provide better decision support. That may be true in theory. In practice, AI accelerates exactly the same pattern I described above.

If procurement already buys the cheapest, AI helps them do it faster and with more confidence in a spec they did not write. If the end user already ignores the system, AI gives them a slightly more impressive system to ignore, or a chatbot to argue with instead of a form to fudge. If nobody asked the frontline staff before, AI makes it even easier not to, because there is now a plausible synthetic answer to every question you might otherwise have walked to the floor to ask.

AI does not fix suboptimization. It accelerates it, because it removes some of the friction that used to slow bad decisions down. That does not mean AI is pointless, and I am not part of the AI-is-overhyped crowd. It means that technology was never the actual constraint. The constraints were ownership, incentives, and the question that got asked before any tool was on the table.

What the successful projects had in common

I have also seen digitalization projects that worked. Not many, but enough to be able to compare them with the ones that did not. What set the successful ones apart was not better technology, bigger budgets, or more capable project managers. Those things help, but they were not the differentiator.

The difference was almost boring. Someone, usually one person with enough seniority to be listened to and enough operational experience to know what to ask, had spent real time defining the problem before anyone started looking at vendors. That same person, or someone they trusted, had talked at length to the people who actually do the work the system was supposed to support. Not in a workshop, not in a survey. In their workplace, while they were doing the job.

By the time procurement started, the relevant question was no longer “which vendor scores highest in our evaluation matrix” but “which of these options actually fits the way the work gets done, and what will we need to change about the work to make this work.”

A practical takeaway

If you are about to start a digitalization project, three questions are worth more than another round of vendor demos:

1. Who in this organization is allowed to optimize for the whole, and what are they measured on? If no one, the project has a structural problem that no tool will solve.
2. Has anyone, recently and without a script, spent time with the people who will use the system in their actual environment?
3. Are we choosing a tool to support a way of working, or are we hoping a tool will create one?

Talking to the people who do the work is still the cheapest step in the entire process, and it is still the step most often skipped. That is not a technology problem. That is the problem.