Category: Problem Solving

Posted on

5S in Three Bullets

I was in a conversation today and we ended up boiling 5S down to three key points:

  • You have everything you need.
  • You need everything you have.
  • You can see everything clearly belongs where it is.

Of course at the next level, these statements are the standards you are continuously checking against.

Presumably we have cleared out everything else, leaving only what we thought was needed, and established visual controls to verify we have those things, and only those things, in the work area.

Then, as the work is done, the moment someone discovers something else is needed, THAT is the time to deal with the issue.

– Ask “Is this something we should need in the normal course of the work?”

If so, then you learned something that you didn’t know or didn’t remember when you first organized the area. Add that item, find a place for it, and establish a visual control. Right now.

If not, then “Why did we need it this time?”

What broke the normal pattern of work?

This is where 5S breaks down – when we don’t discriminate between something that is needed in the normal course of work, and something that is needed as an exception.

If we just “get it” and add it to the work area, then we normalize deviance and incrementally erode the process. If we ignore the issue, we add “getting this when it is needed” to the work cycle.

If, on the other hand, we seek to understand what broke the normal pattern and deal with the core issue, we have a shot at real kaizen. (It is perfectly OK to get what you need and keep it around as a temporary countermeasure. Just put it someplace where you will KNOW when you used it.)

The worst thing you can do is allow these small problems to accumulate and try to correct them en-mass as some kind of “corrective action.”

Kanban

Likewise, kanban can be expressed the same way. It is more dynamic, but is really answering the same questions in the context of materials.

 

Standard Work

If you paraphrase these key points to just about any other “tool of lean” then the purpose of surfacing problems and driving solution becomes apparent.

  • You are doing everything that is required.
  • Everything being done is required.
  • Everything being done clearly is part of the sequence.

Take a look at the other classic “tools of lean.” How would they fit into the same pattern?

 

Posted on

3P Works

I am in another 3P type of event this week.
One of the cool things is how the act of physical simulation, even a crude one, drives out ideas and insights.

Limitations are challenged, possibilities are expanded.

Posted on

Pushing Innovation

3P – the Production Preparation Process – is often used to develop a complete “reboot” of a process. The term kaikaku is often applied.

Like many of the lean tools, subtle points sometimes get lost in rote application.

Here are a couple of thoughts from some experience:

Developing and Exploring Target Conditions

One of the obvious characteristics of 3P in its early stages is mock-ups of the product and processes. The purpose of these mock-ups is to explore various concepts, gain understanding, surface and propose solutions to problems before anything expensive is actually built.

The result of this process is a fairly well defined target condition.

That is, we understand the performance the product, and the process, must deliver in order to meet the goal. And we know what they need to look like in order to meet those goals.

The mock-ups give much more definition to “how the process needs to work” than any sketch or CAD drawing can provide. They give the team confidence that, at the minimum, they understand what problems must be solved to turn this proposal into reality.

As the 3P continues, these mock-ups should be morphing into functioning prototypes, and finally into full-scale production. At each step there should be a verification that the team is converging onto the goal.

Any time there is divergence from the goal is time to symbolically pull the andon, huddle, reset to a known point, and reestablish a track to success.

Keeping the Solution Space as Wide as Possible

One common mistake that teams make is to focus too quickly on a single solution. This is a result of trying to quickly solve the “big problem” rather than seeking first to gain much deeper understanding.

The evaluation process is not about picking winners. The goal in 3P is to keep as many viable solutions in play for as long as possible.

At each iteration of exploration the team learns what problem must be solved next to keep this solution alive. If that problem seems too big and overwhelming, you are likely working on more than one thing. Time to decompose the process to its basic elements (again) and tackle things one-by-one.

Plan B

While you are exploring alternatives, you always want to have something in your hip pocket that will, as a minimum, work. It might not be elegant, as cheap as you want, but it delivers. Having a viable Plan B in play gives the rest of the team much more freedom to push the envelope and explore.

The Plan B team is working continuously to improve from the baseline. Often they can develop some quite radical improvements. But they always start from something that works.

The beauty of this approach is that elements of the true innovation teams’ work can often be incorporated back into the baseline for even higher performance of the baseline.

Posted on

Standard Problem Solving

A key point of Mike Rother’s book Toyota Kata is that the organization develops a very deep core-competency in problem solving.

In order to develop competency at anything, there must first be a standard to strive for. What I am realizing is the precise method used doesn’t matter nearly as much as having a method (that works) and rigorously striving to follow it.

Why is this important?

Consider the opposite. Let’s say, hypothetically, that we have a team of very good problem solvers and they are trying to tackle a tough problem. However each of these people brings a different method to the table.

As they discuss the problem, each will be trying to frame it in his or her paradigm for how to go about arriving at the root cause and finding a countermeasure. Indeed, even those words (root cause, countermeasure) might be different.

Some of them might not even call it a “problem.” A team member steeped in Theory of Constraints is going to be referring to a “constraint” – what is constraining the system from advancing to the next level of performance.

Someone else will insist on calling it an “opportunity.”

No matter how competent each individual team member, the group is going to expend a lot of time and energy with how to go about even defining the problem. This is time and energy that is not spent actually solving it.

Things get worse if there are weak problem solving skills to begin with. Someone might have heard of “5 Why’s” for example, and try simply asking “Why?” repeatedly, and writing down the answers on the flip chart in a mistaken belief that this effort leads the team to the root cause of the problem. (it doesn’t, as the room is hermetically sealed to information flow).

So if the organization has a structure, a method, for problem solving there are at least steps that should be consistently followed.

Introduce a good facilitator / teacher / mentor into the mix, and they get an opportunity to practice with coaching, and develop skill.

But “without a standard, there can be no improvement” and the same thing applies to problem solving and improvement itself. If you want to get better at it, you need to start with a standard you are striving to achieve, and then study what keeps you from achieving it.

Posted on

The Report-Out

The classic one-week kaizen event ends with a report-out by the team that outlines the improvements they have made, and the results they have achieved.

Actual results, though, are notorious for falling short of what was reported. Action items are left over, and things frequently peter out unless there is a huge effort to force sustainment.

Let’s look at this a little differently.

Typically what happens during the kaizen week is that a new process is designed, and some things are put into place to enable it – point of use, rearranging things for flow, etc.

The report out is describing expected results, and how the process must operate to deliver them.

In other words, a very common outcome of a kaizen event is a pretty well thought out target condition. This is how we want the process to operate, this is the result we are going to strive to achieve. It is all future tense.

What happens next will make or break things.

The next question that should be asked is “Great! When are you going to try it, and what do you expect to learn?” If the report-out does not directly address this question, then you can expect the typical result – steady erosion.

In fact, the process of seeing and addressing those problems must be embedded into the daily management process itself.

The report-out is the beginning of kaizen, not the end. The next phase is not “follow-up.” It is a natural continuation, if less intense, of the kaizen process. The report-out is describing an engineering prototype. Now it is time to test it and discover what we didn’t know during the design process.

 

Posted on

Firefighting Kata

27 months ago I wrote a piece about a “firefighting culture” where I described the actual process used to fight fires – following PDCA.

I have learned a few things since then, and I want to tighten my analogy a bit.

What is the core thinking behind true firefighting? This is actually closer to home than you may think. Many companies have situations that are on fire – in that they are destructively out of control.

I recall Mr. Iwata lecturing a group of managers in a large aerospace company in Seattle. He listened patiently to their grand plans about how the transformed operation would look. Then his remarks cut to the chase.

“Your house is on fire. This is not the time to be thinking about how you will decorate it.”

The question is – does urgency force a change in the thinking or approach?

I say it does not. However urgency does stress people’s skills and capabilities to deal with the situation to the limit – and beyond. Thus, it is best if those skills are thoroughly developed before there is a crisis, when the stakes are not so high. This is how high-risk professions train. They work to develop ingrained habits and skills for handling chaos before it is real.

So let’s go to our hypothetical burning building and look at what happens – as a matter of routine – even though every situation is different.

The target condition is a generally a given: The fire is extinguished, things are cooled down enough that there will be no re-ignition.

What is the current condition? Yes, the building is on fire. (doh!) But there is more to it than that.

What is stopping us from putting this fire out right now?

What is the layout of the building? Its construction? Where are the air shafts, sources of fuel, oxygen? Are there hazards in the building? Is there a basement under the main floor? Is there anyone inside?

Because they are (hopefully) skilled and practiced, gaining this information is routine, and hopefully they are getting most of it on the way.

The fire chief on site is going to develop an overall strategy for attacking the fire, and deploy his forces accordingly.

One thing they do not do – they don’t go creating action item lists, they don’t go hunting for fires, and they don’t just go into reaction mode.

Neither do they have a detailed “action plan” that they can blindly follow. Simply put, they are in an vague situation with many things that are still not known. These things will only be revealed as they progress.

What is the first problem?

The initial actions will be more or less routine things that help the effort, and gain more information. They are going to ventilate the roof to clear smoke, and they are going to first work to rescue any people who are trapped.

This is their initial tactical target condition.

As they move toward that target, they will simultaneously gain more knowledge about the situation, decide the next objective, and the actions required to achieve it.

Cycle PDCA

As they carry out those actions, either things will work as predicted, and the objective will be achieved or (more likely) there will be surprises. Those surprises are not failures, rather they are additional information, things that were not previously understood.

Because this is dangerous work, if things get totally strange, they are going to back-out and reassess, and possibly start over.

As they go, they will work methodically but quickly, step by step, never leaving fire (unsolved problems) behind them, always having an escape path.

And, at some point along the way, what must be done to accomplish the original objective, put out the last of the fire will be come apparent.

Why are they so good at this?

Simple. They practice these things all of the time, under constant critical eyes of trainers. Every error and mistake is called out, corrected, and the action is repeated until they routinely get it right. Even though they are very good at what they do, they know two things:

  1. They can get better.
  2. Their skills are perishable.

So, although each fire is different, they have kata that they practice, continuously – from basic drills to training in more complex scenarios. They are putting these things to use now that there is real urgency.

What about the rest of us?

In business, we tend to assume that crisis will either not occur, or when it does will be within our domain of being able to handle it… but we often get surprised and our problem solving skills are stretched to the breaking point.

Why?

Because we have never really practiced those skills, and if we have, we have not been critical enough of how we went about solving routine problems, and we are sloppy.

When there is no urgency, we can get away with being sloppy. When method is not critical, anything more or less works. But when things are complicated, messy, and right now, there isn’t time to practice. “You go to war with what you’ve got.” What that really means is that, however ill-prepared you are, you now have to deal with reality.

Problem solving is as important to a business (and I include any human enterprise, profit or not in this) as it is to the firefighters. Business has technical skills, as firefighters have handling hoses, operating their equipment, etc. But no matter how competent firefighters are at their technical tools, they are lousy firefighters if they have not practiced quickly solving problems related to putting out fires.

Likewise, no matter how good you are at keeping your books straight, managing your order base, scheduling production, whatever routine things you do, if you have not practiced problem solving skills on a daily basis, you are likely not very good at it. Daily kaizen is practice solving problems. The side-benefit is your business gets better as a result.

The difference is that firefighters know it is important, so they practice, subject themselves to the critical eye of professional trainers and coaches. In business, nobody teaches “problem solving” except in the most vague way.

 

“All we do is fight fires.”

Hopefully you wish you were that good.

Posted on

Coffee + Electrical Panels = 7500

A reader, Josh, sent me this link.

Spilled coffee in 777 cockpit leads to inadvertent hijack warning, FAA-mandated sippy cups look likely

The more compete, technical version, is here.

The short version is:

  1. Airline pilot spills coffee on cockpit panel.
  2. Coffee (or scalded pilot) causes airplane to send out the HIJACK transponder code.
  3. Many people become involved quickly.
  4. Frankfurt bound plane returns diverts to Toronto, passengers are returned (it doesn’t say how) to Chicago, which the author considers a bad thing.

tippy-cup

Given that even highly improbable events are nearly certain given enough opportunities, I am actually rather surprised this hasn’t happened already, given the sheer number of opportunities calculated by (#flights x #pilots x #cups of coffee) over, say, a ten year period.

So, given that we have an undesirable outcome (though perhaps not quite as embarrassing as the .45 hole in the cockpit floor from a few years ago), what is the root cause, and what is the countermeasure?

Whatever we do, we should probably have it cost somewhat less than scrambling F-15’s to go ask what the problem is.

(Yes, I am being somewhat serious here, but also struggling just a little to keep a straight face.)

Many companies respond to a similar problem opportunity by banning drinks altogether in the work areas. My guess is that if we wanted to continue to have pilots operate the airplanes, we might consider something else.

f-15-sparrowI will leave my readers to ponder the thought, and remind you that there are worse outcomes than returning to Chicago via Toronto.

 

Posted on

Motivation, Bonuses and Key Performance Indicators

I have posted a few times about the “management by measurement” culture and how destructive it can be. This TED video by Daniel Pink adds some color to the conversation.

Simply put, while traditional “incentives” tend to work well when the task is rote and the solution is well understood, applying those same incentives to situations where creativity is required will reduce people’s performance.

We saw this in Ted Wujec’s Marshmallow Challenge video as well, where an incentive reduced the success rate of the teams to zero.

This time of year companies are typically reviewing their performance and setting goals and targets for next year.

It is important to keep in mind that there is overwhelming evidence that tying bonuses to key performance indicators is the a reliable way to reduce the performance of the company.

Posted on

Trusting the Process

Here is an “ah-ha” or even one of those “oh s#!&” moments I had as Mike Rother was talking about his Toyota Kata research last week.

  Solution How Solution is Developed
Toyota / “Lean” Left Open Very specific – guided and directed.
Traditional Management Given / Directed Not specified, left to “empowered” employee.

When confronted with a problem, “traditional” managers have been taught to direct a solution, and leave details of putting it into place unspecified – “empowering” people to find the best way to work the details, solve the problems, and get it done.

“Toyota” or “Lean” managers, on the other hand, (if they are following the kata model – rare outside of Toyota I think), are going to be quite open about the solution, but very specific about the method used to develop and deploy that solution.

The result?

The two populations learn quite different things.

One learns to bypass obstacles, put the directed solution into place quickly.. git-r-done.

The other learns, through repetition, a thorough, adaptable, reliable and universal process for diagnosing a situation, seeing the root cause, and developing countermeasures that sustain.

The line I circled in my notes is “Kata must be content free.” meaning that if the method is carried out correctly, the solution will work to deal with the issue at hand. It is not necessary to specify a solution, only to hold the “true north” of what constitutes improvement and ensure that the process to develop the solution is carried out correctly.

An unworkable solution is a sign that the problem solving process was not applied correctly, not a flaw in the process itself.

OK – that all sounds good. What is the “ah-ha?”

How have many of us been “implementing lean” and “engaging people” by giving them targets in the form of specific tools to implement, and then leaving it to the “engaged team” to work out the details of how it will function in their situation? Which of the above two models am I using if I do that?

If I were to set an appropriate target, that takes the process closer to one-by-one, etc. and then to correctly guide the team through the process of understanding the current state, evaluating what problem(s) are blocking progress in that position, and methodically solve them they might or might not arrive at the tool I have in mind as the answer. Just to be clear – this approach is a lot tougher because there is another skill involved than just knowing how to make kanban work, or set up a u-shaped work cell.

There is a fine line as well between giving the team the solution and advising them on some things to try that will help them reveal more issues.

But in the end, if their solution works to close the gap, but uses a totally different approach, I have to be open to that possibility.

We lean “experts” have to play by our own rulebook.

Otherwise I am simply holding a wrench and looking for a screw to pound.

Posted on

When Can I see?

One of the issues Mike Rother says he has had with the coaching questions in Toyota Kata is question #5 “When can we go see what you have learned?”

In the west, inevitably it seems, once the word “When” is uttered, everyone in the conversation leaps to hear “When will you be done?” no matter how the question is actually framed.

As I am understanding it right now, the actual intent is for the coach to establish two things:

  1. The PDCA cycle needs to be turned rapidly. “When…”? is meant to establish a time fame that might be measured in hours, or even minutes, rather than days or weeks. The more quickly the PDCA cycle is turned, the more thoroughly the problem is understood and the more robust the countermeasure.
  2. “What we have learned…” means “What surprises did you encounter?” “What went differently than you expected?” “What didn’t work the way you thought it would?” this part of the question is intended to drive home the point that it is these things, not the success, that drive deeper understanding plus give clues about the next problem that must be addressed.

Based on Rother’s experience with this question, I am tinkering with how to re-frame it so I can use it more effectively. Ultimately the behavior I want is an invitation to jointly observe how the proposed countermeasure has changed the process. We want to understand the actual effect vs the intended effect.

That, of course, requires that the intended effect is understood and explicitly stated before trying. That does NOT mean that every little step is documented on paper such as an A3. That is far too cumbersome at this level of granularity. We want this process to cycle faster than the time required to write this stuff down. It does mean that I would have evidence that it has been thought through rather than just blindly trying something.