Let’s talk about Steve Jobs for a minute. He said, “if you define the problem correctly, you almost always have the solution”.
This statement is profound as there’s an emphasis on understanding the problem, rather than solving it.
And many people face this major obstacle in their approach to problem-solving. There’s far too much of an expectation to solve the problem than there is in understanding it.
#1 Don’t Panic! Just breakdown the mountain into small molehills
#2 Choose your molehills to overcome for a quick win
#3 Make sure your molehills are backed up with data
Let’s dive into each of these:
The number of people that panic at the sight of a problem is by the bucketful.
It’s important to change your mindset. If a problem is well-defined and broken down, it can quite easily be overcome.
For example, building an entire website is challenging. Building one page of it? Probably not so much.
Another issue with worrying about the problem; is that you’re not focused on defining or resolving the problem. You’re not even focused on getting started!
Does the phrase, making a mountain out of a molehill spring to mind?
Thought so. We just need to do the exact opposite here and break the mountain down to smaller molehills.
Remember what Steve Jobs said, define the problem.
There are a few ways to do this; there are 5 WHYs or root cause analysis. Whichever method you use, the key is to b r e a k i t d o w n…
Let’s look at a real-life example from my technology consulting project:
Problem: The client is not receiving their critical key performance indicator reports.
Why 1: The data analytics platform from which these reports are produced, has pending failed batch jobs.
Why 2: There are over 2000+ automated overnight jobs to run and the completion of “some” of these jobs are taking longer than anticipated.
Why 3: (at this point define “some”). 300+ jobs coming from two source systems are constantly failing and restarting. This needs more processing power.
Why 4: The failed records relate to data having poor quality than initially catered for.
Why 5: Poor data quality is being driven by service agents inputting long strings of data in a front-end system. Root cause identified.
Now that you’ve defined the problem with all the available facts, let’s choose our battles.
Although, finding a root cause is important, resolving the root cause is not always the quickest or most efficient solution.
Using the above example, this is the solution for fixing the root cause:
Restricting the usage of the front-end system and provide training, sounds simple.
What if the client has 5,000+ service agents across 30 major cities? Mobilising this would be a herculean effort.
Easily £250K+ cost & 4 months of effort.
Let’s look at another solution:
Confer with the client and your technical teams, whether these culprit string columns are even needed for the result?
The most likely answer would be no. As for KPIs, you wouldn’t use string columns but rather enumerated columns instead.
At this point, a solution could be, to drop these columns from the processing altogether. This instantaneously saves hours of processing.
Considering this is a live service, a major incident could be raised, and the change expedited.
Cost £25K & 2 weeks of effort.
This point is really important. Before you sell your solution back to the client: remember to have some hard facts and data to back up your claim.
Data is hard to argue against, it paints the story for you.
In the above example, the hard facts were:
There’s absolutely no shame in having a “no-solution option”. Basically, after the facts are evaluated, the solution is riskier or less cost-effective than living with the problem itself.
But to even arrive at the “no-solution option”, you need to define the problem and look at alternative solutions.
Sometimes, it’s difficult to establish all the facts, as there are time pressures to getting a solution agreed upon. In these scenarios, use experience, and your gut instinct with as many facts as possible.
To sum this section up, have something to back up your proposed solution.
Even if you do all of the above, remember nothing is foolproof. Ensure you have contingencies in the plan, a plan B, a failover plan etc.
You also want to make sure; your proposed solution is accepted. Ensure you tell a good story based on characters, action & outcome.
You could propose multiple solutions. One which you know will definitely not be accepted and one that is slightly radical but could be accepted.
Giving two distinctly different options will steer your audience towards choosing the option you want.
Let’s go back to Steve Jobs, he is also quoted to have said, “…first solutions you come up with are always more complex, and most people stop there…”
Remember this, as simple and elegant solutions don’t come up at the first go. We had a physical QWERTY keyboard in Nokia, before the multi-touch interface on the Apple iPhone.
If you’re still reading this, I hope you’ve found some value in this blog post.
If you’d like to be kept informed of more content like this, subscribe to my newsletter.
Feel free to reach out to my email [email protected], if you have some feedback or just want to say hello!
Check out my other blog on The Value of Your Data