A3 by PowerPoint

aarrgh! all of the purists say! Death by PowerPoint. Yup.

But one of today’s realities is that many managers expect to be “briefed” and expect it to be done in a conference room with a projector and… PowerPoint.

Getting them to sit down and go through a single sheet of A3 paper is going to be a stretch at best. So let me propose an interim.

Five slides, six at the most.

No fancy headings, logos, etc. They take up space and distract from the message.

Simple text. No animation. Pictures, graphs to make the points.

The slides are:

Background / Current Condition

Briefly cover where we are, and why we are talking about this right now.

Back up your assertions with data and facts. Note that, in my context, a “fact” is something you can see, observe, sense, touch. The data must be explained by the facts.

Target

What is this going to look like when we are successful?

The target is binary. It is verifiable as “met” or “not met.” It does not include vague words like “improved” or “reduced” which are subject to interpretation.

Analysis

What is keeping us from hitting the target right now? What is in the way? What must be solved, what barrier must be cleared, what factor must be eliminated?

Clearly demonstrate that dealing with these issues will allow reaching the target.

Countermeasures / Implementation

What actions will be taken to deal with the issues or shortcomings?

When will they be taken?

Who will take them?

When will they be checked for successful implementation?

For each one, what is the predicted effect if it works as planned?

How will you check the actual effect?

Do the cumulative predicted effects of your countermeasures add up to enough to close the gap and reach the target?

If not, then what else are you going to do?

Results / Follow-Up

What actually happened?

If When things got off track, what is the recovery / correction plan?

If When actual results were different than planned, what else are you going to do?

Did you reach the target? If not, what else are you going to do?

It’s the thinking, not the format!

Do the headers change sometimes? Sure, but the intent is:

What is happening?

What do you want to happen?

What is the gap?

What will you do to get it there, and how will you check that:

  • You did you you planned.
  • It worked like you expected?

Do it.

Check it.

Fix it.

Learn.

PDCA

This is a leader’s tool

If it is done well, and done correctly, it is done the way John Shook describes it in his new book Managing to Learn. But don’t confuse the size of the paper with the structure of the thinking. Get that right. Worry about the sheet of paper later if you must.

When encountering resistance, a good teacher knows what things can be left for later, and which ones are critical to get right.

Not Just Asking Why? – Five Investigations

I hit around this issue in the past, but with the recent publication of John Shook’s new book Managing to Learn, I felt the need to go into it again.

In the text, Shook’s coverage of root cause investigation is very thorough. He tells the story of each “Why?” question triggering another round of investigation.

But in a full page sidebar, he uses the example from Taiichi Ohno’s classic book Toyota Production System: Beyond Large-Scale Production. For those of you following at home, the original example is on page 17 of Ohno’s book, and the reference to it is on page 47 of Managing to Learn.

Quoting from the books:

  1. Why did the machine stop?
    There was an overload and the fuse blew.
  2. Why was there an overload?
    The bearing was not sufficiently lubricated.
  3. Why was it not lubricated sufficiently?
    The lubrication pump was not working sufficiently.
  4. Why was it not pumping sufficiently?
    The shaft of the pump was warn and rattling.
  5. Why was the shaft worn out?
    There was no strainer attached, and metal scrap got in.

The conclusion is that the lack of a strainer is the root cause of the machine stoppage. (“For the want of a nail…“)

This line of thinking is all well and good after the chain is understood. Unfortunately it gives the impression that the root cause of a problem can be reached simply by repeatedly asking “Why?” and writing down the answers. I know this because I have personally experienced well-meaning-but-ignorant consultants who have done exactly that on a flip chart with a team trying to solve a problem.

I have heard “Just ask why five times” as a method, proposed in contrast to more rigorous methods.

It ain’t that simple, folks.

Let’s look at this example.

Why did the machine stop? What I know right now is that the machine isn’t running. Although I can get to the “blown fuse” fairly quickly, let’s not confuse the first or second thing I would check with a process of systematically eliminating other possibilities. The simple fact is that I would check the fuse fairly quickly because I can’t check everything at once, and because I am going to check things more-or-less in order of simplicity. But I am systematically ruling out loss of power at the feed, a physical problem (such as a broken connection), a problem in the control circuitry, and a host of other possible issues. In short, I must investigate a “loss of electrical power” until I reach the conclusion that it is a blown fuse.

Ohno skips a bit by going directly to the cause of the blown fuse as an overload, but it is going to take a little more investigation to get to that conclusion. Coming forward a few decades from when that book was written, I would probably reset the breaker and see if it trips again. But even then, I haven’t ruled out a bad fuse / breaker. Determining, for sure, that it is an overload condition is going to take a little more troubleshooting. A multi-meter would be much more useful than a flip chart at this point.

Once I am pretty certain I am dealing with an overload condition, then I can ask what is causing it.

Why was there an overload? Well lots of things can cause an overload. Something is putting drag on this notional motor. Maybe it was a bearing problem in the motor. Maybe a bearing elsewhere. Maybe a gear has locked up. Is this even an overloaded motor? Or is it an overloaded circuit? Eventually, after systematically checking and testing, I find the bad bearing. Now – Why did the bearing fail? How do I know it is lack of lubrication? Hopefully it is obvious, but there may be some other things I need to look at. Is there a flow of lubricant into the bearing? If that is normal, I need to look elsewhere. But there is not a normal flow of lubricant, so for now I can reasonably assume that lubrication is the problem.

Why was it not lubricated sufficiently? If the lubricant is not reaching the bearing, Why is there insufficient lubricant flow?

Is the sump dry? Is the intake clear? Is the line kinked, clogged or leaking? Is it clear? How do I know? As I work my way upstream, physically checking, I’ll eventually reach the pump that is complaining.

Why was it not pumping sufficiently? At this point, I am probably replacing the pump. But why the pump failed in the first place is a reasonable question to be asking. And only upon physical examination of the old pump am I going to find the worn and rattling shaft. But I am curious, so I look rather than just scrapping the pump and replacing it.

Why was the shaft worn out? Because the scope of investigation is narrowing, things get a little easier. Taking the old pump apart is going to reveal that the shaft is bound up with metal scrap. That takes me through a few more “Why?” questions – how could this get in here? And that is the point where I see no strainer on the intake.

Now, obviously, I made all of this up. But here is my point:

We, the teachers of others, do our students a major disservice when we over-simplify things. “Ask why five times” is very easy for people to take it out of context and try to apply literally. Unless the problem is very simple, it just doesn’t work, and that leaves them:

  • Frustrated.
  • (Correctly) believing that anyone who thinks the real world is this simple has never had to deal with it.

Ohno certainly dealt in the real world. He also uses metaphors. We should caution ourselves not to take everything as 100% literal. Ohno’s point is summed up in the last paragraph of this section of his book on page 18 when he concludes:

In a production plant operation, data are highly regarded — but I consider facts to be even more important. When a problem arises, if our search for the cause is not thorough, the actions taken can be out of focus. That is why we repeatedly ask why. This is the scientific basis of the Toyota system.  [emphasis added]

The scientific method generates understanding through repeated hypothesis testing. A scientist ask “Why?” then fits a possible answer to the facts as he understands them and then asks “What else would be true if I am right?” and builds an experiment (or investigates) to verify, or refute, his thinking. This is how to ask “Why” and this is what you should do five times.