When doing risk analysis, engineers have no problem identifying potential problems – answering the “what could go wrong?” question. The difficulty is with the mitigation plan – “How can we prevent it?”
Going over this problem in many coaching sessions, I discovered one reason why this is so
Engineers skip the middle step, of this three step process:
- What can go wrong?
- Why would it happen?
- How can we prevent it (or at least lessen its impact)?
Intellectually, it makes sense. If a risk has actually occurred, it’s now a problem. The normal engineering response is to perform a root cause analysis: “Root out the cause –the solution will be obvious” my first boss used to say.
But when considering risk – that is, a potential problem that has yet to happen, engineers tended to focus on prevention at all cost. I found that when they looked at what might happen, they were keenly aware of the potential impacts, and this naturally focused their mind on preventing the possible disaster. Solving this is simple: re-focus the team on the possible causes. Answer the question: Why would that (risk) happen?
However, it is not that easy discussing the cause of a problem that does not exist yet. After all Root Cause Analysis is a process of elimination. And, it is a lot easier to eliminate wrong causes, when the problem has occurred and we can test our hypothesis. In risk analysis, we work with suppositions.
To make the process easier, I have found that using Toyota’s five Whys is quite useful.
The process is simple. The “Whys” form a chain of questions, each consecutive “why” inquiring about the previous answer in the chain. (The goal is to ask “Why” of the previous answer – and not ask “why” five times about the initial risk and come up with 5 different answers). It is a chain of inquiry that digs deeper in each successive question.
In reality, I have found that we rarely need all “5” whys – 2 or 3 really helps to clarify the potential causes enough for a mitigation plan to emerge.
From the coaching file:
The QA team was discussing their proactive QA plan on phase 2 of the project. They were reviewing the design review process:
[Lead]: What could go wrong with this plan?
[Team]: The engineers might not follow the development process.
[Lead]: So what can we do about that?
[Team]: Hmm – I don’t know, get their boss to make sure they do it?[Coach]: Let’s focus on the risk first before we look at solutions. – try the 5 Why questions
[Lead]: OK – Why would they not follow the process?
[Team]: Because they don’t know it?
[Lead]: That’s not likely – we just had a kick-off where we reviewed the process with everybody.
[Team]: OK – Maybe because they don’t want to follow it?
[Lead]: That could be – but Why would they not want to follow it?
[Team]: May be they don’t agree with it
[Lead]: so Why would they not agree with it?
[Team]: I think they want to do it a different way
[Lead]: and Why do they?
[Team]: at the meeting, I heard some of them grumbling about the process – they think it’s too vague – they think they have a better way.[Coach]: OK – now let’s look at mitigation – how can we prevent the risk that they won’t follow the process, if the engineers think they have a better way?
[Lead]: I think we should have a discussion about the process with them – ask them what they think, see what they don’t like – you know – get buy-in…
(the rest of the discussion is for another post…)
Please note: There usually is more than one possible cause. The 5-Why approach tracks all causes until they are clear. Then, before mitigating, you need only assess the probability of the cause actually occurring is. Normally, you would mitigate the higher probability causes.
The 5-Whys have been criticized because they can trivialize the root cause process – leaving details out that would otherwise lead to a better solution. That is quite possible, when using them to solve a problem that has happened. However, they are the perfect tool for clarifying causes of potential problem – i.e. risk. Even if the clarification can lack some details, I have always found the 5-why method to help identify risk mitigation plans.
High Performance Engineering Teams embrace risk: they look for what can go wrong continuously (yes! almost every day), and seek to prevent the risk by adjusting their approach to the work. For this, asking why 5 times is a great tool.
