This article unpicks the major causes of large IT delivery failure and presents an alternative delivery model to the popular ‘programme’ construct.
This article was co-authored with Dave Rogers.
Most big IT programmes just don’t work.
Headlines abound of costly, embarrassing and major IT 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 business, are filled with temporary staff and the programme incentives are often misaligned. 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 IT programme disasters?
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. These audits and 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 life cycle. Strong financial discipline is still required and this does not preclude writing large business cases. It just means that not all the funding is released in one go.
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 usually 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 product owners
Product 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.
Autonomous products teams consistently have higher staff satisfaction and create greater business alignment.
The old and new models head to head
| Traditional Programme | Sustained Delivery Capability |
| Large budgets designed to motivate spending money at pace | Funding released in small increments based on validating outcomes |
| A temporary organisation, with fixed time and budget | A permanent capability, with a fixed number of teams |
| Temporary funding designed to deliver technology into live service | Permanent, proportional funding to sustain continuous improvement |
| Requirements set up front to solve a specific set of problems through technology | Requirements are adaptable, responding to user needs and business needs |
| A rigid and complex governance structure designed for over-reporting | Lightweight governance designed to trust teams to make their decisions |
| Complex interdependencies between projects coordinated by a central team | Decoupled service teams, run by empowered product owners |
Summary
Traditional programme structures create layers of separation, which result in duplicated effort and confusion over roles and responsibilities. As a result, programmes should only be used when there is a genuine requirement for coordinating multiple projects that must be integrated.
A more reliable, sustainable model proposes to invest in a fixed number of permanent teams that are funded long-term.
This article first appeared on Medium