Every problem has defined way of solution but most important step in a problem solving methodology is the problem definition. You do this step incorrectly, and the problem would become a mystery and you will keep going to and fro on the solution.
The basic mistake – “this is what I think is the solution”. We make such assumptions before trying to find out what the problem is and work towards meeting the assumed solution to somehow fit the scheme. Let’s look at the reason as to why we assume the solution before diagnosing the solution.
– The experience talks; with experience we tend to believe that even if one parameter of the problem looks like something that you have done in the past, then we tend to deploy that as the solution.
– The timeline dictates; more often than not, we are in a situation where the timeline drives the solution. And sometimes we tend to assume the workaround is the solution.
There could be many such reasons involving expectations from the team, or you being looked upon as the solution provider. In no way should you ignore the first thought of the tentative solution. It should definitely be considered, not as THE solution, but as a hypothesis that needs to be proved with various aspects of fact-gathering exercise.
The problem definition approach – As a consultant, I have been part of many situations where the problem statement itself is so confusing that you spend a considerable amount of time trying to figure out what is needed to be done. In general the problem definition approach could be:
• Understand AS-IS – This tells you what is happening as of now and why this is being considered as a problem, along with is it really a problem. That’s the first step to validate what you have heard till now. But even while doing this, you need to make sure that all the stakeholders have been identified and the views of each and every one of them has been considered.
• Question yourself – the typical “5 whys” technique works well in this scenario; but make sure here that you are trying to find out why this is considered to be a problem and don’t divert towards the solution. The Toyota technique though, says “5 whys” but there is no limitation to this – sometimes it may take more.
• Keep an eye out for the detail – Explain the problem; describe it in such a way that it is understood as a problem. This should not have answers or probable solution in it. Don’t try to be creative while writing a problem statement. Explain it in numbers if possible. Ensure everyone involved (remember the stakeholders) have an agreement to it.
Always remember – not every problem is worth solving. Once you have defined the problem, check if there is a direct/obvious solution.
The problem statement should focus on the following:
– For whom is it important and why? – Identify the correct stakeholders who consider this as a problem.
– Whom is the solution beneficial for? (Remember the problem may be more important for a different set of people and solution could be for different.) For example – less number of forecasting data points for the meteorology department is a problem for forecasting but whatever solution you provide, the benefit is going to the masses and not just the meteorology department.
In an IT world, any project has a problem statement. What needs to be figured out is whether you have sufficient information to first define it, and then only you should try to figure out the solution. This is why the requirement analysis phase is so important.
Need to figure out what and why are you trying to solve? For whom are you providing a solution? And by when is the solution meaningful? Answer those questions and then work towards the solution.