The NHS IT delivery programme has a dreadful track record. It is not surprising when you look at their methodology and the techniques the NHS and the ISIP programme recommend for benefit mapping, benefit management and benefit realisation. They are fundamentally flawed.
Here are some of the many reasons why they fail:
- They ignore the landscape and context, confusing benefits at different levels
- They ignore impact and consequence
- Being unclear where change needs to happen
- They treat enablers as the same as impact
- Projects and enablers are confused
- It makes following the timing and tracking deliverables difficult
First lets look at the NHS benefit management material. You can either look at the approach in the NHS ISIP benefits mapping or look at the alternative approach in the ISIP Benefit dependency network masterclass material.
1) Understanding the landscape and context
The first thing you will notice is that although the talk about benefits to particular parties, they are not specific about those parties and how they relate.
Imagine you are in a PCT (Primary Care Trust as was). You are delivering technology to GPs so they can access a more complete view of patient records for a particular care pathway. It is important to realise that there are dependencies across that pathway that will involve other healthcare professionals such as tests in pathology labs, x-rays, hospital discharge records, and perhaps even records in Social services and district nurses. It is only when you have all of these in place that you will start to give benefits to patients. Until then you need to be clear who is involved and how they interact. Without this complete view of the landscape, the next step is impossible.
What you have is a sequence: PCT, GP, patient. What you need is to be clear about the benefits at each level.
2) Distinguishing between impact and benefit.
The second mistake that the NHS benefit approach makes is not to distinguish the difference between impact and benefit at each level. So for a GP, you can implement the system but other pieces of work will be necessary to ensure that the benefits for the GP and at the GP level, are implemented. So you actually need two levels of “benefit” for each body: “How am I affected/What is changed for me” and (separately) “What is the benefit for me”.
Notice there is ALWAYS a timing difference here. You implement a system and the benefits of that implementation at the point of implementation come later (if at all).
It is the same at the patient level. There are always two “benefits”. The first is the impact, “I can now make my own booking” and the consequence “Which means I can choose when I want and appointment”. These are often assumed to be the same but they are not. The patient may be able to make their own booking but something in the system may stop them getting the appointments they want (or even getting through). If this is the case the “benefit” of being able to make your own booking becomes more of a nuisance than not being able to.
It is “impact” and “consequence” at each level, for each party, that needs to be considered. The models within the ISIP and NHS benefit maps do not make this clear. Again you have to have the NHS landscape clear here as well, to do this.
3) Enablers vs impact.
This is a really important distinction. Again confused by the way the material is presented and the lack of context in any examples.
If I am in a PCT and am introducing a Long Term Conditions system across multiple healthcare providers then I am putting in place some enablers of this technology, perhaps software, training, new hardware or infrastructure, interfaces between systems, protocols, new working practices, that are used across multiple healthcare professional groups (Acute, GPs, Social services, community nurses, polyclinic, etc.) .
These are enablers that work across the various parties involved, BUT ARE NOT directly impacting those involved. For instance the link between the GPs systems and the central Long Term Care system is an enabler. The impact is that GPs can then see the more complete pathway and other Health care professionals can also see what the GP has put on their referral forms more easily (provided you have also rolled it out to all the GPs, given them access and trained them).
It is an enabler. Think underlying capability or common infrastructure.
4) Being clear where change work needs to occur
Now everywhere there is an arrow between these enablers, impacts and benefits and then onto further impacts and benefits, you need action and change.
So why does the ISIP benefit dependency network go:
Enabler -> Projects (and Actions to change) -> Outcome -> Benefit -> Priority objective?
It does not make sense. Projects deliver enablers. Actions turn outcomes into benefits. All operate at different levels.
What we have been drawing is clearly a set of dependencies where actions for change are needed at many levels across the NHS landscape and environment. In fact everywhere an arrow exists, some change intervention is required. If you don’t think about this you are at best leaving things to chance and at worst destroying any chance of the project actually delivering the benefits at any level.
5) Projects and enablers are confused
Lets be clear here. Projects do need enablers (give me some funding, resources, technology and an enthusiastic clinician to make things happen). But the enablers are different at different levels. This whole model seems confused about this.
However it is useful to talk about enablers. It is the Infrastructure or common enablers that are delivered by projects. The project will also deliver impact on the health care professionals or care pathways and help then enable their own benefits.
Another example of strange labels is Priority objectives. The way they draw the sequence of boxes there is “priority objective” at the end. In other words the sequence should ultimately lead to this priority objective. I agree, but that is not how to represent things.
What you will have when you develop these benefit maps across the landscape is perhaps several for the Long Term Care priority objective. One set of projects for Diabetes, another for heart conditions, another for COPD etc etc. What we are doing here is explaining how a priority is delivered by the chains of enablers, impact, immediate benefit across the various levels . By the time you reach the benefits for the patients you may have 4-6 ultimate significant benefits (that result from the impact of the project on their care). Now you don’t want to have to draw a link from each of these to a box called “priority objective”.
The whole benefit map is a description of how the priority objective will be delivered. So it should be a label on the benefit map, rather than a linked ultimate outcome. Think of the wrapper around the benefit map, or simply its title.
6) The implication for phased delivery and timing
So this is a more structured approach that is sensitive to how the impact and benefits work at any level of the health landscape. This is where the real advantage comes in. With this richer picture you can track the stated benefits at any level across the landscape you have drawn.
First have you got the enablers in place? Then have you put in place that which will immediately impact the care professionals? What are you doing about the benefits you promised for them? Have they occurred or are they not using the system because it is a pain, slow or “just another system to log out of and into”. And when will it be delivered?
Having this clear cause and effect model in your benefit map enables you to clearly show what has been delivered and what is holding up progress. Having a muddle that mixed outcomes and benefits at each level makes it impossible to draw, impossible to use and impossible to manage.
I have been using such benefit maps in the NHS for over 5 years now. Whenever I present them I first get them to check the landscape before showing them the benefit model laid over the top. This way they agree the landscape before they start to think about the benefits, consequences and impact of the project. It works.
Shame they did not do this before they wasted £6bn on the programme for change and subsequent NHS IT programmes.
By the way, you will have realised that this approach is basically strategy mapping. Therefore it is really easy to make the step to “How would we measure this” and developing a modern NHS balanced scorecard for the operation of the care pathway or service. Really easy, but to find out how to do this you’ll have to talk to me.
Phil Jones
