“What do you think of us using this software in our programme?”
“It generally looks fine, what is it for? What are you trying to improve?”
“Oh. Well. Umm, it’s so that we can collect data more easily and it’s in one place.”
“Mmm ok. So how does more data help? What is the problem you are trying to solve? What’s not working now?”
Sometimes the next part of the discussion is angry and defensive as the person simply wanting to use the new software (the shiny toy); but most often it leads to an interesting discussion about current frustrations, operational practices, and eventually the problem that is trying to be resolved.
Defining and being clear on the problem you are trying to resolve is the trickiest P by far of the courageous change framework. It also might be the least sexy, however it is one of the most important. It’s tricky because often what is stated as the problem is actually a symptom not the problem. The classic example of this is when we talk about wanting to use technology because staff are not being held accountable by their managers; we are trying to address a human problem with technology. It will not work.
Problems are like onions and those Russian doll set, you need to keep peeling back the layers to find the core. Instinctively we tend to know this, but we don’t know how.
Some techniques that can be of value include the 5 whys, user stories, clarifying the audience, interviewing stakeholders, creating problem trees, conducting root cause analysis, etc. All of these techniques help peel back the layers bit by bit. It’s rare that they will work on their own or that you will have time to do them in their pure form, but being familiar with them will help.
Because it is like peeling back layers, it is not always straightforward; it can be iterative and will depend on the person (and hopefully persons) you are talking with. For some starting with the current frustration and unpacking it will be best; for others starting with the desired end state and working backwards will be better.
The technique doesn’t matter; what matters is that you do the work. Get multiple perspectives, not just one. Listen. Clarify. Write down what you think it is, then check, double check. Often it helps to take the current understanding, do some simple design work and check back to have people interact with the design as this will help with defining the problem.
Call this what you like, whatever works for you, but do the work. Being clear on what you’re trying solve allows you to know when you have. And being done is nearly as important as starting.