Using process mapping to solve problem statements

by | Apr 25, 2022 | 0 comments

In February 2022 NHS Digital published the blog “What is your problem?” by Tero Väänänen, which focuses on “why it is important to define the problems we are addressing before trying to solve them”. This blog will look at where problem defining and problem statements can be applied to process mapping.

The NHS blog focuses on understanding the problems that an organisation is facing by using Problem Statements. This is encapsulated by the metaphor used from Alice in Winderland; “If we don’t know where we are going, any road will take us there, but how do we know we’ve got to the right place? How do we know we have solved our problem or the problem of our users?”

Defining the problem

As Tero describes, the best way to start to define the problem is to look at the recourses already on hand. Tero describes this as data that has been collected on the existing service such as survey data on user satisfaction, cost analysis on existing solutions, how people are talking about the problems on social media, or problems with resources. This focuses on factual data that can be analysed and turned into problem statements.

What is a Problem Statement?

Tero describes that a problem statement should:

      • only describe one problem at a time. It’s sometimes difficult as there are so many problems we’re trying to solve, but it’s critical that we write these up as separate problem statements. It may be that we can solve some of them and de-prioritise others. If we bundle distinct issues in a single problem statement, we increase the risk of throwing the baby out with the bathwater: problems that were perfectly solvable on their own, get tied up in a complicated and difficult problem statement that is then deprioritised because it is too big
      • not describe any solutions. It is important that we only describe the problem and not solutions. We don’t want to taint the process by inserting our preconceptions, even if we feel they are right. Trust the process; there will be time to write down all the possible solutions later!
      • be based on facts. How do you know this is a problem? We should have some data to back this up. The data could be from user research: users are struggling with something or we have observed something could be more efficient. This could be from quantitative data analytics showing bigger trends in use. This is the data that will eventually show us that we are starting to solve the problem
      • not assign blame. There’s no place in problem statements for assigning blame – be that to another team, directorate, or a 3rd party. Stick to the facts and move on
      • be concise. Describe the problem with enough detail to make the problem clear but keep the problem statement concise

Tero proposes that ‘Problem statements’ are the solution to ensuring that the real problem is discovered.

This approach to defining problems isn’t fool proof, getting the right people in the room is essential for all of the problems to be discovered accurately. Furthermore, the users may not recognise some of the inefficiencies in their process as a problem as that is how that have done the work for many years.

 

Where can process mapping support this?

Process mapping is an easy way to solve this problem, the Engage Process Modeler is an easy to use process modelling tool that utilises graphical icons and is based on BPMN. The use of a collaborative tool such as this is essential to understanding the current process as the users can see and comment on the process map as it is being built live in a workshop.  A previous blog “How to run a process mapping workshop” covers how to facilitate a workshop to get to these outcomes. A key role is that of the project facilitator, who in smaller process mapping workshops is commonly the business analyst;

      • A key role of the workshop facilitator is to set the pacing of the meeting. It is important that all objectives set out in the planning phase are covered and given appropriate time for discussion. It is also important to ensure that everyone is contributing and that everyone is contributing equally without one person or a group speaking for the majority.
      • Throughout this discussion, a record needs to be kept of the key points such as decisions or issues for future workshops. It is usually more effective to set someone other than the workshop facilitator as the ‘scribe’ so they can focus fully on running the workshop.

Using process mapping as a way to discover problems and problem statements is effective as the business analyst can question and challenge parts of a map where the service don’t see it as a problem, but technology or logically there is a more efficient way or reaching the desired outcome. Although process mapping can be a lengthy exercise, the maps that are created, especially if a To-Be (future state) map has been created are vital to the service areas running and training for the services they provide. To-Be process maps can also be developed as part of a redesign project and act as a blueprint for developers to build the new way of working.

What does this mean?

In conclusion, Tero’s approach to using problem statements as a key method of defining and discovering a service area is effective, but may lead to some inaccuracies as the service users may not consider things a problems where they should be investigated. I believe that combining this method with process mapping using the Engage Process Modeler is an effective way to discover and define a service activity whilst creating useful recourses for the team and development team to use.