Look after the capabilities, and the benefits will look after themselves

Save for later

Favourite

Many people think of an initiative in terms of “deliver the project” and then “realise the benefits”. The first part is reasonably well understood, the second is not. But often, what’s needed is quite straightforward. I thought I would share an approach concerned with a business, or technical, “capability”, that focuses on use of the capability to realise the benefits.

Many projects delivering an output are creating or adding to a capability. A business example would be a new software package enhancing a “supplier management” capability. A technical example would be a new diagnostics tool enhancing an “equipment maintenance” capability.

The whole point of the capability is for it to be used. It’s through using it that value is obtained. In modern organisations, it’s difficult to think of capabilities that are being used, but are not delivering value to the user directly, or the organisation more generally, or both. It’s convenient to think of value in two areas – operational and strategic.

From the operational perspective, value will be obtained if the results that users can achieve using the capability, for given effort and resources, is better than the alternative. They are more efficient and/or effective in what they do. Using an agile approach gives the best chance of achieving this – iterating the solution in-line with what users need to do.

From the strategic perspective, as a result of using the capability, the organisation will be obtaining value in terms of achieved outcomes, for given effort and resources, compared to other options.

So if a capability is being used, then it’s a reasonable assumption that value is being obtained at an operational level and at a strategic level. In other words, benefits are being realised without any further intervention. You may want to monitor the benefits as well, but first focus on use.

From my experience, availability and use are not often tracked. I have come across many examples where expensive assets are not being used as intended for simple reasons. The functions they support suffer as a result. Yet the cost of finding these cases and correcting them would be small.

With some simple analysis, you can get a clear understanding of what has to be done to get successful use of a capability, leading to the benefits. I use a drawing to model capabilities. It lets you share and develop the thinking, and get agreement to your approach.

I think of a capability as the ability to perform a function. The “feature” components of a capability directly support user functionality. I use the concept of “fabric” components to model the other parts that are required. These are often things that either the user is not aware of, or has no interest in. But if we think of a capability as everything needed to perform a function, then they are needed.

A capability can be considered in different states:

  • Exists - means that the feature and fabric components exist somewhere, either procured or built.
  • Available - means that the capability can be used, supported by its feature and fabric components. For every component, it’s a good exercise to list what available means. For a feature that might include the users having: knowledge of it, logical access, physical access, permission to use it, necessary training, and so on.
  • Used - means that the capability is being used, supported by its feature and fabric components, and the function is being performed, leading to the benefits.
  • Retired - means that the capability is no longer intended for use, and its components need no longer exist.

The Ministry of Defence has the useful acronym TEPIDOIL that can be used as a checklist for defining a capability:

Training

Equipment

Personnel

Information

Doctrine and concepts

Organisation

Infrastructure

Logistics

 

For a capability to be available, there is usually something needed under each topic in TEPIDOIL. Some will relate to components under your control. Others represent dependencies that can be modelled using “situations”. As an example, your team may be responsible for the products that lead to trained users (including fabric components like training courses and trainers). Alternatively, another area may be responsible for this, in which case you can model this as the situation “trained users exist”, and show that your capability is dependent on it.

Just because a capability is available for use, it still does not mean that users will use it. So, you can model the additional situations that will encourage use. The work to establish these situations is commonly thought of as “business change”. Your model can provide structure to this activity.

Start your drawing with a box for your capability. Add boxes for the feature and fabric components under it as a hierarchy. Add the situations that you have identified. Then link them with arrows to the capability as a whole, or to specific feature or fabric components. Indicate whether the arrow is showing the relationship “influences availability” or “influences use”. You can then add detail. You can show an ID, title and responsibility in the box. Additional information for managing the capability can be held in an associated table. This will include measurement details, with target and actual values.

 

 In summary:

  • Draw a simple diagram to identify what your capability consists of (everything needed to perform a function).
  • Add the situations that would make it available (use TEPIDOIL as a checklist, define what available means for each component)
  • Add the situations that would encourage use (the results of business change effort)
  • Use the diagram to share, refine the analysis, and get agreement to your approach
  • Monitor capability availability and take corrective action when necessary
  • Monitor capability use and take corrective action when necessary
  • Confirm that benefits are being realised, taking further action when necessary

It’s exciting times for Benefits Management, as organisations increasingly see success in outcome terms.
To learn about this, and other tools and techniques, and tune in to latest thinking come to the APM Benefits Summit on 22 June 2017 – see you there.

Ned Newton

Posted by Ned Newton on 3rd May 2017

About the Author

Ned is a consultant at Atkins, specialising in benefits management. He is a Benefits Management SIG Committee Member. With an engineering degree from Cambridge University, his career has included roles within projects and programmes across a wide range of industry sectors, including civil engineering, banking, airports, utilities and central government.

He now helps organisations identify, track and realise benefits on a wide variety of initiatives, ranging from small projects through to pan-government infrastructure programmes. He is a keen innovator with a track record for solving business problems with new tools and techniques. In recent years, his focus has been on "Outcome Relationship Models" - using a novel technique for outcome mapping and analysis. Over the last two years he has been helping establish the approach on six large government programmes.

{{comments.length}}CommentComments
{{item.AuthorName}}

{{item.AuthorName}} {{item.AuthorName}} says on {{item.DateFormattedString}}:

Share this page

Login or Register to leave a comment:

Recommended events

Recommended blogs

The Cake Theory of benefits realisation

13 March 2017

“There is only one cake,” I stated to the rather amused group in front of me. “And it’s only fair, if more than one person helped bake that cake, that they each get a slice of the cake.”

Save for later

Favourite

Lies, damn lies and… business cases

12 April 2017

Most people see the business case process as a form of medieval torture administered by accountants. They also, with some justification, question the quality and value of the business case once created.

Save for later

Favourite

Recommended news

Join APM

Sign up to the APM Newsletter.