Plan vs. Actual -- Part 5

Plan vs. Actual—Part 5

Attention. It’s crucial. When we give attention to something, we start noticing it in other places. Have you ever shopped for a new (to you) vehicle, with a particular model in mind? And find that you then “see” that model frequently while on the road. Yeah, attention.

So, it is with my current attention on Plan-Do-Check-Act Cycle (PDCA), or Plan vs. Actual, that I start seeing it more. I gave a presentation on it last week to our entire staff and have been talking about it a lot.

And, this morning, I note that no less a light than Tom Peters writes a very concise (for him) piece on implementing after planning. Execution of the idea and its absolute criticality.

That’s where most of us live. Tom speaks strongly to the subject.

Go get something done today.

Plan vs. Actual -- Part 4

Plan vs. Actual--Part 4

"But I can't reach the kanban rack!"

“But I can’t reach the Kanban rack!”

In our Kaizen event earlier this morning, the team was clicking, creating some visible tools to manage a process that, due to its technical requirements, happens out of sight. The tools were wonderfully clear and simple, flowing from the team, implementable with electrical tape and magnetic clips.

With one exception.

One of our associates, a quiet woman of small stature, pointed out our initial proposed location of the kanban rack made for a difficult reach for her. I looked at the rest of our team…she was the only “vertically challenged” member of this particular kaizen team. Yet, without her comment, we would have plunked the rack 6-10 inches higher than where it ultimately landed.

Is 6-10 inches a big deal? Yes, it is, if it makes it difficult for an associate to do standard work easily or it adds a silly annoyance. And, had we not had a representative kaizen team, all of us taller members would have missed this.

Small things matter.

Seeing the familiar for the first time

Seeing the familiar for the first time

We kicked off a kaizen event this morning. After welcoming the participants, the kaizen leader pointed out that we always do kaizen events in the workplace, not in a conference room, because that’s where the operators and the ideas are.

As he talked, I looked around the group. Four of the six participants had been in kaizen events before but this was a new experience for the other two. And when he explained why we were in the workplace, the eyes of these two lit up, along with bright smiles and nodding heads. This resonated for them.

Watching their reaction was a marvelous reminder for me. It is a radical concept to most people that we would attempt to improve a process quickly and do so entirely in and at the workplace, with the people actually doing the work, while they are doing the work. It hit these two team members radically.

And positively.

I can’t forget the radical nature of the Lean paradigm. I can’t get too comfortable or cozy with it and forget just how drastic and far-reaching it is. It would be like visiting the Grand Canyon and blandly calling it a “large ditch.”

I hope you can have some sense of awe today. I sure did.

Plan vs. Actual -- Part 3

Plan vs. Actual—Part 3

So why does Plan vs. Actual work? Why is it imbedded in Lean applications so deeply we almost take it for granted?

Primarily, it is a simple application of the Plan-Do-Check-Act Cycle (PDCA) which is fundamental to Lean. In fact so fundamental, we have to remind ourselves of its profound impact from time to time. And is was in failing to either check or act that I botched it so badly, twice, this fall.

This reason Plan vs Actual works makes even more sense to me, though, when I examine it linguistically. In setting a plan, I make a declaration, naming a future state. By measuring the actual condition, I make an assertion, a statement of facts for which I am willing to provide evidence.

But it is in a third linguistic action that the power happens. It is when I make an assessment, an opinion based on a goal. And it is only in making powerful, well-grounded assessments that we trigger effective action, action that triggers a system of requests and promises.

It is in this system of five linguistic actions (declarations, assertions, assessments, requests, promises) that we flesh out lean leadership. We spend much of our time speaking. Do we do it effectively? I sure have botched it recently. I find going back to the basics very helpful.

I’m deeply grateful to my long-time friend Hal Macomber for originally putting me onto the work of Fernando Flores in this area. Hal has written much about a Language Action Perspective, of which I only scratch the surface here. It is not a well-known area but deserves attention in the nitty-gritty of a Lean implementation.

Plan vs. Actual -- Part 2

Plan vs. Actual – Part 2

My second big botch of this simple concept of Plan vs Actual occurred this fall in a financial setting.

We had a problem with one key manufacturing issue, which, fortunately, had a simple, reliable metric with which we could measure progress. I set out a plan and began to execute it. My measuring the input, I figured we were on our way towards the target.

What I failed to do was to calculate just long it would take to achieve the goal.

This is as if I had worked out a diet and exercise plan to lose one pound a week, yet never did the simple math to see how many weeks it would take me to get from 205 lbs to the desired 190 lbs.

Multiple weeks into the effort, a fellow manager asked me the obvious question: “Joe, if you are losing a pound a week and we’re 8 weeks into this, why do you still weigh 203 lbs?”

I never did the math. I didn’t watch the metric closely. I assumed I “knew” that the pound a week was coming off and everything else would be just fine.

As it turns out, the input was wrong. To continue the analogy, my weight loss system took off less than a half-pound a week, not a full pound. By not measuring it more frequently, I didn’t have the info that would have alerted me that something was wrong.

Pretty lousy performance. And looks even worse as I put it into black and white. I’ve thought a lot about it and have instituted some changes. I’ll write about that next time.

And, I hope you can learn a lesson from my mistake!!

Plan vs. Actual -- Part 1

Plan vs. Actual- Part 1

A common tool in Lean is to talk about “Plan vs. Actual.” While not exclusive to Lean, it is the simple concept of stating, ahead of time, what you think the outcome of a particular action or improvement will be. Then, you compare the actual with the plan. It is a great tool for learning, if used properly.

And I botched this in the last few weeks. Royally. Twice.

Earlier this fall, we ran into an unexpected production problem. (Come to think of it, that problem was the result of someone else NOT doing plan vs. actual…but that’s another story.) Fixing it required some new capital equipment. We worked very quickly through the specs of the equipment, got approval to spend the money, ordered it, pushed the vendor, set up the equipment, and started using it.

And it didn’t fix the problem.

The ultimate solution turned out to be in our hands already. It was a different, though lower-cost, capital improvement. We could have had THAT solution in hand weeks earlier. But we didn’t.

All because I didn’t force the plan vs. actual discussion early on.

This is a common story. You could say “Yeah, Joe, big deal, welcome to the real world.” But if every mistake is an opportunity to learn, we have to learn from this one.

In this case, I allowed others to force a technical assumption about the solution. In a spot where we needed some very specific technical information about an input to this piece of capital equipment, I accepted a vague statement. I did not press, asking “You say that input is fast enough. Just how many furlongs per fortnight can it go?” Had I demanded specificity about the one crucial parameter, we might have avoided the expense and loss of time and all the scrap we made in the interim.

Good leaders have an ability to distill a complex issue down to a few important questions. THEN, they actually ask those questions, to the right person, at the right time.

At least I learned from it.

A Rich Bouquet with Oak Undertones

A rich bouquet with oak undertones

Overproduction is one of the seven wastes. Seldom, though, does it make news. Until we recently learned a surplus spurs French to turn wine into disinfectant.

This made news because it involves wine, France and is humorous. Lest we laugh too heartily, though, let’s pause to consider the difficulty of avoiding this waste. Wine, good wine anyway, takes years to mature. This requires prediction of demand well ahead of the actual demand. In most of our situations, we seek to remedy this by leaving raw materials in the raw state as long as possible, then relentlessly shortening the production cycle to its minimum required time. In so doing, we minimize the criticality of accurate predictions. I have no idea how a wine maker (a maker of good wines, anyway) could avoid this need to predict.

Avoiding the need to predict is one way to prevent the waste of overproduction. It illustrates, wonderfully, how very interconnected all of our systems are.

"To me" or "with me"?

“To me” or “with me”?

We talk in Lean circles quite a bit about “going to gemba”, the workplace. Jeff Liker calls it “go and see for yourself.” And, on a very practical basis, it means physically moving to the place where associates do the work.

Why is this seemingly simple thing so effective? I’ve said for years, both to myself and to others, “Something good always happens when I walk through the workplace.” But it has nothing to do with me; I’m no vibrant, charismatic person, much more the opposite. But why?

Does “going to Gemba” work in a Lean system because it allows a manager and associates to make improvements “with” each other and not “at” each other?

A memo or email feels “from on high” to the associates who have to implement it. A conversation in the workplace, however, feels much more empathetic, doesn’t it?

Down with Philosophy

Down with the Philosophy

I wrote yesterday about how critical it is for me to know and practice a consistent philosophy of Lean. And today I write about how I can’t spend all my time thinking about the philosophy.

After my lunch last Wednesday with Kevin, I got back to work and did my daily walkthrough of our production areas. Within 5 seconds of entering one set of workstations, three associates simultaneously pointed their fingers at me and said “There he is. Get over here!” I wondered what I had done; their commanad allowed no option.

Turned out a persistent production problem was continuing, despite a change we had made the previous week. The group was frustrated and quickly vented to me.

“So, let’s change the setting again,” I said after hearing their observations. The chatter suddenly stopped; “Change it again? We just changed it.” “Yeah, but that change isn’t working,” I replied. “You just gave me solid data as proof. It seems to me our earlier change didn’t go far enough.”

We did some quick calculations, there at the work station, and estimated how much farther we had to change the setting to improve yield. The four of us agreed it seemed reasonable. I took on the task of doing the necessary paperwork. They agreed to do it when we returned from Thanksgiving holidays. We all agreed on the outcome metric that would tell us if the change was effective or not.

The entire discussion took maybe three minutes. No meetings. No task forces. No donuts. There was intensity. There was data. There was passion. There was honest speaking and listening. There were clear, verifiable promises.

In those three minutes, I contemplated pointing out to this group the philosophical underpinnings of what was going on. It happened in the workplace, in gemba. It was driven by data. It valued the ideas of those working with the product. It happened quickly. Indeed, I thought about all these things.

But I didn’t make any of those statements.

No customer buys a product from us because we are attempting to implement a Lean system. No distributor gets excited about our mistake-proofing systems. No end user cares that we make small changes, driven by associates.

They buy our product because it is available. They buy it because it meets their specifications. They buy it because it works. They buy it because it delivers financial value.

If I spend all my time thinking about Lean philosophy, I’ll never get the work done to implement Lean. And it is in these actions that Lean happens.

Long live the Philosophy. Down with the Philosophy.

Long Live the Philosophy

Long Live the Philosophy

Had lunch with a friend from our church last Wednesday. I was tardy and apologized to Kevin, blurting out my reason for being late; “I had to sort out a philosophical misunderstanding of our manufacturing system.”

Kevin looked dumfounded. “You mean you have a philosophy of manufacturing?”

I tried to explain briefly. And it got me thinking; why is it important to have a philosophical framework for manufacturing? Why this framework Jeff Liker calls The Toyota Way?

If I didn’t have a philosophy of process excellence, I’d have no way of making sense of the seemingly random events and stimuli that happen every day. I would never be able to exercise responsible leadership without a few key principles acting as anchors.

Thus, when I get a request, I ask myself; Does it contribute to single piece flow? Does it help mistake-proof? Does it decrease one or more of the seven wastes? Does it drive point speed or system speed? Does it conform with standard work? Does it help people speak and listen better?

A philosophy is the only way to make a system consistent. And is essential.

And it also has a downside. Listen more tomorrow.

Why Toyota? Why always Toyota?

Why Toyota? Why always Toyota?

I read with interest Mark Graban’s Lean Blog entry yesterday on No Satisfaction at Toyota, an article in Fast Company. It is a terrific article and I recommend it highly.

And it got me thinking; Why am I so fascinated by Toyota? Why does my benchmark always come back to this one company? Am I narrow? Envious? Participating in a fad? Why always Toyota?

Our neighbors and friends for many years have a son who is a very talented musician. He plays the bassoon. When he was in Junior High, we’d walk past the house and hear him in his room playing scales. First in one key. Then in the next step higher key. Then a step lower key. Up and down. Scales, scales, scales. Later we’d hear him work on a particular piece of music. Over and over, on the same few measures, getting it just right. On the bassoon, for heaven’s sake.

That Junior High kid is now in his mid 20s. He earned major scholarships to study bassoon in the US and in England. He now works with a major eastern symphony orchestra. Contrary to what one might take from my description above, he is a very well-rounded man. He is very personable, charming and has also found a gift in fund-raising for this orchestra.

He did this by paying attention to the most excellent bassoonists he could connect with. He and his parents sacrificed much to travel and study the best, with the best.

And in so doing, he nailed the basics. The scales. The bassoon repertoire. And he hasn’t quit. And he has a fascinating job in an arena he loves.

Yeah, that’s why Toyota. I’ve toured their plants, read all I can on them and I see the results of all their products. Further, Toyota is willing to share, much as some world-class bassoonists were willing to teach my neighbor.

I need not apologize for a fascination with Toyota, no more than my friend will apologize for learning from his teachers. The issue is not Toyota; it is in the pride I would exhibit to think I cannot learn from the best.

"Learning About Lean" takes a new direction

“Learning about Lean” takes a new direction

It has been over five months since I’ve posted to this blog. And now it is moving again. Here’s the scoop.

Through the late spring and summer, I went into the proverbial “writer’s block.” Not only was I phenomenally busy, I couldn’t come up with much to write about. Certainly nothing that struck me as interesting. And, if I couldn’t muster any enthusiasm, I was sure the boredom would come through in my writing. Waste, you know.

Recently, I had a new insight which got me back on track. I wrote the first entry to this blog in September, 2002. I intended to use the blog a mechanism to communicate with work colleagues and suppliers about basic Lean principles. Blogging was in its infancy at that time and there were few resources on the Web about Lean. Thus, it seemed like a good idea; educate and direct.

Four years and a major job change later, I see I can take a new direction with this blog. The educational hopes I had for this blog are now largely filled by other, more capable writers. Notable are the “Gang of Seven” writers I link to on the left side of this blog. These folks are outstanding thinkers and are worthy of your attention to learn about lean. And they regularly improve. For example, Mark Graban’s Lean Blog recently added a message board for discussions about Lean. Long-time blogging buddy Hal Macomber used his Reforming Project Management blog to write, live, from a recent Lean Construction conference.

With such excellent resources out there on the broad principles of Lean, I’m taking this blog to a more personal level. I’m deep into Lean every day and am responsible for implementing it in the very real world of a very real company. It is messy. We regularly see two steps forward and one (or three) steps backwards. We see people get it. We see hard work decimated by one silly decision. Yet, Lean never works if it only stays in the minds of the consultants and authors. Real people have to implement it in a real company. And I love what I do.

So I’ll write about my experience in doing just that. Much as one might write in a diary, I’ll try to describe what I see and feel in the grind of implementing Lean.

Thanks for coming along for the ride.

Missing in Action

Missing in Action

Had lunch today with a friend from our local Lean community.  His first comment was “Wow, I know you’ve been busy!”  I looked at Mike quizzically, not knowing him to be clairvoyant.  “You haven’t posted to your blog in over a month!!”

 

Mike is no fortuneteller but he can read a calendar.  Here's a quick update on what I'm "Learning About Lean".

 

I’m in one of the most exciting and exhausting phases of my professional career.  Our company is in a very rapid growth phase and it’s my job to ramp up the volume in a controlled and productive way.  One is lucky to ever see this type of growth once in a career; so I’m trying to grasp the moment, enjoy it and not be overwhelmed with the tasks. 

 

The past six weeks has been particularly busy.  Much hiring, training, orienting, teaching, coaching and, yes, some confrontation.  Yet the key team members grasp what we are trying to do and are doing a great job of fleshing out lean principles in the midst of the stress.  What do we see?

 

Pull systems work.  Way better than any predictive or anticipatory systems ever could.

 

Jidoka (error detection and correction at the point of origin) is a phenomenal tool.  Difficult to implement, particularly if others are in an “inspect-in-quality” style of thinking. And amazingly effective. 

 

Simplification focuses the mind. 

 

Measuring and observing constraints focuses the effort.

 

I’d love to promise I’ll write more.  But I’m not sure I’d deliver.  So, I’ll write when I can, when I have something to say. 

 

Thanks for hanging around.  I'm grateful Mike did. 

 

On Simplification

On Simplification

Tom Peters is one verbose guy…I’m astounded at the quantity of his blogging.  At times, I just start skimming when I sense he is typing, rather than writing.  

 

However, he had some substantial insight following a recent speaking trip to the heart of Russian Siberia, 4,000 miles East of Moscow.  The pithiest, to me, was:

 

There is a wretched tendency to keep complicating things, for the sake of self-amusement, to the point that the "eternal basics" disappear into the dust

 

Yes. 

 

When we gain knowledge in a specific area, such as Lean, we can forget the basics, finding them boring, and desire to complicate, adding topics, just because we can.  Just because it makes is more fun for us.  Self-absorption wins out over teaching and leading others.

 

A couple weeks ago, a speaker with TSSC addressed our local Lean Network.  And, for over two hours, talked about Standard Work.  One topic.  Deep.  Simple. Clear.  And she didn’t seem the least bit bored.  Not the least bit annoyed by our questions.  Her energy over the basics was palpable and inspiring. 

 

Peters captures it well.  Conquer a basic today.

 

 

Responding to Frank Patrick: Root Cause

Responding to Frank Patrick; Root Cause

Blogging Buddy Frank Patrick posed a question to me yesterday, based on a comment I posed to his assertion about understanding underpinnings last week. For those of you who find text full of links annoying, I’ll summarize in text.

Frank has a deep understanding of Theory of Constraints. I mean deep. And I learn from him regularly. Frank posited;

The Theory of Constraints Thinking Processes can be used to address this through the use of a Current Reality Tree to lay out the logical underpinnings that support or explain one's "perception of the world." This aspect of marketing runs parallel to the need, in any situation involving persuasion, to start from a point of "agreement about the problem."

So I asked Frank, via the comment, if he could explain more how he applies these powerful concepts in practice. I’m not that good at it; I’d benefit from Frank’s explanation.

What sits behind my request is one of the points of learning for me currently; how do we reliably and quickly describe the root cause of problems? The more I try to seek process excellence, the more I am aware of the need to find root cause. And the company that can consistently and quickly specify the core problem it faces will simply be more agile than competitors. And such an agility will be impossible for a competitor to identify, understand or replicate.

TOS’s Current Reality Tree is the most analytical and robust of the numerous methods of getting to root cause. I’ve used it several times. In each instance, it has led me to a very sound root cause, to which the solution became obvious. In each instance, I have been completely unable to communicate either the process or the result to others. The work and simple, logical elegance was for naught.

Frank, any help on implementation??

Queue's Cues

Queue’s Cues

Seth Godin is a terrific writer, one of my favorites.  He just put up Seth's Blog: Banging down the doors, which leads with this:

 

Finally, a sunny day. Did some errands, walked around the West Village and realized what a phenomenal cue queues provide. In other words, there must be a reason for that line.

 

Seth applied this to marketing.  It also applies to processes.

 

Any line, any queue, any pile of material or decisions or papers or emails is something with meaning.  There must be a reason for the line.

 

Virtually all lines indicate a loss of flow.  Something is stopped.  Waiting.  Sitting. 

 

And what is the reason? 

 

It is a great question; What is the cue in the queue?  There are seeds of improvement there, waiting to germinate.

 

 

 

 

Whadda ya do on a line stop...

Whadda ya do on a line stop...

...when all the right people are gone?

We had that experience today.

Our production team found a quality problem and stopped the line. Perfect. The signal went off. Perfect. They quickly detected the nature of the problem on a particular machine. Perfect.

Then, imperfection. The three people who could deal with the problem were gone, through a combination of vacations, travel and illness.

Quickly from perfection to panic.

I was in the middle of a significant meeting when an associate (correctly) interrupted to tell me the news of the problem and the absences. I suggested one other engineer in another department who MIGHT know how to fix the problem.

We all headed for the machine, on the floor. Three of us ended up there, none of us having the technical knowledge to bring the machine back to life. Yet production was shut down.

Chuck then went to the back of the machine, pulled up a stool and sat and looked. And looked. Then he called for us to do a test cycle from the front. Nothing. He sat and looked some more. Again the call. It worked.

Chuck came around to the front of the machine, laughing. "I fixed it. It'll stay fixed. Wanna see what I did?" By simply sitting and calmly looking at a bunch of wires and switches, he made sense. And saw one adjustment on a motor that had slowly vibrated loose. In the four years we've had this machine, this problem has never occured.

Chuck interrupted his work in an entirely different department to help us out. He didn't have to help, yet he did.

When we read the books on how to respond to a line stop, there are always people to respond. They hustle, fix the problem within one takt cycle or pull the offending unit off line. And then ride off into the sunset.

It doesn't always work that way. Like today. When trust and cooperation and just a can-do spirit has to prevail over the intended (perfect) problem solving paradigm. In a small company (and I suspect in large ones too) this is always a possible outcome.

People make systems work. And when the system breaks down, people still work. Building good relationships, broad shared objectives and a just plain likeable spirit is so key.

Chuck laughed as we headed out of production. "I'll send you my consulting invoice! A Dr. Pepper and some Jelly Bellies!"

Yeah, I picked those up on my way home tonight...they'll be waiting for him at his desk in the morning.

Waste in Bad Messaging

Waste in Bad Messaging

Whoa, a post from the missing-in-action Learning About Lean guy??  Yeah, I’m still here and working through an incredibly fascinating and hectic stage of growth.  I’ve simply not chosen to blog much in the face of major priorities.  But, I’m coming to the surface and will be back more now.

 

Two fellows I respect blogged yesterday on an important issue, triggering this post.

 

Hal Macomber writes on Explaining Misunderstanding.  Hal urges us to carefully consider how we communicate and not just blurt or act our way along. Instead, we need to both reflect and then be inquisitive, asking good questions to understand. 

 

Tom Peters writes on the odds of getting anything right.  Using the unlikely scenario of little-known George Mason getting to the finals of the NCAA Basketball tournament, Peters points out how each level of communication lowers the likelihood that we will achieve what we wanted to achieve. 

 

Taken together, with Tom arguing for decreasing the number of layers and Hal arguing for reflection and curiosity, here is a powerful argument for going directly to the people involved in a decision and then taking enough time to understand how a proposal comes across.  Most of us have to fight nature to do this…and it’s worth the fight.

 

Dude, you gotta understand waste better than that!

Dude, you gotta understand waste better than that!

Had a sales rep call on us last week with a proposed improvement to one of our processes. He was selling a motorized mechanism with specific attachments for certain products. Although his presentation was weak, we were able to ascertain eventually what he was offering and how it genuinely may be helpful to us.

At one point in the conversation, he stated fairly emphatically “I think this unit can really help you eliminate waste.”

Cool, I said, tell me how!

He stammered a bit, as if he didn’t quite understand my question. So I asked again, “There are multiple wastes, seven to be precise; which do you think you can reduce?”

After a blank stare for a few uncomfortable seconds, he began to talk about scrap. And indeed his unit could help in that regard. One of our engineers then asked about the changeover time for the various attachments.

He stammered a bit again and then told her “Oh, I’d allow about an hour to make the change.” Three of us gasped audibly. She pursued the questioning; “So, if you got good at it, how long would it take to swap the attachments?” The rep circled a bit and then said “Well, you really don’t want to change very often. Once you get it adjusted, you should run at least 500 parts.”

When I pointed out that one of the parts had an average weekly demand by our customers of about 50 parts, it was his turn to gasp audibly. I went back to the “waste” comment and said that we didn’t want to decrease the waste of quality to merely increase the waste of excess inventory.

This rep was a good man, had a good product and we may well use it. However, it was very clear that any drive for process excellence would be something we’d have to carry out on our own. This vendor didn’t have the ability to help us.

It also made me wonder how much better he and his company might do with a simple understanding of waste and of the principles of rapid change-over. The potential was there, yet it remains unrealized.

In a world where the contrast between process excellence and process mediocrity is becoming starker, how long can machine vendors avoid recognizing it??

What creates job dissatisfaction? You'd be surprised

What creates job dissatisfaction?  You'd be surprised

 

 

We interviewed a candidate for an open manufacturing position last week.  A very capable person and her comments were telling.

 

She took an "early retirement" offer from a major auto manufacturer recently, an effort at significantly downsizing the company.  We asked her about her experience at this firm and, in particular, what bothered her. 

 

She stated that her biggest struggle was the fact that line workers, such as her, were often forced to pass along a known defect.  Their team on the line badly wanted to produce product that conformed to specification.  Yet she was instructed, if she couldn't fix the problem as the line moved past her station, to say something to the next person downstream, and then carry on with the next car.  "We never knew if that problem got fixed or if it just ended up as the customer's annoyance," she told us with a frown.

 

She then turned the table and asked if we had a similar view of handling defects.  Imagine how thrilled I was when three of our manufacturing associates, part of the interview team, immediately and together enthusiastically told her "NO.  We don't pass along known errors.  We stop and fix it at that point." 

 

This issue of rapid error detection and correction is a matter of policy not technology.  When management decides it is good to do, the manufacturing team will do it, better than ever.  But the management walk and talk have to match. 

 

 

Mick Jagger meets Flow

 

Mick Jagger meets Flow

Is there anything that gets in the way of the "flow" like email?  The sound goes and/or the little envelope shows up at the bottom of the screen...and boom, you check it and concentration is shot.  It has been driving me nuts the past few weeks.

 

Enter Merlin of 43 Folders, a wonderful site on personal productivity.  Merlin regularly urges us to simply turn off email, allotting certain times of the day only to check and follow up on email.  I've been doing just that the past week.  Turn it on in the morning, respond to urgencies, turn it off most of the morning, check it mid day, than again around 3 and once more before I go home.  That's it.  Amazing. 

 

This bit of personal revelation happened chronologically near the spectacle of Mick Jagger and the Rolling Stones doing the halftime show at last weekend's Super Bowl.  Having come of age in the late 60s, the Stones' music is pretty well embedded in my psyche and seeing the group again (ancient though they are...gee, did Mick, never a handsome man, look bad in the close ups or what??) triggered an odd burst of creative (and probably misdirected) energy.  So, here's a new set of lyrics to their staple "Paint It Black".  My apologies, but here goes:

 

The voice says "you have mail" I want to turn it off.

Demanding all my thoughts I want to turn it off.

Projects sit and languish as I wonder what to write,

Bcc or just cc, it's all a foolish sight. 

 

I can't think anymore, I want to turn it off.

Distractions all day long, I want to turn it off.

Thinking deep is not allowed; it just takes way too long.

"Reply now" or lose the chance to ever be profound. 

 

Banks from Nigeria are sure to send me cash

My number's all they need, I'll soon have me a stash.

Spammers come but they don't go, they just keep bustin' through

Email's free, at least to them, but the cost is all on you!

 

I wanna see you turn it, turn it,

Turn it off.   Shut it down. Walk away.

The world will be just fine.  For a time.  Hey!.

Turn if, turn it, turn it, turn it off.   Yeah.

 

(Instrumental portion, with nasal-like humming sounds here)

 

(Fade.  )

 

Yeah, well, enjoy.  Turning off email really is a good idea, even if my lyrics are not. 

 

Just what are we optimizing?

Just what are we optimizing?

"It drives me nuts!!  They don't get it! What is their problem??"  My friend Ricardo was yelling in the phone.

 

Down boy, I said.  Inhale.  What's going on?

 

"Optimizing.  They keep talking about optimizing.  But they are clueless what to optimize!!!"  I could almost see his neck muscles bulging through the phone.

 

OK, tell me what you heard.

 

"So, I'm sitting in a meeting. One department's guy is making a big speech about why he has to get his efficiency figures up.  The next department makes the same speech, except that her group gets inefficient when the first group gets efficient.  The first group just dumps stuff to her to gain the efficiency.  And nothing resolved, they just went back and forth."

 

Yeah, so tell me something new, Ricardo; departments argue.  Why are you so mad?

 

"What makes me mad is that nobody saw it!!  Everyone in the meeting was operating on the assumption that if each department is efficient, the entire company is efficient! And we've learned from Goldratt and Womack and many others we need system optimization, not local optimization."

 

That's why I like you, Ricardo, you're a good student.  But you're out of school now.  What do you do with this knowledge?

 

"I don't know.  My lectures just don't seem to work." 

 

Well, if you yell at them like you are yelling at me, I'd guess they aren't.  So what would be better?

 

"There you go again...you probably are going to suggest I show them something."

 

What would you suggest?  What's a way to demonstrate this elusive optimization?

 

He thought a moment.  "How about time?  Like the amount of time it takes to process a product?"

 

Seems like a good idea.  But show me some numbers.

 

He thought some more.  "If department A tries to be more efficient, it can crank up it's output to 300 units per hour.  But, by doing that, they slow down department B to 240 units per hour."

 

So what happens to the extra 60 units every hour?

 

"Aw, they just pile up in the aisle.  Gets a little messy by the end of the day.  But department A has better numbers."

 

So how much gets shipped to the customer in this plan?

 

"Well, without overtime, just around 1,900 units a day, since department B can only do 240 per hour.   But a lot of times they stick around an hour or two to get the aisle cleaned out."

 

So how efficient is that to pay time and a half for those folks?  A rhetorical question.  I try another tack.  If Department A is a bit "inefficient" what do the numbers look like?

 

"Well, department A slows down to about 280 units per hour, while department B gets to 250 per hour."  A further pause.  "And so that would put about 2,000 parts per day out the door.  Without overtime."

 

There's your example, my friend.  Use the real numbers.  The competition is outside the plant, not inside. 

 

Optimize...the whole, not the part.

 

Eliminating waste by paying attention to the waist

Eliminating waste by paying attention to the waist

You can learn a lot by looking in unusual places.  My current favorite unusual place is Kathleen Fasanella's excellent blog Fashion-Incubator.  Not that I'll ever figure out how to dress well.  But Kathleen writes about how she makes clothing.  She has a marvelous feel for how things are made.  Plus she is a great writer. And I learn a lot from her. 

 

Today's post is titled yet another pet peeve: Waistbands.  She describes in wonderfully clear language how a manufacturer can design in value for the end user by simply paying attention to design.  In this case, by merely moving where on the piece of fabric the manufacturer cuts the waistband of the pants with respect to the legs of the pants, the pants can then respond to repeated washings with the waist "moving" in direct proportion to the rest of the pants.  Simply put, the waist won't shrink any faster than the rest of the garment.  All by how the waistband is cut. 

 

If you are familiar with sewing it will make sense.  If you are not, like me, you will appreciate that Kathleen proposes more value for the end user is there to be had with some simple thinking and tinkering.  Even on something as mundane as a pair of jeans.  And when the user says "Gee, this brand just fits better!" every day when she/he puts them on, guess what brand will be at the top of the list at the next shopping trip?

 

 

A Kaizen Event for the Holidays

A Kaizen Event for the Holidays

 

 

Between Christmas and New Year's, we snuck in a two-day Kaizen event.  Pretty cool, in that our team got into it.  Results were impressive.  By simply removing non-value added activities, we took a process that had an 11-minute cycle time with three people and modified it to an 8 minute cycle time with only two people.  In addition, we eliminated one external activity that fed this process that required one person for six minutes. 

 

Simply watching, timing, talking, trying, testing and trying again, we saw this in two days.  These things are not hard to do.  The discipline to do it is. 

 

This kaizen event also points out another important fact:  our marketing team is central to achieving kaizen success.  Why?  By keeping a growing backlog of work for our team.  Thus, our team members were not the slightest bit concerned about cutting one person out of a process.  That team member had more than enough to do on a related process.  If the business isn't growing, kaizen won't work. 

 

This is a point seldom discussed and crucial.  A lean transformation is a system-wide effort.  Not just in operations. 

 

Go hug a marketing person today.  It's good for improvement. 

 

The Good, the Bad and the (your eyes are) Ugly

The Good, the Bad and the (your eyes are) Ugly

 

Got an email earlier this week from Kevin Rutherford who writes the blog silk and spinach (what a great name, why can't I think up picturesque words like that??!).  Picking up on practical applications of lean principles, Kevin writes here on the British Post Office's efforts to standardize passport photos:  your eyes are too high, sir.

 

What's intriguing here was that the BPO's initial efforts at mistake-proofing were well conceived; they told the user precisely how to position the head in the photo.  They botched the effort with subsequent requirements, invisible to the user.  In short, they did not achieve rapid error detection and correction, also known as Jidoka (with thanks to Mark Rosenthal for this terrific article which I've used for years). 

 

Kevin's brief and funny write up explains this better than any sleepy PowerPoint presentation; enjoy it.

 

Upon further review, we are also pleased to report that Kevin's eyes are fine and he's on schedule for his holiday. 

 

You're looking good, sir. 

 

How Kanban Breaks Down

How Kanban Breaks Down

 

Last summer, I wrote here about everyday examples of Lean.  In one entry, I described my Jugban system of keeping distilled water in the house for my contact lenses.  A simple container Kanban system, it just works. 

 

Or so I thought until I saw how kanban breaks down.

 

My clever system for refilling the empty container involved a nearby grocery store having a distilled water dispenser that worked.  Alas, the dispenser was out of service recently.  So, I went to another grocery store nearby which also had a dispenser.  That helped me out for a few weeks.  And then IT broke down!  I was in a pickle and ended up having to buy a new gallon at a drug store. 

 

Kanban works marvelously so long as the supplier can and will consistently supply the requestor with the exact amount requested at the time requested in the quality required.  When the supplier breaks down or becomes unreliable, you have three choices.  Fix the supplier.  Change the supplier. Increase your buffer inventory. 

 

Or else your vision really clouds. 

 

Project Kaizen Site is Up

Project Kaizen Site Is Up

 

In December, we ran a series on improving project performance, called Project Kaizen.  Hal Macomber has compiled most of these posts onto a new site, Project Kaizen.  We'll add material there from time to time.  It will serve as a reference for all of us. 

 

Thanks, Hal, for your work on this!

 

Check your Assumptions at the Door

Check your Assumptions at the Door

My colleague Mike solved a tough problem last week.  A really tough problem.  One that had vexed us for the past five months.  One that was important to our company.  And when he fixed it, he not only fixed it, but he laid the groundwork for it staying fixed. And he fixed it with no capital investment and only a few hours of thoughtful work on his part. 

 

It is worth examining what Mike did.

 

Mike has the basic understanding of the context of the problem.  He cared passionately about it, to the point it was causing him to lose sleep.  He kept telling himself, correctly, "This isn't magic, it is physics.  We can figure it out."  Yet we couldn't.

 

Then, over the New Year's weekend, he had an insight.  He questioned a basic assumption we had all made about the situation.  Amazingly, that assumption was false.  Patently false.  Outrageously false.  He then verified the very falseness of that assumption.  Upon verification, the solution was both obvious and easy.  He reversed the error (this was the few hours of thoughtful work).  And, bang, in less than a day, the problem we could not solve was solved.  For good.

 

Perceptive readers will recognize this as a key component of evaporating cloud analysis of tough conflicts.  Central to this is asking "What assumptions am I making about the cause which triggers the effect I observe?"  (My blogging buddy Frank Patrick goes deeper on this topic here.)  It is a mental discipline that forces one to think deeply and question assumptions.   Because, when we can find a false assumption, we make a leap towards finding the root cause.  And finding root cause is the only way to rid the problem, completely. 

 

Mike challenged the assumption instinctively.  Could we have solved the problem in two months, not five, had we employed a more formal problem solving technique sooner??  I suspect so.  That too is a discipline.  We're not there yet. 

 

Try this today with a difficult assumption.  Finish the sentence "You know, this situation really oughta work if (state assumption) was true."  Make a list.  Put at least seven assumptions on this list (yeah, its tough...do it anyway).  Then verify, one by one, if each assumption is in fact true.  You might surprise yourself.

 

Thanks, Mike.  You da man!