• IT projects are judged on delivery, not on whether they actually deliver the promised business impact.

• No one is held accountable for business benefits after funding is approved—this is seen as normal, but it's insane.

• A benefits-based governance model is not only possible, it's easier, smarter, and long overdue.

With normal IT project governance, we are not held accountable to deliver the business outcome that we promised when we applied for the funds.

I find this totally crazy, and I'm somewhat disappointed with myself for not realising it earlier in my career. It wasn't until the middle phase of my career, when I began specialising in project rescues/turnarounds, that this dawned on me. It was through repetition that the silliness of traditional governance dawned on me.

Think about it.

For any significant IT project to be approved for funding, we need to build a business case. The business case demonstrates to the funding body that our project will change the business in such a way as to recoup more money than we spend on the project.

The "recoup" bit is what we refer to as the "business benefits". Typically, this comes from reducing our operating costs or increasing our revenue.

So typically, if we want to spend $1m on a project, we will need to demonstrate that we'll recoup at least $500k per year. The idea is that such a project would pay for itself within two years, and after that, we are making a profit as it were. Actually, these days, most IT investment boards are looking for a one-year payback, so the same project would be expected to pay back $1m per year.

But under traditional project governance, this is the last time that benefits are discussed—even after the project is finished and everyone has gone home.

Let's use an analogy to demonstrate the disconnect.

Imagine I offered to fit a gadget to your car for $500 that will double your mileage, so you can go twice as far for the same cost of petrol or halve your fuel cost for the same distance. So I say your annual fuel bill will come down from $3,000 to $1,500. I say the gadget will be supplied and installed in less than a week.

Sweet deal, right? So you go for it. You hand me $500 expecting me to give you something in return.

But what are you expecting from me in return for your $500:

1. A gadget supplied and installed in a week for $500, or

2. Half your yearly spend on petrol?

I'm hoping you went for option 2; it's the correct answer. Having a gadget in your car is irrelevant if it doesn't deliver the benefit I promised you, right?

And yet in IT, we measure our success according to option #1. Did I install the system in the time I promised, for the budget you gave me?

Worse still, in IT, I can ask anyone on the delivery team what business benefits we're expected to deliver, and no one will be able to provide a sensible answer. I know this because I've spent over a decade asking the question in the context of project turnarounds—and I've never been given a practical answer. Not once.

This isn't the delivery team's fault; it's a by-product of a governance model which was invented in the '50s when building computer systems cost as much as building a building. Whilst the IT world has been flipped on its head in economic terms, we've stuck to a governance model that no longer works.

It's worth noting that the various flavours of agile since the 1990s have not offered up an alternative (agile) governance model either. In my opinion, this is why agile has had limited success—it's been constrained by a traditional non-agile governance model that can't cope with incremental delivery.

In our car analogy, we use a benefits-based governance model—I expect a result, not a gadget. In IT, we use scope, cost and time instead. We're deemed successful if we deliver the system we promised, in the time we predicted, and for the budget we asked for. It matters not whether we deliver even a fraction of the business benefit we promised. No one is held accountable.

In almost 40 years of projects, I've never worked for an organisation that routinely evaluates the business benefits actually delivered by a project.

But is it even possible to use benefits-based governance in IT?

Absolutely—and benefits-based governance turns out to be far simpler, effective, efficient and satisfying than the traditional model.

More on benefits-based governance next week.

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

Andrew Walker
Consulting to for-purpose CEOs to deliver more impact with existing teams and systems - by freeing humans up from admin.
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

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

Back issues available here.