Tag: 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

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.

Posted on

Pull as Kaizen

Michael Ballé’s recent Gemba Coach column drives home the importance of understanding that all of the so-called “tools of lean” are really there to drive problem solving.

A well designed kanban system is (or at least should be) built to not simply provide a pull signal, but more importantly, to continuously ask, and answer:

  • “What is supposed to be happening?” (what is the target condition?)
  • “What is actually happening” (what is the current condition?)

and give at least a hint of the problem that needs to be addressed right now when there is an issue. As a minimum, what condition must be addressed right now, and the first “Why? to be investigated.

A couple of months ago I posed a hypothetical question about a team’s effort to put in a kanban process and asked for your thoughts and comments.

The scenario I described was, with one or two trivial changes, copied directly from pages 48 and 49 of the Lean Enterprise Institute’s latest workbook, Creating a Lean Fulfillment Stream.

Although the process as described would likely work (at least for a few items), I was really surprised to see an LEI book describe a process that explicitly and deliberately breaks the “rules of kanban” that they have published elsewhere, particularly in Lean Lexicon. The LEI did not make up the rules of kanban, they have been well established for decades. Thus, I have to admit that my first response was to question the credibility of the entire book (Lean Fulfillment Stream), even though there are many things in it that are worthwhile.

Many of you correctly called out issues with the mechanics. Now, in light of this new information, I would again like to invite comment.

If a good process should be set up to continuously ask, and reveal the answers to, those two questions, where does this kanban scheme come up short?

How would those issues cause problems with the processes that Ballé is describing in his column?