Why large technology programmes fail and what to do instead

This article unpicks the major causes of large technology delivery failure and presents an alternative delivery model to the popular ‘programme’ construct.

This article was co-authored with Arif Harbott.

Most big technology programmes just don’t work.

Headlines abound of costly, embarrassing and major technology delivery failures in the public and private sectors. These failures, almost always, involve multi-year programmes with budgets that amount to many millions of pounds.

The programmes are often run separately from the core business, are filled with temporary staff, and the programme incentives become increasingly misaligned from the priorities of the organisation. Therefore, rarely are the desired outcomes achieved.

Before an alternative model of technology delivery is discussed, it’s useful to understand the key reasons for these failures.

What are the main reasons for technology programme failure?

1. Trying to predict an uncertain future

An upfront, multi-year business case that attempts to predict the future rarely realises the stated benefits, particularly when technology is central to delivery.

Technology changes too quickly. Business and user needs inevitably change, too.

2. Inflexible and overbearing governance

Large programmes, due to their scale and complexity, can be overwhelmed by reviews, audits and assurance.

This means that programmes optimise their governance for over-reporting, meetings, and the production of evidence to defend against scrutiny. This excess governance take time, effort and focus away from delivery.

3. Misaligned incentives

Most programmes are measured and tracked on their budget management and delivery of rigid milestones.

This leads to programmes that reject innovation and changing needs. They instead focus on the delivery of rigid, anonymous Gantt charts.

4. Too large and too complex

Most programmes are far too large and interconnected, thus creating complex dependencies that make delivery almost impossible.

Massive programme budgets encourage poor fiscal management. Once budgets have been approved, the motivation is to spend money at pace. The ability to start small and grow spending in response to effective delivery is hampered by the fear of losing unspent budget.

5. Separated and temporary structure

Most programmes are run in isolation from the business. This can create a divide between the motivations of the programme and the motivations of the business. The programme ‘silo’ can lead to avoidable rivalries and tensions between the programme and business teams. It is common for a culture of blame to emerge when programmes fail to deliver.

Programmes that employ a temporary structure often use contractors or suppliers whose knowledge is lost when they leave at the end of the programme.

An alternative model — the sustained delivery capability

In contrast to large-scale technology programmes, a sustained delivery capability model exhibits the following characteristics:

1. Incremental funding based on outcomes

Funding is released in small increments based on validating outcomes at each stage of the technology lifecycle.

This reduces risk by allowing funding only to those products that meet user needs. It also gives better value for money as investment is focused on those products with the highest return.

2. Fixed number of permanent teams

A fixed (but flexible) number of permanent cross-disciplinary teams, staffed mostly by permanent staff who want to build their careers inside the organisation.

The benefits are that teams deeply understand the business, and organisational knowledge is retained. The added benefit of permanent, long-lived teams is that they outperform new teams.

3. Sustains the technology it creates

A healthy service requires constant attention, and continued well-directed investment. The lifetime costs of sustaining a service should be built into investment business cases.

Every technology system should have permanent funding, with an owner who is responsible for the roadmap, continuous improvement and prioritisation of investment.

This approach maintains reliability and effective security, and through iteration allows better alignment with changing user needs.

4. Adaptive to change

When building technology, change is inevitable, especially when creating new software as part of transforming a service.

Cross-discipline agile teams, independent from each other, but collaborating where data and services connect, maximises the ability to respond to new information, or changing context.

To respond to change, these teams must have autonomy. Their visions must be aligned, but their immediate delivery goals need not be.

5. Empowered service owners

Technology provides a service to the organisation, and these services should have strong ownership. Service owners and their teams should have autonomy to make decisions and create a culture of continuous improvement. These teams should be long-lived, multi-disciplinary and include people from business and technology.

Summary

Traditional programme structures create layers of separation, which result in duplicated effort and confusion over roles and responsibilities. When used to deliver technology, and meet uncertain user needs, they become dangerously ineffective.

A more reliable, sustainable model proposes to invest in a fixed number of permanent teams that are funded long-term.

Many organisations must realise that technology is core to success, and that permanent capability to deliver is more effective than periodic transformation.