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.

I am sure there are many reasons – but I have noticed one that is not often mentioned.

Failing teams have a culture of risk-avoidance.  Successful teams have a risk-embracing culture.  They are diametrically opposed – and it affects how they deal with risk.

Risk-avoidance cultures want the risk to go away.  They want no risk to remain.  They secretly believe that if the risk management process is done well, risk will actually be removed – even though they know that engineers are not perfect so this ideal is rarely reached.  In these teams, risk management is a discrete task: something you do at select times in the project which, when completed, results in the removal of risk.

Risk-avoidance cultures say:
Risk must be eliminated – it should not remain on my project!

Risk-embracing cultures believe that risk is a fact of life.  They expect it at any turn. They are comfortable with risk.  They learn to love looking for risk. No matter the mitigation plan – they reason, something can always go wrong – so they keep planning for it.  Risk management is a continuous affair – almost a state of mind.

Risk-embracing cultures say:
Risk is part of our life – we expect it and use it to get better

In my experience, no team is purely risk-avoidance or risk embracing. These are opposite poles of a spectrum – the team tends towards one or the other.

I have learned to identify the dominant behavior (avoidance or embracing) by looking for telltale signs of how the team reacts when risk becomes an actual problem (i.e. it was not avoided).

A warning:  Do not confuse risk-avoidance with risk-adverse. They are two different concepts. I know many successful entrepreneurs who are clearly  risk-embracing and yet are very risk adverse. I also know team leaders who are in the risk-avoidance camp but are reckless risk takers.

Engineering teams do well in a risk-embracing culture.   It is the nature of engineering work that we cannot predict everything. Evolving an approach that always looks for what can go wrong, understanding the source of the potential problem and creating adaptive mitigation plans  requires great engineering skills. It’s actually challenging and fun.