A framework for thinking about problems - Part 5
If you followed this framework, you would identify OR eliminate different types of problems. In the example used earlier with the machinery breaking down, you would apply it as follows:
Your sound asset management strategies may have kept (ageing) equipment in good nick = potential problem eliminated.
Your people may be very skilled at planned preventative maintenance = potential problem eliminated.
You may have sufficient staff, and they are appropriately organised (right people, covering all the shifts, doing all the right work)
And so on...
Following the framework, you may eventually discover that you don’t have the system in place to monitor the performance (say heat loads) to warn you when something needs replacing or fixing or whether the usages should be changed.
The problem may well (simply) be the age of the machinery, but unless you have explored ALL the elements (strategy, systems, skills etc) of the problem, you can’t identify the real issue and you can’t solve the problem.
It is invaluable to have a tool/framework to think about and to help solve problems. Besides the obvious productivity benefits of solving the right problems quickly and efficiently, it has a very positive impact on the culture of the business as a good, methodical approach to solving problems based on logic. There are no ‘blame games’ to play, and no one needs to worry about defending the indefensible.
And it may just expose the people (which everybody knows) who have been gaming the system for years, and that is not a bad thing either - a rather positive unintended consequence.
Takeaways for the real world
I don’t expect anyone would ever whip out the little diagram in the middle of the next meeting and use it as a cheat sheet to solve a problem. (I don’t, so not sure you should.)
But what you can attempt to remember is:
Be critical in your considerations to understand whether a ‘problem’ being presented is actually merely a symptom.
Think carefully about whether the nature of that problem is a resource-type, a context-type or an opportunity type of problem.
Dig deeper into the nature of the problem: Ask yourself what type of resource, what type of opportunity etc.(It will be a bonus if you can remember the 4Ms, PESTLE and Product:Market fit.)
The root cause is likely to be one of the 6S’s. (If you forget what they are, just Google Peters & Waterman, In Search of Excellence.)
Figure out how to address the root cause.
Back to the Clever Engineer
Remember our opening story where the engineer solved the production line issue with a simple fan?
I disagree with the premise of the story.
Sure the engineer came up with a ‘smart’ resolution. However, the problem as I see it, is that they still have a problem (possibly many, including semi-daft CEO) not the least of which being that they still have a production line that does not fill every tube. Whether the Band Aid cost $20 for a fan or $8m for fancy scales, it is STILL a band-aid.
I tried to explain in this article how, by having a clear typology of problems, one can successfully and comprehensively diagnose the issues in such a way that the remedy is self-evident.
NOTE: This is the final part (5) in the series. Visit our blog and find the rest of the series which will be published on consecutive days.
Alternatively you can download the whitepaper in a single PDF.