Hall of shame of problems
Ever wondered how to express a problem properly? Beside knowing “how to do this” let’s have look on what to avoid. This article shares my "hall of shame" of problems. A bit tongue in cheek but I want to share an easy method to get rid of "the broken pump".
As trainers and facilitators at CoThink we are specialised in describing problems within industry, pharma, IT and other businesses. When we facilitate a Root Cause Analysis with the subject matter experts, we explore the causes of the event to solve the problem and to avoid re-occurrence. In a training the participants practise with real-life cases that enable them to solve problems in structured way by using the RATIO-methods.
Why it's the hall of shame
This photo is taken during a training when I collected the various ways the participants described problems.
This is quite a normal way of communicating and everyone understands generally what is meant. But when you're communicating about a problem it matters how you express yourself. And general understanding is not good enough!
In a typical problem-progress-meeting, everyone wonders what is meant by "Pump NOK", "Please fix". Needs the pump to be replaced? Is there a leak? What is the impact on the process? What's really going on with that pump? And the one who wrote about the problem is not available (asleep to prepare for his next shift).
And what to think of:
The consequences of these vague descriptions are numerous and often lead to: extra costs due to solving the symptom, loss of (production) time and associated costs and/or hazardous situations. I'm not complete but you get the picture: it matters how you express a problem.
A "How To" describe problems
To describe problems we use a standard format: "subject + deviation". And when you agree to be as specific as possible this could lead to:
To solve complex problems I visualise them with an Event Map. It's built with answers on questions I ask as a facilitator to the people with expertise. The answers need to have specific subject and deviation. And you can expect me, not to settle with "defect" for an answer.
The benefits of this approach are:
- Problems are solved quicker
- The communication is about facts, not opinions
- Encouraging further action/investigation instead of “Jumping to conclusions”
- Time is used efficiently and not wasted on hearsay, assumptions and rumours
Putting the how to in practice
In the daily life of an operator, engineer or technician lots of problems are solved without Root Cause Analysis or dedicated facilitator. So what if you start to use the "subject + deviation " format to describe your problems? You get RCA's done directly on the shop/production floor! Instead of 2 experienced engineers you have them working in shifts 24/7.
To make this all happen you could let them read this post but it probably won't do the trick. Sit together and agree on how you compose a "good" problem description. If you need support or more inspiring examples…let me know: email@example.com.
Free training Event Mapping
If you want to know more on Event Mapping you could follow our free online course.