We increasingly live in a world that demands ‘just do it’ action, where our time is limited and things just need to be done, and done right now. But what does this mean for problem-solving?
Let me ask you this: think of the last time you did something, and it didn’t quite go to plan. Did you get time to reflect on why things have gone wrong, learn from it, and make it better for next time? Did you talk about it with anyone?
Or did you just ‘make it work’ – i.e. work harder or longer, and hope you’ll get to it when you next have the chance? And did that chance ever come? When we talk about Continuous Improvement, problem-solving is naturally at the heart of it – after all, isn’t Continuous Improvement about making things better?
But I often find that there is a sense of disappointment when the problem-solving methods we teach don’t prove to be the ‘golden carrot’ to magically solve all issues we ever find. Let’s explore some of the common issues faced when implementing a team-based problem-solving approach:
1. We can’t solve what we can’t see
Quite simply, we can’t expect to tackle problems that we don’t know about. So this is why Problem-Solving approaches need to work hand-in-hand with Visual Management – so that everyone can see when we have had a situation that isn’t quite right. This sounds quite simple, doesn’t it? But thinking back to the question I posed earlier, if we are engrained in a culture of constantly working around issues, with a “I’ll get to you later” mentality, it is very easy to get into a mind-set of “it’s not a problem, I’m just doing my job”, so the issue never gets flagged. Secondly, the culture of some organisations can be one of “don’t tell me bad news”, and a problem is seen as exactly that. We need to start seeing problems as ‘opportunities to improve’ that need to be shared, not failures that we are embarrassed of and that must be hidden. I’ve often found that a simple way to break these cycles is to conduct a quick Post-It note brainstorm with staff – asking them “what makes you have a bad day?” – to immediately highlight operational issues.
2. Waiting for it to become a problem before we tackle it
By virtue of the fact that it’s called ‘problem-solving’, many seem to have the notion that we should not report or take action on something, until it is a full-blown problem – which is actually quite a reactive mentality. Think about this – the last time you had a problem, was it a total surprise, or did you see it coming? If it was the latter, could something have been done sooner to head it off, and if so, would that have lessened the impact of the problem, or stopped it happening at all? With many organisations, I have used a document template called ‘the 3Cs’ – Concern, Cause and Countermeasure to facilitate the recording of issues. In this context, I much prefer the use of the word, ‘Concern’ rather than ‘Problem’ – as it implies we should be more proactive in flagging issues, based on concerns we have rather than waiting for them to become full-blown problems.
3. Groundhog day
I should explain – for those of you much younger than me, or those who do not share my taste in movies – Groundhog Day is a film, starring Bill Murray as a weatherman who, trapped in a time-warp, lives out the same day of his life, in exactly the same way, several times over – much to his frustration. How is this relevant to Problem-Solving? Well, in two aspects – firstly those problems we think we solve, that keep coming back to bite us. Wasn’t it Einstein that said, “the definition of insanity is doing the same thing, again and again, and expecting a different result”? With these types of problems, we should encourage teams to take more structured approaches, such as Root Cause Problem Solving, to challenge their thinking, beyond their usual assumptions. Secondly, when we solve problems – especially where we have made such a time investment to figure out root causes – we should share these with our colleagues, so that they can benefit from our learning too, rather than living out our ‘Groundhog Day’ for us.
4. No help
A big part of what makes team-based problem solving so effective is that it is “team-based”, in that we encourage teams to flag and try to solve problems themselves – breaking away from the mentality of “I do stuff – I don’t solve problems”. But we need to recognise that there will be times when the local teams don’t have the answer; or if they do, they don’t have the authority to implement it. So this is why, with any team-based problem-solving approach, there needs to be a clear path to get help. Back at the beginning of my career, the best example I saw of this was at a metal foundry – a very dark, hot, noisy environment. In that organisation, a problem that was only ten minutes old could result in the scrapping of a huge billet – costing up to a £m each time. So to facilitate rapidly problem-solving, they implemented a ‘Help Process’ that would provide support to staff in minutes, if a problem could not be solved locally.
Since then, I have always thought that if people in an organisation, in that harsh environment, can support each other so effectively, it should not be beyond us in our somewhat cosier offices to do the same. Also, doesn’t ‘Help Process’ sound so much better than ‘Escalation Process’? I have shamelessly re-used that term for many years now!
5. Understanding the psychological aspects of change
My final point is a favourite topic of mine – related to psychology, and is particularly pertinent to when large-scale, cross-functional problem-solving activities are being carried out. I’ve facilitated many of these events where they have become quite heated, with strong differing views coming from different parts of an organisation – sometimes resulting in angry confrontations or distraught participants. Many of you will be familiar with the Kubler-Ross Change Curve, with regards to change management – but this is also relevant in the context of problem-solving. In such groups, whilst there can often be the excitement of brainstorming potential solutions to a long-standing problem that will finally be solved, we should not forget those who are still coming to terms with the fact that there is a problem in the first place.
Many years ago, one of my first-ever projects as a Lean practitioner was to implement a local problem-solving process in a large-scale manufacturing environment, based on learning from a conference hosted on the topic by Toyota. I have since been fascinated by how well such approaches can work, in terms of flagging things that were previously unknown, and solving the things that many thought could never be fixed.
Today, more and more innovative solutions are available on the market and I have seen many companies jumping a stage in the process, thinking that implementing a specific app will magically solve all their woes.
In reality, Operational Excellence and technology need to work hand-in-hand to deliver the right outcomes. No application or software can help an organisation improve their process operations unless people are given the opportunity to first get to a place where they feel confident to flag issues early on, and work together with their colleagues to address them. This is why it is always vital to carry a full assessment first and then decide on the best technological solution available.
