Quick summary:
Underlying issues can identified by establishing the context to which the current problem exists. We can help identify context by understanding the larger goal that is trying to be achieved, as well as qualatative research such as interviews. By doing so we can ensure we focus our energies on creating appropiate solutions before commiting to any quick win projects.
In my introductory post I broke down solving a problem into key steps, the first being recognizing the key issue. Additionally I briefly talked about quickwins, the reasons why people undertake them, and the potential drawbacks of using this approach. Committing to any quickwin solutions, before finding out why a problem exist potentially means wasted effort. We need to first identify what our key issue is.
The leaky bucket example
Put your imagination caps on and consider the simple scenario - we're trying to fill a bucket of water, but it never seems to fill up. Our first step is to identify our problem . In this case we have an old bucket that isn't filling up.
All we know at the start is we're stuck with a leaky bucket problem.
The next step is asking why? Why is it not filling up? We find out through some observational research (i.e - we look at the bucket) that it's because its not filling up faster than its leaking out. There are two clear issues here, one the bucket isn't being filled up fast enough and secondly the bucket has a leak. To fix the leak in the bucket properly it is going to take time and resources, while filling up the bucket faster is simply a case of turning on the faucet more.
So using the quickwin approach filling up faster clearly makes more sense from a cost / benefit viewpoint. If we increase the speed at which the bucket fills up to the point its faster than its leaking out then the bucket is going to eventually fill up. So we've resolved this issue and can move onto another issue? Obviously this is an extremely short sighted solution as soon as we stop filling up the bucket its going to leak out and empty again.
We were able to implement a very fast low effort solution to solve the problem, but we've pretty much resigned ourselves is to never stop filling up the bucket. Ultimately filling up the bucket faster is not really the issue we need to fix. This shortsightedness can cause all sorts of additional headaches.
Take for example:
We've turned on the faucet further in an effort to fill the bucket faster since that's the "quickwin" solution to our problem. But the faucet is still not going fast enough, we turn it on as far as it will go, but it's still not fast enough. Now our problem is that even with the faucet on maximum the bucket is not filling up fast enough. The new solution is having to install a faucet that outputs more water.
We have all of a sudden gone from a simple bucket issue to a faucet issue. We already decided on trying to fill the bucket faster and which has locked ourselves in to replacing a faucet which is going to take much more effort and money to resolve than if we simply gone ahead and fixed the leak. Business often end up in this situation and is a prime example of the 'Escalation of commitment' or 'Sunk cost fallacy' (two related key issues that will see future writings on). Let's end that example right there before we spend any more time getting lost in that forest.
So in our initial identified problem "Because its not filling up faster than its leaking out" we focused on the first part, the speed at which we're filling up since that was a really quick and easy way to resolve it. It should be fairly clear that we should be addressing the leak rather than the speed at which we're filling the bucket. The reason we ignored the leak was that it was going to take more time and effort to resolve it properly. But what we ended up doing by filling up faster was working on a solution that never really solved the issue, and just ended up being a fruitless endeavor.
Our water bucket example may seem a tad exaggerated, but if we simply swap out the leaky bucket for a realistic business issue such as customer retention then our example isn't so far fetched. Business often seemly try and fix falling customers numbers by trying to fill their buckets faster, rather than fixing the leak that exists.
So why don't we always just fix the leak?
As we stated earlier filling the bucket faster was supposed to be the quickwin solution, but as soon as we stop filling the bucket we're back at square one. Fixing the leak was going to be a project that cost time and resource. So what options does this leave us?
What we're missing is context.
For me this is where the important questions get asked and we can begin to build a clear picture of the project. We've been told that the current situation is we're filling a leaky bucket at a faucet. That is the problem we've been issued to solve. But the magic happens when we ask why?
Why are we filling up at a faucet? Why are we filling up a leaky bucket? And the ultimate question. "What are we trying to solve, with the bucket faucet situation?"
In our situation we get the following answers:
We're using the faucet because it's outside, we're using a leaky bucket because it's the only bucket we have, and what we're ultimately trying to do is water our garden.
As we get each answer, we think of other questions we could be asking, but as soon as we get that final answer 'watering the garden' everything becomes much much clearer. Why are we watering the garden? Because it was observed that the garden was dry. Bingo! We've identified the actual underlying problem we're trying to solve.
All these issues all revolve around getting water from one place to another. Now that we know the actual issue, our initial problem, a leaky bucket not completely filling up has context and we can plan an appropriate solution.
Revealing the key insight
So how do we apply this rationale and figure out what the underlying issue is? It all comes back to asking 'why?' Start by identify everything you know about the problem and everyone that is involved. In the real world this often would be who the project stakeholders are, or who the business unit owners are, and who the end users or customers are. Next thing is identifying a timeline of events that takes place before this current problem and what happens after.
Once we identify what's happening before and after the problem, we can see the bigger picture.
Once a this has been created, we can add in all the relevant people in the project onto the timeline. This technique helps you create the context you need and illustrate where people involved in the project fit into the picture.
We can then add in all the people, objects, platforms, actions involved in the timeline.
Once you have a timeline of events and have identified where people fit into the picture we can then begin to do some qualitative research such as interviews. Meg Sewell wrote a great article titled "The use of qualitative interviews in evaluation" which identified interviews being great for capturing and understanding processes from participants.
Interview all the project stakeholders and customers to reveal goals and insights into the problem.
We need to identify what their requirements are and how they tie into the picture. We need to ask what their goals are, and more importantly why they have those goals. If they don't know why, it may mean you need to expand your timeline longer and or involve people up the proverbial 'food chain' that do know why. Everyone's requirements are likely to be vastly different each other, and careful consideration should be made to ensure all views and goals are recorded. Note although all goals should be recorded, priority should be placed on those people who are most relevant to the project.
Once we see the larger picture we can establish what are the reasons that lead us to encounter this problem. In our example, what lead us to try and fill a leaky bucket under a faucet? We can then move onto figuring out what the best solution to this problem is, while understanding the larger goal at hand.
In the next blog post in this series I'll talk about solving the problem now that we have the right information.