• Stop buying tools you don’t need—use what you have and integrate smartly.

• Kill the busywork—ditch documents that exist just to impress governance committees.

• Ruthlessly prioritize—only build what delivers measurable business value.

It wasn't until I was routinely delivering projects with a benefits-based governance model that I realised just how wasteful our traditional governance and delivery models are.

I would often be pulled in to turn around a failing project at the point where half the budget was spent, only to find that I could take a fresh start. Often I'd win a project that had previously been budgeted using the traditional model, only to find that I could deliver expected business benefit for way less than 50% of the forecast spend.

As extreme as this sounds, it’s actually perfectly logical.

While there are numerous levers for this cost reduction, three big ones stand out, because in a benefits-driven model:

• We tend more toward getting extra value from existing systems than we do buying or building new ones.

• We avoid a huge amount of unnecessary work generating traditional governance documents.

• We avoid delivering capabilities that have little or no impact in delivering the business benefit.

Less focus on buy and build

In a traditional governance model, the project's focus is almost always on buying or building a new system. This is natural because we're working in an information vacuum; we don't have a benefits-based "north star," so in its absence, we shift to "we need a new xyz system."

The problem is that once we shift focus to "system xyz" instead of "benefit xyz," we've ruled out anything but a new system.

An example of this is the most dramatic turnaround I've worked on, which was a 10-year failure. For 10 years, various attempts had been made to get funding for and deliver a project. Each time this project was positioned as "xyz system replacement" rather than being a benefit-based target. Once it was called "publishing system replacement," another was "call centre replacement system," and so on.

Without exception, I've found that it's faster and more cost-effective to use existing systems as a base and provide better integrations and user experiences around these systems to make data entry more efficient.

Buying new systems is more costly for several reasons:

• Buying applications involves initial and ongoing licence costs, whereas integrating or wrapping existing systems with new user experiences can be done with ubiquitous, cost-free technologies.

• For a purchase, the process of funding, selection, negotiation, provisioning, and customisation takes at least a year, with the associated resource and licensing costs. This time also represents an opportunity cost because it delays the benefits we're hoping to achieve with the project. Avoiding a purchase decision means we can start immediately.

• Resources with certifications in a particular vendor product are always more expensive than their "open" counterparts who use ubiquitous skills and licences.

Avoiding governance-centric documentation

When we analyse the documentation we're required to generate in a traditional governance model, we realise how little of it is necessary for the solution we're delivering. Most project documentation is actually only required to demonstrate progress.

By adopting a simpler and more relevant progress metric (business benefits delivered), we avoid the need for most of these documents.

Most architecture and design documents are not necessary because we can easily fit within existing standards by using the integration and user experience technologies already approved in the organisation. We don't need infrastructure architecture documents because we're not introducing any infrastructure—we're using services already hosted by our existing email and drive vendor.

We don't need to map current and future states or specify our system upfront because we don't need to evaluate a vendor product. We're just on the hook to deliver outcomes. Because we deliver these gradually, sponsors have ample time to correct our course of action in the rare event that our initial capability in one area misses the mark.

Avoiding delivering low-value capabilities

No solution is perfect, and no solution will deliver every feature imagined by our intended audience.

The problem with the traditional governance model is that we don't have any yardstick to measure or qualify high value from low value.

This leads to a "kitchen sink" approach to managing scope. If "the business" requests a feature, we're on the hook for it.

In reality, this is hugely wasteful. We end up configuring and building things that have no impact on the business benefits we're intending to deliver.

In contrast, a project team focused on delivering business benefits will continually ask the question, "Is this the most valuable thing we can be implementing next?"

This means two things:

• We build the most valuable things first.

• The things we don't address by the end of the project are, by definition, of marginal value—when measured against the yardstick of business benefits.

Close

Like many of the best things in the world, benefits-based governance and delivery is super simple and yet very powerful.

Dramatic cost reduction is only one of the profound benefits of this model. In my next instalment on this model, we'll investigate the positive benefits of improved morale and motivation.

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.