First capabilities, then benefits should follow

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.