Digital change rarely happens because a board wakes up enthusiastic about technology. It happens because specific, nameable pressures make the status quo untenable. External drivers are forces outside the organisation's control: shifting customer expectations, moves by competitors and platform entrants, the falling cost curves of specific technologies, and tightening or newly relevant regulation. A common way of organising this external scan is a PESTLE-style framing — political, economic, social, technological, legal and environmental factors (Johnson et al., 2017) — though it is one widely used lens among several rather than a universal taxonomy, and a scan that simply fills in six boxes without weighing which factors actually bite is busywork rather than analysis.

Internal drivers are just as decisive and easier to overlook, because they are uncomfortable to name in a board paper: cost pressure that makes the current way of operating unaffordable, the scar tissue of past failed initiatives that makes some options politically harder than others, and leadership change, which resets what the organisation is willing to fund and when. A new chief executive with an explicit mandate to modernise is a driver in its own right, independent of anything happening in the market. The analytical discipline is to treat drivers as competing claims on attention and money, not a list to be exhaustive about: a handful of external and internal drivers, triangulated against each other, is more useful than many boxes ticked lightly. Drivers that recur across categories — a customer-expectation shift that is also a cost-curve story — deserve more weight than any single-category finding, because they are less likely to be a temporary blip.

A transformation vision earns its place on a slide, but a vision statement is not a strategy. Rumelt (2011) argues that most of what passes for strategy is a wish list dressed up with ambition: a statement of where an organisation wants to end up, a set of financial targets, and a long inventory of initiatives, none of which add up to a coherent way of getting there. Real strategy, in his terms, has a kernel of three parts: a diagnosis that names the specific challenge rather than a generic one, a guiding policy that sets the overall approach without specifying every move, and coherent actions that reinforce each other rather than competing for the same scarce resource.

Applied to digital change, that kernel becomes strategic bets: a small number of resourced commitments the organisation chooses to make, each traceable back to a driver from the previous lesson, rather than a backlog of every digital project a workshop could generate. A bet is a bet because it could be wrong, and because resourcing it means not fully resourcing something else; an organisation that claims every priority is equally urgent has not yet done the strategic work of choosing. The discipline of narrowing is as much political as analytical — stakeholders whose pet idea doesn't survive the cut need an honest answer grounded in the diagnosis, not a vague promise that it might be revisited later.

A strategy document can survive a board meeting without anyone asking who is actually going to run it. That is the gap an operating model closes: it is how an organisation gets digital work done in practice — ownership, decision rights and the capabilities it relies on — and it is a distinct discipline from setting the strategy itself. Ross, Mocker and Beath (2018) describe five building blocks that established companies lean on as they pursue digital transformation. Three are technology platforms: an operational backbone that makes core transactions reliable and efficient, a digital platform that lets the organisation build new digital offerings quickly, and an external developer platform that opens the organisation's data or capability to outside developers. Two are organisational capabilities rather than systems: shared customer insight — a common understanding across the organisation of what customers value, rather than a different answer in every department — and an accountability framework that gives autonomous teams clear ownership and the authority to act on it.

The value of the framework is less in the five labels than in the exercise of asking, block by block, who owns this today. Most strategies are written at the level of what will be built; they are far less often written at the level of who is accountable once it exists, which is exactly the gap that goes undiscovered until a programme is already under way. An operating-model exercise that finds no clear owner for a building block is not a failure of the exercise — it is the exercise working, because it has found a gap the strategy document alone would have missed.

A roadmap is not a calendar with initiatives pinned to it; it is an argument about dependency. Before anything can be sequenced, the gap between the current state and the target state has to be stated honestly for each strategic bet — what capability exists today, what the bet requires, and what stands in the way. Legacy constraints are usually the sharpest version of this gap: a capability as modern as AI-assisted forecasting cannot be built on a transactional backbone that cannot reliably produce clean, timely data, no matter how good the forecasting model is. Dynamic-capabilities thinking makes the same point at a higher level — the capacity to reconfigure resources matters as much as the resources themselves, and that capacity has to be built, not assumed (Teece, Pisano and Shuen, 1997).

Sequencing follows from the dependency map, not from which bet is most exciting. Foundational work — the operational backbone, data quality, a stable platform — has to precede the capability that depends on it, even when that makes a roadmap's early stages look unglamorous next to the bet a board actually wants to talk about. The common failure mode is parallel delivery: resourcing every bet at once because sequencing feels like delay, which instead starves the foundational work of the attention it needs and leaves the exciting bet built on sand. A technology roadmap earns its name by making that dependency visible, so a board can see why patience early on buys speed later.

A strategy and a roadmap earn investment only once they are expressed as a business case a board can interrogate. Ward and Peppard (2002) set out the basic structure most digital business cases still follow: the costs of building and running the capability, the benefits it is expected to deliver — split into those that can be quantified in money, those that can be measured but not easily monetised, and those that are observable only qualitatively — and the risks and assumptions underneath both sides of the ledger. The temptation is to let the benefits side do the persuading and leave the assumptions implicit; a business case that survives scrutiny states its assumptions as plainly as its numbers, because every assumption is also an invitation for a board to ask what happens if it's wrong.

Cost and benefit estimates are also where optimism creeps in hardest, and not always innocently. Flyvbjerg (2006) found that infrastructure cost forecasts are systematically too low, for two linked reasons: optimism bias, the ordinary human tendency to underestimate how long and how much things cost, and strategic misrepresentation, where sponsors understate costs or overstate benefits to get a proposal approved. A digital business case is a smaller, less capital-intensive relative of the megaprojects Flyvbjerg studied, but the same two risks apply, which is why stating assumptions explicitly, and stress-testing them, matters more than the headline number any single estimate produces.