How benefits-based delivery improves team morale

We've investigated how to govern IT projects based on the benefits delivered, rather than traditional document-based measures in the traditional model. We've also looked at the cost advantages of this approach.

But there are also a host of additional upsides to benefits-based governance from the perspective of team morale and motivation.

The big morale benefits stem from unique aspects of the approach:

• Tangible results

• Feedback in the first month

• Autonomy

Let's look at each of these.

Tangible Results

In a traditional project our progress is measured by the delivery of documents. We call these deliverables. They range from architecture and requirements to project plans.

But these artefacts are synthetic, even if we print them out on paper. They have no real meaning in a physical or financial sense. We can't internalise them in any meaningful way.

So the extended project team ticks these deliverables off one by one, but they have no emotional connection with them because documents have no inherent meaning.

With each gate ticked, we feel a sense of relief rather than excitement. We steel ourselves for the next document.

In a benefits-based scenario, it's easy for the whole team (business and technical delivery folks) to relate to something like "Wow, we've taken all these calls in half the time thanks to what we've delivered so far". These are real customers calling in to real call centre agents. We can take out a stopwatch if we want and see how much quicker the calls have been.

The whole team immediately has a sense of achievement because we've seen the link between "what" we're doing and the "why". Simon Sinek explains the research behind this in his "Start With Why" TED talk.

Feedback in the First Month

It's concerning that the traditional approach to governance actually never provides the extended team with any feedback at all on what business benefits they've delivered. Even in theory, we don't deliver any benefits until after "user acceptance testing" has concluded at the end of the project and we've deployed the new solution to all and sundry.

In practice I've never seen a business that measures this; they just pack up after the project team has gone home and they move on. Often it's taken so long to approve and deliver the project that the original sponsor isn't around anymore. At best this is demoralising; at worst (most commonly) it's subconsciously depressing and demotivating.

In contrast, benefits-based governance requires us to demonstrate real progress within a month.

It's one of the most satisfying aspects of helping teams work this way, to watch the reaction on the team's faces when they first realise that they've actually made a difference within the first month. Business people are as excited as the IT team, maybe even more so. And once a team has worked this way they find it hard to give it up because of the addictive, uplifting feeling of achieving something real.

It doesn't matter if the team has improved the life of just one call centre agent out of 2,500 - it's still real. They can talk to James, find out how he's feeling about the results and then widen the net to tens, then hundreds of other users as time goes by.

Fast feedback is a well-documented foundation in motivating teams. Benefits-based governance ticks this box where traditional governance fails.

Autonomy

The relationship between autonomy and motivation is well documented with a slew of studies and models developed as far back as the 1980s.

Yet in the traditional governance model the delivery team has no remit to make any choices at all. All aspects of the project are pre-dictated, from architecture and scope through to products, tools and programming languages. They're preset because they're the only proxy available for measuring progress. It's almost as though the delivery team is expected to be a bunch of robots, mindlessly following the instructions of those who came before them.

In the benefits-based approach, the team is given a goal, or a North Star, and they have reasonable autonomy on how to achieve that goal. Indeed, the team will likely try a few different ways to achieve the business goal early in the project and gradually settle on what gives the best "bang for buck". In a traditional project this type of iteration is seen as wasteful because we're using a different measuring stick. In a benefits-based world, iteration and experimentation is not only allowed, it's seen as necessary and efficient.

This choice gives the team a real purpose, a real problem to solve.

I've seen the effects of this autonomy first-hand on hundreds of projects and to this day it's a rewarding experience. Teams don't need coercion to work harder; they do what they need to do because they've taken ownership of the goal. I've seen a team voluntarily do a release on Sunday evening after dinner with the family, just because they were excited to see the reaction on Monday morning.

It's hard for me to overstate how motivating it is to work toward a benefits-based goal compared with the traditional governance approach - it really is transformational from a morale perspective.

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.