🌳Branching out to find root cause

We’ve got a problem in the field. 

We’ve classified the symptoms,

And collected the failed components.

What now?

There are several options we could go with here, but a good middle ground is a technique called Fault Tree Analysis. It can be formally written down, but more often it’s a natural progression of investigation that happens live.

We start with the symptom, and just keep asking Why? or What could cause that? until we find the root cause of the problem.

Let’s say we’re seeing an overspeed condition on a motor driving a pump.

Start with the symptoms - Measured overspeed

What could cause that? Faulty speed sensor -or- Speed command too high -or- something else

What could cause the speed sensor to fail? Bad supply voltage -or- damaged physical component

What could cause the speed command to be high? Incorrect feedback signal (flow measurement) -or- failing motor driver 

Keep walking down each branch of the tree until things start making sense!

Once we get there, close the loop by triggering the root cause in a working system, and see if we get the original symptoms. If we do, we’ve got our answer!

-Brian Schoolcraft

Don’t fix and forget!

What’s worse than finding a problem in the field?

Fixing the problem.

Then finding it again.

And not knowing how you fixed it the first time!

Has that ever happened to you? It’s happened to me!

We can avoid this by ensuring that the results of our fieldwork get written down, but that’s often not the priority of the front line guys who are finding and fixing things.

So, let’s make sure there’s one person (or group, depending on your size) who’s solely responsible for documenting the results of field issues. 

If they’re not directly involved in the fix, they’d interview the field team,

Compile any relevant data, 

And store it neatly so we can find it in the future.

So next time - we know what to do!

-Brian Schoolcraft

Get the parts on the table

“The trick to having good ideas is not to sit around in glorious isolation and try to think big thoughts. The trick is to get more parts on the table.” -Steven Johnson, Where Good Ideas Come From

Such a good quote! We can put it into practice in so many areas of product development:

The innovation phase

You can think “big thoughts” all day, but until you build something, they’re just unbounded ideas

The development phase

Which type of fastener should I use? How do I make this mechanism work? Who knows? 

Buy a few options. Build some samples. Make them real and get them on the table

The troubleshooting phase

Creating failure hypotheses is great, but it’s often much more effective to review every failure at once, and start identifying patterns.

How can you get things out of your head and onto the table today?

-Brian Schoolcraft