Most digital transformation programmes launch well and fade quietly a year or two later. The tools stay installed, but the energy behind them disappears. Based on the author’s experience building a Digital R&D function from scratch, here are six things that consistently separate the programmes that keep delivering from the ones that quietly stall.
1. Digital roadmaps
A roadmap is not a wish list of projects. It is a sequence, with a reason for the order. Data foundations tend to come before advanced analytics, since a predictive model has nothing to learn from if the data underneath it is not there yet. A roadmap that skips this ordering usually ends up with several unrelated pilots running at once, none of them building on the others, and no clear sense of what comes next once the current wave of projects finishes.
2. Hub and spoke
Two extremes both fail. A fully centralised digital team becomes a bottleneck, since every request from every part of R&D has to queue for the same small group of specialists. A fully devolved model, where every team builds its own tools with no coordination, produces duplicate effort and systems that cannot talk to each other. A hub and spoke model splits the difference. The hub owns the platform, the standards, and the harder technical work. The spokes, people embedded in individual teams, apply that platform to their own local problems. This keeps the centre from drowning in requests while keeping local expertise close to the actual science.
3. Data unicorns: domain plus digital knowledge
The people who make the biggest difference in a digital transformation are rarely pure data specialists. They are the ones who understand both the science and the digital tools well enough to translate between the two. A brilliant data scientist who does not understand formulation chemistry will build models nobody trusts. A brilliant formulation chemist who cannot work with data will keep working the old way regardless of what tools get bought. The people worth investing in most are the ones developing both halves at once.
4. More data engineers, less data scientists
Most organisations reach for data scientists first, because the word sounds like the exciting end of the work. In practice, a data science team without solid data engineering underneath it spends most of its time on plumbing. Getting data cleaned, connected, and reliably flowing is unglamorous, and it is also the work that everything else depends on. A team weighted toward engineering, with fewer, well supported data scientists sitting on top of that foundation, tends to produce results faster than the reverse.
5. On the job support
Training sessions rarely change behaviour by themselves. People go back to their desks, hit a real problem the training did not cover, and quietly revert to the old way of working because it is faster than figuring out the new one alone. What actually changes behaviour is support available at the moment someone gets stuck, not a workshop that happened three weeks earlier. This is a slower, less visible investment than a training rollout, and it is usually the one that gets cut first when budgets tighten, which is exactly why it is worth protecting.
6. Few big bets
A portfolio full of small, safe initiatives feels productive and rarely produces a result big enough to change how the organisation sees digital. A small number of larger, well resourced bets, chosen deliberately rather than accumulated by accident, is more likely to produce something visible enough to build momentum. This does not mean abandoning the smaller, useful work entirely. It means being honest that most of the organisation’s attention and executive sponsorship should go toward a short list, not spread evenly across everything that got proposed.
Success does not end at launch
The six factors above get a programme started well. What keeps it running is a different, quieter set of things, easy to under-invest in once the initial launch energy fades.
Adoption has to be tracked on purpose, not assumed. A tool that nobody actually uses six months after launch did not fail at the technology stage. It failed at adoption, and that failure is usually invisible until someone finally checks.
Maintenance is the debt that comes due after year one. Every automation, dashboard, and pipeline built during the initial push needs someone to keep it running as systems change around it. A roadmap that only budgets for building things, and never for maintaining them, quietly accumulates a backlog of things breaking faster than anyone can fix them.
Data management is not a one-time project either. New data keeps arriving, new sources keep appearing, and the governance put in place at the start needs to keep pace with that or it stops matching reality.
Few big bets shows up again here, deliberately. The discipline of choosing a small number of priorities does not end once the first ones are delivered. It has to be renewed each year, or the portfolio quietly drifts back toward a long list of small, disconnected initiatives, the exact pattern the roadmap was meant to avoid in the first place.
Digital is closer to a sport than a purchase
Buying a pizza is a single transaction. You pay, you eat it, and you are done. A lot of digital transformation gets treated the same way. Buy the software, run the rollout, declare success at the launch event. But digital capability works more like a sport. Buying a football does not make anyone good at football. Getting good takes training, repetition, and people building a skill over time, in a way that never really finishes.
The same is true here. A new tool creates no impact by existing. It creates impact once people actually use it, get better at using it, and build it into how they work day to day. That is why on the job support and adoption tracking matter so much, and why maintenance and data management never stop being someone’s job. Digital transformation is not something an organisation buys once. It is a skill an organisation keeps training.
Frequently asked questions
Why do digital transformation programmes stall after launch?
Usually because the effort put into the initial rollout—the roadmap, the kickoff, the training—does not continue afterward. Adoption, maintenance, and data governance all need ongoing attention, and they are the parts most likely to get cut once the launch is behind everyone.
What is a hub and spoke digital operating model?
A structure where a central hub owns the platform, standards, and harder technical work, while people embedded in individual teams—the spokes—apply that platform to their own local problems. It avoids the bottleneck of a fully centralised team and the fragmentation of a fully devolved one.
Why fewer big bets rather than many small initiatives?
A portfolio of many small, safe initiatives rarely produces a result visible enough to build momentum. A small number of larger, deliberately chosen bets are more likely to demonstrate real impact, which in turn earns the sponsorship needed for the next round.
Does training alone change how people work?
Rarely by itself. People tend to revert to old habits once they hit a problem the training did not cover. Support available at the moment someone gets stuck matters more than a workshop that happened weeks earlier.