Updated: Jul 12
Whether the problem currently demanding your attention is getting your toddler to stop tormenting the dog or finding ways to increase the visibility of your company, there is one prerequisite that most people tend to overlook: define the problem.
It’s a basic requirement of Problem-Solving methodology that before even attempting to tackle the issue at hand, we know exactly what the problem is. It’s such a fundamental, and obvious, part of the process that I’m often shocked how many people, and organisations, skim over it, if not miss it altogether.
How many meetings have you sat in on where the problem is simply assumed?
Let me give you an example: Some years ago, a large manufacturer of construction equipment, producing more than a hundred heavy construction machines per week, each worth upwards of £30,000, asked me to sit in on a meeting to investigate a serious quality problem.
When I started to read through the documents relating to the issue, I wasn’t surprised to note that it had been a thorn in side of this company for several years. There had been many meetings, both with engineers from the factory, distributors and service engineers on the road. Nobody had found a solution. Worse, nobody really knew exactly what was causing it.
Now, let me make something very clear – these were clever people. Some of the sharpest engineering minds I have worked with were involved in this situation. But, let’s face it. We’re all busy, we’ve got lots on our plate at any given moment and while no solution seems to be presenting itself, there are other matters screaming for our attention.
And it’s also a matter of mindset. Once we are looking for a solution to a specific problem, it rarely occurs to us that we’re looking in the wrong place. The meeting began like this:
Me – Thanks for letting me sit in on your meeting. As you know, I’ve been asked to help the effort to find a solution. Before we go into the slides and graphs, I’d like to start at the very beginning. What, exactly, is the problem we're looking at?
Engineer – (Pulling out a large steel pin, around 4 cm in diameter, from a box next to the table) As you can see, this pin is completely chewed up at one end. Reports from customers indicate that these things are snapping in the middle of operation and causing some very serious near-misses on site.
Me – So what’s the problem?
Engineer - That we have a serious safety issue.
Me – Yes, I see. However, without wanting to appear pedantic, what is the problem we’re trying to solve?
Engineer – These pins are snapping and we don’t know why.
Me – So, that pin in your hands, which must weigh at least 3 kilos, is snapping during the operation of the machine?
Engineer – Yes.
Me – Wow, that is something. And whilst we have this chewed up pin, have we actually had any of the broken ones sent to us?
Engineer – No, not yet. We’ve asked some of the customers and distributors that have told us of the problem to send one to us but, as yet, we haven’t received any.
Me – So, again, I don’t want to appear smart, but may I suggest that, at this point, we amend the problem definition to read something more like ‘Due to a malfunction that appears to be chewing up the ends of the pin, there is a customer perception that we have a safety issue on our hands’.
And whilst I agree that I appear to be splitting hairs, I must point out that we have no concrete evidence that the pins are snapping and looking for a solution to that problem is leading us in the wrong direction. We’re looking for something that could be breaking these pins – I assume you’re investigating whether the pins are fit for purpose, whether the steel is meeting specification, whether the dimensions are correct etc, right?
Engineer – Yes, that’s exactly what we’re doing.
Me - So, we actually have two problems – something is chewing up the end of the pins, and customers have got the impression that they’re snapping. Each of which needs to be approached separately.
Can I ask that we split the team into two parts and address each issue individually – the larger part of the team can carry out a full Root Cause Analysis, detailing 5 whys etc, whilst the smaller part of the team tackles the PR aspect, which should revolve around informing the customers exactly what we’re doing to investigate the problem.
As it turned out, within a week the team, not me, had discovered that a tool used to seat the bearing that housed the pin, was not functioning correctly and the bearing was therefore being seated at an angle. This had caused it to seize once dirt had got into it and, because the bearing was no longer turning, the movement of the pin in the machine was slowly chewing up that end of the pin. No broken pins were ever found.
After correcting the tool, a full check of all machines was carried out during routine maintenance and changed where necessary. The problem was considered resolved within 3 months.
Again, I must point out that none of the above reflects poorly on the team – they were taking all the information at face value. But defining the problem correctly requires a stubborn adherence to what might be called a ‘dogged refusal to believe the obvious’.
In any situation where a problem is being investigated, be very wary if the 'Definition' aspect of the investigation is conspicuously short. Just ask yourself if assumptions are being made and ask: 'Really? Is that actually the problem?' You will be surprised at how often the definition will change upon closer scrutiny. And what’s the worst that can happen? You come across as a cynic. So what?
This idea of taking information at face value is a glitch that also seems to afflict sales people. A good salesperson is looking for problems to solve. He discovers a need and then tailors the product to suit. But is the problem that he or she has unearthed an actual problem? Or just the incorrect perspective of the customer? That's the subject of an upcoming post.