Blog / Exploring how making changes to a service can have a knock on impact using cumulative risk mapping

February 10, 2019

We often use tools such as risk mapping to think about potential effects of interventions in projects and how that might cause a problem in the future. These risks might be internal project risks (e.g. ‘not enough time to deliver the project’), more project specific outcomes (‘building a new admin system might mean more work for admins’), or wider concerns (‘will users use the new system’).

This tool borrows and builds on risk mapping, as well as systems thinking concepts such as causal loops, and the Iceberg Model to think about unseen impacts on systems.

Often risks are arranged from a business, technical or design aspect. We’ll use these at kick off to get a wide range of stakeholders to comment on what they see as project risks, and which they think is most important to mitigate during the project phase.

More recently we’ve been exploring how to map the knock on effects of making design interventions in projects. Certain risks aren’t apparent from the outset and only become tangible through mapping out the compound effect of changing parts of a service.

For this we have started to use a method called cumulative risk mapping.

Stages of cumulative risk mapping

Stages of cumulative risk mapping

Why would you do it? Put simply if you change elements of a service by making design interventions, then it can be useful to see how that will affect other elements. Most of the time, any unintended outcomes will be obvious and picked up by the team as and when they occur. However in complex services it may not be as easy to see the knock on effects from the outset. Also by waiting till the unintended outcome becomes obvious it might already have wasted time or budget. By visualising it early it helps all members of the project team to see and understand the proposed changes and how they will affect other elements of the system.

How to do it

This tool helps to understand what system risks might occur as a result of implementing those interventions. Once you have some planned interventions and intended outcomes, it’s time to start thinking about the possible undesirable outcomes that may occur from making a design intervention or change to a service within a system.

Example project: Public Health England – UK National screening committee

Example project: Public Health England – UK National screening committee

Once you have mapped out exhaustively the potential unintended outcomes, think about how these outcomes will affect users of the service, and then other stakeholders. As always things might not be linear and when adding directional lines to show what affects what you might find things going backward as well as forwards.

Tailor the stakeholder impact to areas that your service touches on, taking into account the of needs and requirements of those groups.

Tailor the stakeholder impact to areas that your service touches on, taking into account the of needs and requirements of those groups

The important thing is to be comprehensive, and to think as widely as possible about what could happen as a result of the changes the team proposes to make. Having a full as possible team available for this process will help generate as many examples as possible. It will also help when it comes to generating mitigations for the unintended outcomes.

Generating mitigations to the prioritised cumulative risks.

Generating mitigations to the prioritised cumulative risks

Once you have mapped out the results of a design intervention the team should vote on which part of the unintended outcomes poses greatest risk to the service. These will then be prioritised throughout the project as needing to be considered through mitigations. You might find these mitigations become features of the prototypes they are based of, essentially predicting future problems early (in the example shown, utilising a template became part of the acceptance criteria of that user story).

A completed systems impact map for one intervention.

A completed systems impact map for one design intervention

When to use the cumulative risk mapping

We would typically use this tool at the end of discovery or beginning of alpha when there should be some concepts generated that can be prototyped and validated during alpha. Use these as the starting points.

One way of generating these design interventions is to do a theory of change exercise, to identify what the small design changes are you are making and what the intermediate and longer goals are for those changes (a cumulative impact).

Further reading

You can use this tool in tandem with a theory of change, as a way of generating the design interventions in the first place. Read here for more about our ideas on theories of change.

You may want to develop a systemic vision at this stage. For example we are trying to move away from [problems of existing service] towards a [service with intended outcomes] whilst avoiding [identified cumulative risks] as outlined here (p62).

You may also want to look into hypothesis testing and creating a hypothesis board, as a way of generating links between design interventions or prototypes and intended benefit to the service.