In short
- Three mechanisms sink a grand transformation: size (scope written from assumptions rather than observation), time to first effect (months of analysis before anything works) and change fatigue.
- An organisation has limited capacity for new processes at once — a transformation tries to exceed that limit in every department simultaneously.
- Believing in the whole ≠ seeing proof. A large programme asks for belief before anything is visible; a small implementation shows the result first.
- A small implementation that works creates proof, and proof drives the next one — the following decision rests on experience rather than a promise.
- Small steps carry risk too: you can end up with a set of disconnected tools. The difference is that here the risk is cheap and visible immediately, rather than expensive and surfacing after a year.
The problem starts with size. A program planned to cover everything at once requires defining the scope up front — a scope nobody has actually worked through in practice — so it gets defined based on assumptions, not on what's really happening on the shop floor. The bigger the plan, the more assumptions it contains, and those assumptions only turn out to be wrong once the work is underway.
The second mechanism is time to first result. In a large program, the first working tool shows up after months of analysis, documentation, and sign-offs. During that time the company keeps paying and waiting, and enthusiasm among management and teams cools off. By the time something finally exists, part of the organization has already decided it's just another project that won't pan out.
The third is change fatigue. An organization has a limited capacity for new processes at any one time, and a transformation tries to push past that limit across every department simultaneously. People resist the next new thing before they've had time to get used to the last one, and the rollout gets stuck — not on technology, but on everyday resistance.
Why small implementations succeed more often
A small implementation reverses each of these mechanisms. The scope is narrow enough to be based on what's visible in a single department, not on assumptions about the whole company. The result comes quickly — within a few weeks there's a working tool that someone starts using, so before the enthusiasm evaporates, there's already proof. And the change touches one process in one department, which fits within the organization's capacity.
But the most important difference lies elsewhere. A small implementation that works creates proof, and that proof drives the next one. A company that has seen one solution in real use already knows what it wants from the next, and makes the following decision based on experience, not a promise. A big transformation works the other way around — it asks you to believe in the whole thing before you've seen anything.
That doesn't mean small is enough forever
To be fair: small implementations carry their own risk. You can build one, then another, and end up with a set of disconnected tools that don't add up to anything bigger. The difference is that here the risk is cheap and visible right away, while in a big transformation it's expensive and only surfaces a year later. A sound approach doesn't rule out thinking broadly — the point is to arrive at the broad picture through a sequence of small, proven steps, instead of one leap. I describe this way of working separately in the methodology.
What we don't know yet
Before acting on this article, it is worth checking whether the answers to these questions are known on your side:
- how much change your organisation actually absorbs at once — a limit no board decision can override;
- after how many months the planned programme produces an effect visible to someone outside the project;
- who owns the whole once priorities shift or the person leading it leaves;
- what you will treat as a signal that the direction is wrong — and whether anyone will be willing to say so;
- whether a sequence of small steps can add up to a whole, or will end as a set of disconnected tools.
Frequently asked questions
Why do digital transformations fail?
Usually for three reasons at once: the scope is written from assumptions because nobody has done it in practice yet; the first effect appears after months, so enthusiasm cools; and the change covers every department simultaneously, exceeding the organisation's capacity.
Are small implementations enough in the long run?
Not on their own — you can complete several and end up with disconnected tools. The difference is that you reach the wider picture through a sequence of proven steps rather than one leap, and a wrong direction costs one stage rather than a year.
What should we do instead of a large programme?
Start with the single process that hurts most and treat it as a test of the whole approach. If you are planning digitisation as one large programme, ask after how many months the first real effect appears and whether the organisation will wait that long without proof.
What counts as progress in an implementation?
A working tool in the hands of the department and a measured change against the state before it. Further meetings, documents and presentations are activity, not progress — they can run for months without changing anything in the process.
What's next
If you're planning "company digitalization" as one big program, it's worth asking yourself how many months will pass before the first real result appears, and whether the organization can survive that much waiting without proof. The alternative is to start with the one process that hurts the most, and treat the first implementation as a test of the whole approach. I describe how I run this work, from the first step through to scaling up, in the methodology.
→ See how the small-steps methodology works
→ Book a 30-minute consultation
