Want Benefits-Based Governance? First, Fix How You Deliver

• Incremental delivery means incremental release to real users—not just internal sprints or builds.

• No release, no user adoption; no users, no business benefit—period.

• True incremental delivery is rare but critical, and the best place to start your shift toward benefits-based governance.

Why Benefits-Based Governance Makes Sense

The idea behind benefits-based governance is straightforward. Most executives would naturally prefer a tech change that begins delivering business value from day one, rather than one where benefits are deferred until well after the project concludes.

Rather than interpreting a flurry of secondary outputs — project plans, scope documents, and so on — we can hold teams accountable for the real outcome: the business benefit we’ve committed to deliver.

As with any form of governance, the way we hold our teams accountable is closely tied to how those teams operate day-to-day.

How Delivery Needs to Change

To support benefits-based governance, we need to rethink how delivery works. While there are several important techniques, one stands out: incremental delivery.

This means breaking large, complex projects into smaller, manageable parts and delivering them one at a time.

Why Agile Isn’t Enough

This shift is easy to overlook because many IT teams believe they're already doing this through their agile practices. But in reality, agile has often promoted incremental build, not incremental release.

Agile teams typically work in “sprints” that produce working components. These are usually batched and sent for “user acceptance testing”, before being released all at once toward the end of the project.

The Critical Distinction: Release vs Build

This distinction is critical for benefits-based governance. We can’t unlock any real business value until users are engaging with the new system in their actual work.

What’s commonly referred to as “incremental delivery” in IT would be more accurately called “incremental release”. Unless something is reaching real users, it doesn’t matter — from a benefits perspective — how iteratively we’re building behind the scenes.

No users means no benefit.

The Misconception of Incremental Delivery

The idea of assembling and releasing new technology in small, usable increments is surprisingly rare — despite being widely believed to be the norm.

As executives, it’s important we understand the difference by asking one simple question: how frequently are we releasing into production or live environments?

The answer is often: “Well, that’s impossible, of course we don’t do that.” What follows is usually a long list of reasons why true incremental delivery is seen as unrealistic.

Yes, It Is Possible

Let me be clear: genuine incremental delivery — releasing usable components to a subset of users — is not only possible, it’s better, faster, and more cost-effective.

I’ve seen this approach succeed in more than 200 projects, including some of the most complex corporate environments.

Start Here, Not There

Because incremental delivery is foundational to benefits-based governance, I often recommend starting here first — even before changing the governance model. From a change management perspective, it’s a gentler starting point, allowing us to shift culture one layer at a time.

Even within incremental delivery itself, there are phased procedural and cultural changes we can introduce to improve outcomes step by step.

What’s Next

In future articles, I’ll explore common objections to incremental delivery, along with practical ways to embed the practice into our delivery teams.

When you're ready, here's how I can help:

Andrew Walker 
10 years AI strategy & implementation for executives in staff-heavy organisations, often with mobile .

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.