Why most IT strategies fail in the first year — and what boards should ask for instead of another glossy roadmap.
Every organisation we work with has an IT strategy document. Most of them are competent. Very few of them are still being followed eighteen months later. That gap between the strategy as written and the strategy as lived is one of the most expensive problems in technology leadership, and it is also one of the most fixable.
This article is our view on why strategies fail, and what boards and executive teams should ask for instead. It draws on a decade of strategy reviews, programme recoveries and post-mortems across Australian organisations. The pattern is remarkably consistent.
The strategy that fails most often is the one that tries to do too much, in too much detail, over too long a horizon. The document is beautiful. It has a vision, a set of principles, five strategic pillars, eighteen initiatives, a three-year roadmap, a financial model and a benefits realisation plan. It gets approved at the board meeting with warm congratulations. It then sits in a SharePoint folder and is rarely opened again.
Why? Because the document is too far from the operational reality of the business. The initiatives are described in technology terms rather than business terms. The financial model is built on assumptions that nobody is responsible for validating. The benefits realisation plan exists but no one owns it. The roadmap is a sequence of programmes rather than a sequence of decisions. When conditions change — and they always change — the document has no mechanism for adapting.
A strategy that survives is shorter, sharper and more honest about what the organisation is actually willing to change. It answers four questions, and answers them well:
Every strategy we help develop is paired with a quarterly review rhythm. Not a quarterly status update — a quarterly conversation about whether the underlying assumptions still hold. Did the cost of capital move? Did a major vendor change its commercial terms? Did the regulator do something unexpected? Did the competitive landscape shift in a way that changes the priority order of the bets?
The quarterly review has three deliverables: an updated assumption log, a list of decisions that need to be made before the next quarter, and a small number of explicit course corrections. The strategy document itself is updated annually, not quarterly — but it is updated in the light of what the quarterly reviews surfaced. This rhythm keeps the strategy alive without forcing it to be re-written every time something changes.
If we have one piece of advice for boards reviewing an IT strategy, it is to read the stop list before they read the roadmap. A stop list is uncomfortable because it forces the executive team to admit that some things they are currently doing are not contributing to the strategy. The absence of a stop list is almost always a signal that the strategy was not seriously negotiated inside the executive team. The presence of a stop list — and the willingness of the CEO to defend it — is almost always a signal that the strategy has been genuinely thought through.
A strategy without a stop list is not a strategy. It is a wish list with a budget.
Three questions, every quarter, with no advance warning:
If the executive team can answer these questions fluently, the strategy is alive. If they cannot, it is a document.
The job of an IT strategy is not to be a perfect document. The job of an IT strategy is to enable better decisions — under conditions of uncertainty, with imperfect information, in organisations where competing priorities are the norm. The right measure of a strategy is not how impressive it looks on the shelf; it is how often the executive team refers to it when making difficult trade-offs. If the answer is "not often," it is time for a different conversation.