1. Nederlandse website
  2. English website
  3. Site francais
  4. Deutsche website



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:

Communication dead. Pls reboot
Belt stuck Failing.
Again. Fix

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:

From Pump NOK To Seal pump 8301 leaking barrier fluid
From “Weird Fan     To Fan trips at 89 Hz"
From PLC Defect     To PLC #14-1 error on line 33
From Script failing To Restore script stopped at 6:34 PM

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:

Free training Event Mapping

If you want to know more on Event Mapping you could follow our free online course.

« Terug naar het overzicht
  1.  Faciliteren
  2.  Trainen
  3.  Implementeren
  4.  Contact