Delivering an initiative is not the same as building a capability.

The programme dashboard is green. The system went live, the processes were redesigned, people were trained, the budget held. At the closing meeting, everyone celebrates, and rightly so. Six months later, the company still can't reliably do what the programme promised.

The new service model works in the accounts the project team looked after and falls apart in the rest. The new planning tool is used by a few, and everyone else stays on the spreadsheet. The second time the company has to run the process is as hard as the first.

Nobody lied on the dashboard. The initiative was, in fact, delivered. The problem is that delivering and being capable are different things, and most companies only measure the first.

Three things that get confused

Delivery is a condition for capability, but it doesn't guarantee it. And it's capability that sustains the result after the initiative ends.

The numbers show how wide that gap is. According to Gartner, only 48% of digital initiatives meet or exceed their business outcome targets. When business and technology leaders own the outcome together, that rises to 71%. The difference isn't the technology. It's who stays accountable after delivery.

Why the initiative ends before the capability

An initiative is designed to end. It has a dedicated team, a sponsor, a budget and a date. A capability is the opposite: it has to keep working when the team disperses, the sponsor moves on and the budget becomes a recurring cost.

Three patterns show up almost every time a capability fails to form.

• The knowledge leaves with the team. During the project, the people who know how to do the new thing are the project team. When it disbands, the know-how goes with it, and operations is left with a system nobody fully masters.
• The measure is adoption, not performance. "80% active users" says people log in. It doesn't say whether the company decides better, delivers faster or serves customers better.
• The enablers are left half done. The initiative takes care of one or two pieces, usually technology and process, and leaves the rest for later. Later rarely comes.

Capability lives in the operating model

There is a deeper reason for the gap. Most initiatives change one piece of the operating model and leave the rest as it was. They put in a new system but keep the same roles, the same decision rights, the same meeting rhythm and the same budget by area.

The operating model is how the company actually works: who does what, how work passes from one area to another, who decides and with what information. When the initiative doesn't touch it, the old model absorbs the new thing. The company goes on doing what it did before, now with a new tool.

That's why the right question at the start isn't "what are we implementing?". It's "what has to change in the way we work for the company to do this every time?".

What a capability is made of

A capability only exists when five enablers are in place at the same time:

• People and roles. Who does the work, with what skills, and who answers for the result.
• Process and handoffs. How work flows between areas, with clear quality criteria at every handoff.
• Technology and data. The tools and information that support the work, integrated with what already exists.
• Decisions and governance. Who can decide what, within which limits, and how exceptions are handled.
• Rhythm and evidence. A cadence where performance is measured and corrections happen.

When one is missing, the capability depends on heroic effort. It works while someone pushes and stops when that person leaves.

How to manage the capability, not just the initiative

• Define the capability before you define the project. Instead of starting with "implement system X", start with "what the company needs to be able to do, how often and to what quality". The project becomes a means, not the end.
• Map the five enablers and give each an owner. If the project covers technology and process, someone has to answer for roles, decisions and rhythm, with a date and a measure.
• Measure capability, not adoption. The right question is: can the company do this again, without the project team, in the agreed time and quality?
• Keep the owner after go-live. The capability enters the company's management cycle: it is read, decided on, mobilized and reviewed like any other priority.

The real finish line

A transformation doesn't end when the project ends. It ends when the company can do the new thing again without having to think about it, and when the next change finds an organization better prepared than the last one did.

Until then, the green dashboard is a good start. It isn't the result.

A question for your leadership team: of the last three initiatives your company completed, how many could it repeat tomorrow, without the team that implemented them?

Source

• Gartner, survey on digital initiatives (2024)