Category: Problem Solving

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?

 

Posted on

If The Student Hasn’t Learned…

The teacher hasn’t taught.

This article, titled “Why China is Not Ready for Lean Manufacturing” presents an account of trying to teach “lean manufacturing” in a Chinese factory. The experience is summed up in a couple of key paragraphs:

The team arrived in Dongguan and went to work giving an overview class on Lean techniques. The factory workers seemed attentive and interested in learning. The next day, the Silicon Valley Lean team gathered the people from the assembly line to begin the process of working on the quality problem. After 3 hours, the Lean team ended the session in utter frustration. No one participated. No one would identify problems on the line. No one knew how to approach gathering or analyzing data. No one volunteered.

So what happened? The training was adequate and the Lean principles and methods are sound and easily understood. Why weren’t the Chinese factory workers participating?

Why indeed?

The author’s conclusion is that Chinese worker’s culture and values conflict with the idea of collaboration and contributing ideas to improve production quality and efficiency.

But the article brought up two separate thoughts.

First, there is nothing magic about Western culture. These concepts can, and do, fall just as flat in the USA and Europe as they did in this factory. The problem in these cases has less to do with the national culture, and more to do with attempting to apply a rote approach to teaching.

Second, the result cited here was exactly the opposite of my own experience in a Chinese factory.

It took some persistence, and it took some deliberate steps to remove fear from the factory floor, but in the end we had these Chinese workers making some very innovative contributions.

400ArmBoringMock01 This photo is an old boring mill. It was a slow old boring mill. We needed to squeeze cycle time out of the process to make the projected takt time. We showed the workers some photos of other teams’ efforts to mock-up fixtures so they could quickly try out ideas. The workers, after a few false starts, constructed what you see here, and ended up with a pretty good set of fixtures that could be loaded and unloaded quickly. After some trials, they figured out on their own that they could fit two fixtures on the platform, which allowed them to be unloading and loading one while boring on the other.

400BucketBoring

One of the machinists complained that the machine could run faster if it had a liquid cooling system. With encouragement, he designed and built a simple, but working, cooling system for the cutting tools. (The steel box in the foreground with a pump on it.) The clever part was the chip filter made from a bottle cap and a nail.

400BucketCellMock01 Another team was working on a welding cell. They ended up designing and fabricating more efficient fixtures than had been provided by the engineers. Then they set out to develop the most efficient way to get parts positioned, to load them quickly into the fixture, and weld up the part.

 

 

What was different?400CellWorkDesign

First, we didn’t do any classroom education. Not quite true. We showed them photos of really good welding fixtures that had been designed by a sister company. That took about 30 minutes. We explained what features made those fixtures good. Then we continuously encouraged them to try things so they could learn on their own. And try they did.

We didn’t ask them to go beyond mock-up. We fully expected to take their ideas, turn them over to engineers to get them finalized and drawn up, then have the fixtures fabricated. But the workers took it on their own initiative to dig through the (embarrassingly large) amount of scrap metal out back, bring in what they needed, machine parts, scrounge others, and built their fixtures in steel.

A number of ideas were things I could clearly see would not work. I knew that heat distortion from welding would make a particular fixture design difficult (impossible!) to unload after welding. I could tell them it wouldn’t work, or I could let them try it on their own. I chose the path that would engage their curiosity and let them learn through experience. They became better welders for it.

Honestly – this was a slow time while we were working out other issues with market positioning, sales, design and sourcing decisions, and most of this activity was intended to keep people busy and engaged. But what we ended up with was production-ready work cells, all built upon ideas from the workers.

So why did I tell this little story?

First, I will admit that I was pretty proud of these guys. This was a few years ago now, but it was fun blowing away everyone’s stereotypes about Chinese factories and Chinese workers.

But I wanted to make a key point.

Instead of looking for cultural reasons why “this won’t work here” we kept faith that, if the initial response was silence and non-participation, there was something that we needed to address in the way we taught, and in the environment we were creating.

Indeed, what the Chinese culture brings to kaizen is a centuries-old tradition of improvising with what you have to get something done. This is a great strength that can be hard to find in cultures with longer traditions of wealth.

Just as we were encouraging these workers to try things so they could learn what did work, we had to do the same thing. We didn’t give up after three hours. Eventually we managed to remove the fear and bring out the best these people had to offer.

Classroom education is actually a very poor way to teach people how to study a process, understand it and improve it. Sometimes it kind of works, but I think that is because it is marginally effective if all of the other conditions are right. Perhaps in some cultures that starting point is past the limit of what classroom education can handle. That isn’t a problem with the culture, it is revealing the inherent weakness in the approach.

There is no cookbook. There is only a clear objective, and good faith effort to keep trying until a solution is found.

Epiloge: Yes, this factory got into production. However the parent company could never get traction in this market with this product and recently made a decision to close this plant and pursue a different strategic direction. That is not a reflection at all on the people who did the work in these photos.

Posted on

“Opportunities” vs “Problems”

Over the decades, I have observed that it is quite common for organizational leaders to try to use the word “opportunity” when talking about a problem.

I can understand the desire to do this – we typically think of “problems” as something to do with people.

But I find the emphamistic language… problematic.

 

 

Mr. Opportunity

 

There is a Honda marketing campaign in the USA that features a cartoon character named “Mr. Opportunity.” His tag-line is “I’m Mr. Opportunity, and I’m knocking.” The opportunity is an invitation to take advantage of discounted prices for Honda cars.

Words mean things.

An opportunity is something that I may, or may not, decide to pursue.

But in lean thinking, no problem can go unaddressed.

Rather than a friendly cartoon character knocking on your door, a problem has kicked your door in and is standing in your living room. It must be dealt with, and dealt with quickly.

It has to be contained, pushed back, and finally resolved to keep it from getting back in.

IF the process for doing these things is carried out correctly, there are opportunities for the organization to learn along the way. But in the vast majority of cases, the only way those opportunites get exploited is if the leaders insist on hearing what was learned. So even those “opportunities” shift to imperatives.

Friendly euphemism that soften the urgency do not help us. If we are to have a true problem solving culture, we have to be willing to call things what they actually are.