Posts

Posted on

Simple and Easy Processes

In the last post I commented on Ron Popeil’s product development approach – to make the product easy to demonstrate drives making it easy to use, which creates more value for the customer.

Let’s take the same thinking back to your internal customers.

What if, rather than just writing a procedure, you had to go and demonstrate it to the people who had to follow it? What if you had to demonstrate it well enough that they saw the benefit of doing it that way, and could demonstrate it back to you to confirm that they understood it? If you broke down the work and organized it to be easy to demonstrate and teach, would it look any different? (Hmmm. TWI Job Instruction actually sounds a lot like this.) Would you still ask “Why didn’t they just follow the procedure?”

Look at the information displays and the controls on your equipment. Do they provide total transparency that things are working? Or do they abstract and obscure reality in some way? Can your internal customer be sure things are going as expected?

Do controls give clear feedback that they are being set correctly? Are sequences of operations readily apparent?

How many “blinking 12:00” situations do you have out there on your shop floor – things that have been put into place, but nobody uses because nobody can really figure it out?

Come back to the design of the product itself. Is the manufacturing and assembly process apparent, obvious, and as simple as you can make it? Would it be designed differently if you had to demonstrate how to fabricate and assemble it?

How about your administrative processes? I recall, many years ago, a “process documentation process” being taught. In the class they were using “baking cookies” as a demonstration example. Yet the instructors, who presumably were experts, actually struggled trying to show how this works. This “process” was far less clear than they had thought it was when they had simply thought through it. “It did not work on TV.”

Look at your computer programs and their user interfaces. What makes sense to a programmer rarely makes sense in actual use. Watch over someone’s shoulder for a while. Could you easily demonstrate this process to someone else?

Ron Popeil cooks real chickens and real ribs in the production of his infomercials. He does not use contrived or carefully limited demonstration examples. As you look at your examples and exercises, how well do they stand up to the real world application? Can you go out to the shop floor and demonstrate your “product” in actual use?

This post is full of questions, not answers. I don’t have the answers. Only you (can) know how well your processes are engineered.

Design your production system (for product or service) as carefully as you would design the product or service itself.

Posted on

Developing Products to Create Value

I am reading Malcom Gladwell’s somewhat new book What the Dog Saw. It is an anthology of articles he has written for New Yorker magazine over the last few years.

The first chapter is about Ron Popeil, the icon of infomercials and “Set it… and Forget it.” Gladwell describes a fascinating product development slant – make the product easy to demonstrate. In making it easy to demonstrate, its benefits must be obvious. Its features must make it easy to use and simple. Complexity just does not cut it. And it must work, right out there in the open.

The chapter spends a lot of time on the Showtime Rotisserie. In the sales presentation, it is the product, not the salesman, who is made the center of attention. What it can do for you, how easy it is to use, and how it functions. The front is transparent, and angled so the customer can see the product work, in use (and during a demonstration on TV). The controls are simple enough that he can say “Set it… and forget it.” It is engineered (and was re-engineered in development) to prepare visually appealing perfectly cooked food. As it was being designed, it was continuously being used as it would be in a demonstration – the pitch and the product were developed simultaneously.

Because I love examples of opposites, this is the part that really drove the difference home for me:

If Ron [Popeil] had been the one to introduce the VCR, in other words he would not simply have sold it… He would have changed the VCR itself, so that it made sense in an infomercial. The clock, for example, wouldn’t be digital. (The haplessly blinking unset clock has, of course, become a symbol of frustration.) The tape wouldn’t be inserted behind a hidden door – it would be out in plan view, just like the chicken in the rotisserie, so that if it was recording you could see the spools turn. The controls wouldn’t be discrete buttons; they would be large, and they would make a reassuring click as they were pushed up and down, and each step in the taping process would be identified with a big, obvious numeral so that you could set it and forget it. And would it be a slender black, low profile box? Of course not. Ours is a culture in which the term “black box” is synonymous with incomprehensibility. Ron’s VCR would be in red-and-white plastic, both opaque and transparent, or maybe 364 Alcoa aluminum, painted in some bold primary color, and it would sit on top of the television, not below it, so that when your neighbor or your friend came over he would spot it immediately and say “Wow, you have on of those Ronco Tape-O-Matics!”

All of this is about creating value for the customer – value that, in the customer’s mind, exceeds “four easy payments of $39.95.” When that happens, the customer buys the product.

We spend a lot of time thinking about how well manufacturing and supply chain issues are taken into account during product development. But just as important is he customer interface.

Take a look at your product development process. How involved are the people who have to sell it? How involved are customers and users who have to use it, maintain it? Do they get to try out their processes on your prototypes as you go? Or are specifications just tossed over the fence for engineers to figure out and turn into what they think is the ideal product?

Posted on

Customer Service Opportunities

Today was traveling on behest of a large corporation, so the travel arrangements were made through them. It all went about as routinely as could be expected on the last weekend before Christmas… for me.

Unfortunately the guy I am supposed to meet here had flights going through D.C. that were on a collision trajectory with a snow storm on the east coast today. Flight cancelled.

OK, I need to continue on, then shift my departure out 24 hours – hang around here another day.

Fortunately at the bottom of the itinerary emailed by the corporate travel company is the handy “In case of problems” etc. phone number:

CONTACT xxx TRAVEL 1-800-3xx-xxxx

So I call the number.

A couple of layers of voice menu prompts (including a reminder that airlines are implementing luggage policies, please check your airline’s web site – totally useless information that only delays the response I am trying to get), I end up with the “hold music” being reminded periodically that “Your call is important to us…” etc.

A human comes on the line and I am cheerfully informed that this is not the 800 number I should call. I am reminded that MY reservation was made through the online system (which it was not, I talked to a human being when I made it), and that I need to call “them.” And, kindly, I am forwarded to “them.”

After 20 minutes of hold music, my plane is boarding, so I have to drop the call.

Try again from the seat.

Different initial operator who makes a little more effort to make me wrong for calling the ONLY number that they print on the itinerary they send, otherwise same result. They are closing the cabin door, I have to drop the call.

There actually is a lesson here.

What defines how well a process or system works is not so much the individual components, but the interfaces between them. In this case the “interface,” if you can call it that, is the hapless (and irritated) customer. I am the one who has to integrate various otherwise separate components of this fractured process.

The other story is the reason they were likely so busy today. After all, a major snow storm socked the east coast and caused havoc in the flight schedules that went through there. I am sure there were plenty of people who were impacted, and calling them for assistance re-booking flights, etc. And after all, there really is no way to predict when that will happen so they could be prepared, right? The really cool thing about 21st century communications technology is that you can can not only monitor live weather conditions and radar in real time, if you need to react, “extra people” don’t even need to leave home to be available… they don’t even need to be in the same state or even country. It is possible to plan and prepare for extraordinary mind-boggling never-forget-it customer service, if it is important to you.

In the end, it is about making a conscious decision about the experience you really want your customer to have, and then structuring your processes, deliberately, to deliver that experience – and be sensitive and alert you when they do not. It is not that big a shift from “serving customers” to “customer service,” nor does it cost more in the long haul. “Quality is free” – if you understand how to do it.

Posted on

TheLeanEdge.org

Michael Ballé made me aware of a new site, http://theleanedge.org, that he has started.

Its tagline is “a site for lean dialogue with the authors.”

He has assembled a panel of some of the most prominent names in the field including:

  • Michael Ballé
  • Art Smalley
  • Jeff Liker
  • Mike Rother
  • Robert Austin

where they are discussing issues and answering questions.

It is just getting started, but I think it is going to be a great resource for the community. You can’t go wrong reading what these people have to say.

Posted on

I.E. and Kaizen

There is an interesting thread developing on the NWLEAN discussion group. Kris Hallan, a regular reader here, asked a great question about the contributions of the industrial engineering pioneers to what, today, we regard as “lean production.”

This, in turn, sparked some debate about whether Taylor, the Glibreths, and others were actually following lean methods; about whether traditional industrial engineering is bogged down in over analysis, and a host of other issues.

Because not all you are following NWLEAN, I wanted to share my thoughts here as well.

The pioneers all did very good work advancing the field of knowledge.

The Gilbreths, for example, are credited with the realization that “time is the shadow of motion.”

Ohno and Toyoda were both adamant that everything they applied to build cars was simply an extension of what they saw at the Rouge plant.

The neat thing about knowledge and technology is that each generation has an opportunity to build on the last. Sometimes this is incremental, sometimes it is a profound shift. But in either case, it is the previous work that establishes the foundation – either something to extend, or a refutable hypothesis to test and reject.

If I really look at the shift that separates traditional I.E. from the more modern approach, it is in who holds the knowledge of the process AND how to improve it.

Taylor separated thinking about the process from determining the best way to perform it. He (and the Gilbreths) learned to observe with a keen eye, and optimize the motions he saw. Great stuff. Nobody did that before. Everything we do today is built on that foundation.

Today I see two levels of lean practice.

The first, and far more common, is the “outside expert” – the kaizen workshop leader, for example. In this model, this expert comes from outside the actual process. He acknowledges that the people doing the work probably know the best way to do it. But the work of exactly HOW to improve things – the magic of kaizen if you were, belongs to the expert. He is the one who facilitates improvements. While “process improvement” is the domain of the people doing the work, the “process of improvement” is owned by the outside expert.

So the skill of “improvement” is separate from the skill of “doing the work.”

I see this all of the time. Its dark side is manifested in “How do I make them follow standard work?” as if that is even possible through coercion or some punishment/reward system.

This is really an extension of the Taylor model of separating “thinking” and “doing.” In this case, however, it is “thinking about how improvement should be done” and “doing the improvements” vs. the work itself.

But something slightly different is happening in the organizations I see pulling ahead.

In those, the “skill of how to improve” is also manifested in the people doing the work. “Improvement” is part of that work itself, not something separate. There is time and resource specifically allocated to it, just as there is for production. EVERYBODY is focused on not only making improvements, but also improving how they do improvements themselves.

To the outside observer, the difference in the teaching and implementation processes are very subtle. But the difference in the culture and results that emerge can be profound.

The key difference is in letting go, finally, of the Taylor model and working to incorporate the knowledge and skill of process improvement into the entire organization – everybody – rather than keeping it in a small cadre.

I think this is one of the distinctions between a practitioner and a true sensei.

Posted on

10% Off Coupon from LEI

The Lean Enterprise Institute is offering 10% discounts in their book store, and is asking bloggers to pass that along. I am happy to do so.

To use it, people just go to the Lean Enterprise Institute’s online Store at  http://www.lean.org/Bookstore/ and enter THANKYOU09 in the discount code field at checkout. The offer is good through Jan 31, 2010.

As 2009 winds down, I look back at a year that presents me with many opportunities for reflection. I am working on a couple of posts as a result.

Thank you all for your gift of “listening.”

Mark

Posted on

Values Checklists

I am in the process of going through a lot of old files and filling up recycle bins. Most of this stuff was collected back in first half of the 1990’s when the world wide web was just gaining critical mass, and a half day on Alta Vista, or the brand new search engine, Google, turned up new stuff all of the time. It disappeared just as fast, so the rule was “if you want it, copy it.”

A lot of this material comes from the TQM community. But what struck me enough to sit down for a minute and write about is checklists that include values like “respect for people,” “openness and honesty” and “teamwork.”

This was an era when companies were creating “values statements” and publishing them.

Many of them followed by trying to measure compliance with those values, putting them in performance management reviews, etc.

Of course since the mid 1990’s we know better. . . don’t we?

Values are tricky things. Certainly if a company is sincerely trying to change its culture, the values are going to have to shift. The question I have is not whether this is true, but whether writing them down and trying to enforce them is an effective way to go about it.

Consider how a company with a long, entrenched culture of conflict avoidance is going to transition itself into one which truly respects people?

In a conflict avoidance culture, the people who are truly open and honest tend to ruffle feathers and find themselves in the “out” crowd, isolated in the eddies, and often are never told why.

The people who have flourished in that culture now are saying they want to change it.

Let’s assume that the handful of people at the top – whose behavior has likely been rewarded by promotion throughout their careers and possibly even molded the rest of the organization, can even see that they have not been respectful of people.

If they truly want to change the values of the organization, the only way I can see for this to happen is if they, personally, are totally open and honest that (1) What they have been doing is holding the company back, and is disrespectful of people; (2) They intend to change it starting today; and (3) Ask for help and support from others around them to make a personal change.

If these things don’e happen, then it really doesn’t matter what they put on the wall or say they want everyone else to do.

This is a tough one. It is what Peter Senge calls “personal mastery” and what Jim Collins talks about in “Level 5 Leadership.”

Honestly, I don’t think it is a hard prerequisite for a fair degree of success. I know a few companies who have done pretty will without ever addressing this issue.

But I also know they are hitting the limits of what they can accomplish. As I am someone who sees things in terms of their potential I just wanted to take a couple of minutes and toss this one out there for everyone to think about while we (in the USA at least) stuff ourselves with turkey.

Posted on

Grassroots Innovation: The 3rd Way

Grassroots Innovation: The 3rd Way.

Greg captures a concept in 183 words that entire books have utterly failed to explain.

When we are trying to solve a problem, there are always people involved. And people have positions, feelings, and are always emotionally tied to this-or-that outcome.

It is critically important to find “The 3rd Way” when working on a solution.

There is a great example of what Greg describes as “flight” starting in page 73 of John Shook’s book “Managing to Learn.”

Shook summarizes “The 3rd Way”:

. . . making good decisions required everyone’s complete commitment to dealing with harsh reality.

This produced yet another counter-intuitive aspect of A3 management: respect through conflict.

Organizations that confuse “nice-nice” with teamwork end up paralyzed and frozen in place the moment there is disagreement. No further intellectual growth appears, and they had better hope they are far enough ahead that their competitors won’t catch on.

I have already used more words talking about Greg’s post than he spent making it.

Posted on

Joe Friel’s Blog: Excellence

Joe Friel’s Blog: Excellence.

I’m a couple of months late picking this up (it was published in September, and reported by Greg Eisenbach with the observation that “nothing is listed about talent.” ). But I think it is relevant here because Joe Freil’s predictors of excellence in an athlete translate directly to business performance. Only the context is different.

Motivation – do you want it? The key words are:

This goes well beyond lip service to goals.

Yet, all too often in business, lip service goals are what we get. But organizations that are truly successful and it it for the long haul are motivated by something intrinsic, something more than the platitudes of “creating shareholder value” or other committee-created “vision statements.”

Discipline – a rare commodity in business. The discipline to understand the long-term vision and work incrementally to get there vs. chasing after the short-term gains is the first thing I think of. Even tougher is to demonstrate discipline when times are good. It is easy to hire like mad and sacrifice sustainable margins for short-term sales. It takes discipline to develop a long-term steady growth plan and stick to it.

Confidence – Although this is speculation on my part, I have developed a sense over the years that what we deem “management resistance to change” is actually a lack of confidence. Leaders, and the organization, are simply not capable of performing any better than they believe they can. When I really listen to the language of resistance, the things I hear most often are how “we are different” (or how the examples of excellence are different) in some way that justifies not doing any better than they are now. I have even seen this internally when one part of the company starts to out-perform the others. Even more incredible is the response to turn against the outlier and tear it down.

Focus – I am going to quote Joe Friel here, because I can’t think of a better way to say it.

This could also be called purpose; the athlete knows where he or she wants to go in the sport. Daily training is a purposeful activity that will lead to excellence. Each workout (and accompanying recovery) is a small building block that eventually results in excellence. But you have to take it one step at a time, which brings us to the last predictor, patience.

There are a number of analogies here. Purpose is the obvious one. “Daily training” to the athlete is the process of building, and sustaining, capability. At the pinnacle of “lean” are companies that look at everything they do as training to do it better the next time. They evaluate how they carry out their activities, and evaluate the results. They focus on excellence and, more importantly, they do it on purpose and with purpose.

When there are changes, there are recovery periods which are required for the organization to adjust. Unlike athletes, however, organizations are not limited by the physiology of the human body for adjustment. They can improve on it since their adjustment is mostly psychological and learning, not recovery of damaged tissue.

Patience – Our kaizen blitz culture has created an expectation of instant results. But the purpose of the kaizen event is practice – it is a workout so that people can get better at making improvements as part of their daily work. Impatience is a symptom of poor focus and lack of discipline.

Though this list is great, I want to add one more thing:

Accountability. This word, unfortunately, has a negative “blame and punishment” connotation today as in “hold them accountable.” But I don’t mean it in that way at all. When I say “accountability” I mean that people take personal, internal ownership of their own results. It is actually impossible to impose accountability on someone else. Rewards and punishments may influence behavior a little bit (though I think they just improve people’s skills at concealing things), but they have nothing at all to do with accountability.

You can see accountability when things have gone to hell in a handcart. One organization blames external forces beyond their control, and expects someone else to rescue them since “it wasn’t their fault.”

The accountable organization says “Obviously we need to improve more” and embraces their results, even if they were they were caused by events outside their control.

The difference is between an organization that chooses to be in control of its destiny vs. one which relies on luck, and entitlement to survive.

Posted on

A “Problems First” Culture

I will be the first to tell you that this is probably repetition of a fairly narrow theme you have seen here before. But I think of different ways to frame it, or get different thoughts, so I share them.

“Problems first” is one of the mantras used by Phil Jenkinson, the CEO character in The Lean Manager by Michael and Freddy Ballé. Now that I have had a few weeks to let it sink in and synthesize with my mental models, I am seeing a concept that is so fundamental I would think it would be hammered into students in every management and leadership course taught in the world.

Of course, though, it isn’t.

Instead it seems alien in most company cultures.

Yet without a “problems first” culture, the leaders really have no idea – none at all – what they should be focusing their attention on. How could they? They don’t know what their people are struggling with until it is too late. By that point, a small unresolved problem has grown to the point where it cannot possibly be ignored, and now it must be dealt with. Task teams are formed, initiatives are launched. Action item lists are made and presented every week, and after enormous expense and effort, the illusion of control is returned. And so many companies are run just like this.

I am pretty sure that anyone reading this knows exactly what this feels like. Let me call it a “hidden problems” culture for now. Maybe I will think of a better term later.

Enough about what it isn’t.

Ironically, a lot of companies in the pursuit of “being lean” actually go blindly through the motions of “problems first,” but so in a way that raises questions about their understanding of this concept.

Let’s look at a simple action item review at a staff meeting.

Typically it looks like this:

For each action, the responsible person reports on the status, whether or not it is “on time” (usually against an arbitrarily assigned due date), and any “problems.” The manager asks if any help is needed, and perhaps assigns more actions to someone else to assist.

One common management tool for these things is a “Stoplight Chart” where actions are assigned color codes of Green, Yellow, or Red, usually depending on progress against the deadline (how late they are).

Red items get the most attention in the meeting (as they should, more about that in a minute), but that attention is usually in the framework of review and reporting.

At the end of the meeting, the senior leader has a good feel for what is happening (or what is not happening).

Contrast this with a world-class automobile assembly line.

Just like the actions items, every task has a deadline. Only in this case, the timing is much tighter – measured in seconds, not days. The assembler knows that if he gets more than 3-4 seconds behind, for any reason at all, he cannot possibly catch up and complete the work cycle on time. He is going to be late.

He pulls the andon cord, to let the team leader know there is a problem.

Key Point: This is not a report of a problem. This is transfer of the problem. The assembler is responsible for carrying out the work as it is designed. If he can’t, for any reason, then exceptions are transferred to the team leader.

The team leader can deviate from the standard work sequence to complete the job, but not the timing. If he cannot clear the problem by the end of the takt cycle, that section of the line will stop, and the andon will go red.

This is not a report of a problem, this is transfer of the problem. The team leader is responsible for assuring the work can be completed within the takt time. If he can’t, for any reason, then exceptions are transferred to the supervisor.

The supervisor is now responsible for clearing the problem and getting things moving again. If he can’t, then within a few minutes, another section of the line will be stopped and the responsibility for clearing the problem transfers to the next level in the chain.

And so it continues.

Of course this increasing level of responsibility does not mean that the others walk away. They are clearly working very hard to get the problem cleared. But each level of escalation brings more resources to bear on the issue.

Note that I haven’t talked about root cause and problem solving yet. Although the escalation procedures are designed to help gain better understanding of the underlying cause, the first priority is to get the problem cleared so that production can resume without compromising safety or quality in any way.

There may be a temporary countermeasure put into place to do this – some short term action that, while it might introduce some extra resources into the process, allows safe, quality production to proceed long enough to get to the underlying cause. One test of understanding that cause can be to remove this temporary crutch and see what happens.

OK, back to the staff meeting.

What is different about that?

The main thing is that typically the problems are being reported, but not escalated. The responsible person may have to come with an action plan to clear the issue, but it is still Management by PowerPoint, and the senior leader’s role is approval vs. involvement. If the senior leader does become involved, it is often driven by a perception that the responsible person is incapable rather than a process of professional development.

What would this look like if it were managed exactly the same way as the assembly line?

What if that monthly review were treated the same as the fixed stop position?

A couple of ideas come to mind.

“Green” means “on track, as originally scheduled.”

“Yellow” means “behind, but we have a plan to get back to green.”

“Red” means behind, and we don’t know how we are going to recover.”

How would those meanings change the tenor of these meetings?

“Problems first” is more than just a discussion about problems. It is a culture that is focused on finding them, clearing them, and solving them, and doing so with the same priority that comes with production.