Gemba in cyberspace

Going to Gemba, even in a cyber world

I got an email from consultant of ours, Julie Kowalski of Spizzerinctum Group, last week ( email Julie ) in which she captured something I’ve struggled to say but not as well as she did:

I sometimes feel that we as a business society allow email to do all of our talking for us; sometimes we just need two way dialog. Therefore I do not intend for these documents to be stand alone. I would like to talk through each of the items with you, when you have a chance ---- can we schedule a call for sometime on Tuesday?

Julie captured something very important here; she moved the conversation to the workplace, or as many in the Lean community would say, she went to gemba, the place where value is really added. She proposes, boldly yet clearly, to breakthrough our tendency to avoid direct conversation and immediate feedback.

Do something like this today. Don’t send an email; go find the person and ask. Pick up the phone rather than sending the document. Get to her/his place and ask, directly. Observe what you see and hear. Give that feedback to the person to see if you really understand. Then note what you learn.

Thanks, Julie, for the clarity you bring here.

I hope this is helpful. Feel free to forward to a friend. Email me

 

Big Hat and No Cattle? 

My friend Frank Patrick posted a very useful piece on project management yesterday, worthy of your reading.  He summarizes a recent book he read Waltzing With Bears: Managing Risk on Software Projects.  Frank quotes one passage of note for those of us involved in change management.   

The worst organizations penalize unappealing forecasts but not unappealing results. When the project fails, they reason, "Hey, the guy missed the date, but at least he gave it a good try." This problem feeds upon itself: People understand that promising big is more important than delivering, and everybody learns to act accordingly. If you work for this kind of organization, you might as well go with the flow and keep your risk assessments to yourself. 

Ouch.   

It is so much easier to talk big than to deliver big.  And how many times do we kid ourselves that writing a plan is equivalent to achieving it?  

So how to overcome this?  I go back to one of the basics of project tasks, about which we discussed in our Gutter Project series: Making Reliable Promises.   

And one of the central practices of Reliable Promises is stating clearly the “conditions of satisfaction”.  Here, the customer states, clearly, what needs to happen for him/her to be fully satisfied.   

For example, I asked my colleague Stan for some logistics data on eight different buildings earlier this week.  When I stated my conditions of satisfaction, I listed for him five pieces of data on each of the eight jobs and that I wanted it by noon Friday.  He looked at his schedule, said he could block time for it and proceeded.  On Thursday afternoon, he brought in the data.  It looked great…except he only had four of the five data points done.  I said “Good. I like the four.  And I’ll really be happy when I get the fifth as well.  Remember?”  Oh yeah, he said and off he went.  He’ll have it for me by noon today.   

In Texas, someone who talks a lot but does not deliver is referred to as having “a big hat but no cattle.”  Do your best to deliver some result today.

I hope this is helpful.

Bloglet isn't working well

Bloglet is Not Distributing these entries

If you receive this note via an email from the service Bloglet, you are lucky. The service is not working reliably at all, as I have learned from several subscribers who have asked "Why did you stop writing?"

I removed the Bloglet link from my home page. If you would like a reliable email notice when I update the site, I suggest you sign up with Blogarithm. I use this service to let me know when any of the six blogs I follow are updated.

Thanks for your interest.

 

The Gutter Project...all of a sudden, it is over!

The gutter project I wrote about starting and then continuing is now concluded!   It is kind of amazing and I think instructive, though not in the way I expected it to be instructive. 
About 10 days ago, as part of fulfilling a promise to identify equipment we'd need to handle the slit steel coil to make the gutter, team members Ken and Dave visited our current vendor.  Their discussions with the vendor sparked in the vendor's manager's mind (I'll call him Steve).  The next day, Steve called me to request a meeting.  Soon.

He came down and described to Ken and me an alternate production schedule he was thinking about and wondered if it would work for us.  After discussion and some tweaking of the proposal, we realized his proposal met all of our needs...in short, we didn't need to make our own gutter anymore if he could deliver in this new manner. 

What he proposed, in effect, got away from large batches of gutters being run every three weeks to more of a flow of gutters (no pun intended), delivered weekly.  This was our core problem that moved us to try to in-source gutter manufacture in the first place.  So, we'll write it up and the new plan will be rolling in a couple of weeks.

So, last Friday, we held our last project meeting, saying thanks to Chad, Dave, Ken, Bryan and John for participating. We'll also inform our senior managers that we won’t require the funding we had earlier requested.

What did we learn? We did a plus/delta at the end.

-The hard work to get the physical layout right was worth it.  A simple simulation with sticky notes, made to scale, was a super tool.
-Driving open discussions with the vendor ultimately affected his response.
-Our intention to insource probably triggered the flexibility by the vendor.
-Utilizing reliable promises was useful and understandable to all.  Everyone on the team had several promises they had to deliver on during the project’s six-week duration...no one was left behind.  My thanks to Hal Macomber for this concept. 
-PPC metrics also gave us a feel for where we were doing. 
-We learned a lot about stating, openly, conditions of satisfaction.  It felt mechanistic and stiff at first.  We persevered and it got better.
-We need to practice this approach to projects to get better at this.
-We committed no funds.  We spent only time.  We did not work that we were not fully ready to do.  

It was disappointing to not take this through to a physical completion.  But we did get our desired result, which is hardly disappointing. 

I hope this has been a small bit helpful.  I suspect I may try this effort at a "public project" again in the future.  Stay tuned.

 

One Size Does Not Fit All 

It is tempting in a Lean conversion to copy, blindly, what someone else has done.  Better is to apply that which works in your context.  Steadily.  Quietly.   

I had a chance this morning to tour a local facility which is doing just this.  Taking the appropriate tools and making them work in a 110 year old building with machine tools built in the 1920s.  With very insignificant capital infusion from a parent company.  And doubling productivity in three years. Passion and intelligence will offset financial might in many, many situations. 

For a fascinating view of how to get your ego out of the way to realize "one size does not fit all", check out Jeff Angus’ view of effective coaching for excellence.   

Oh, and don’t be like oil's  Procrustes. 

I hope this is helpful. 

The kaizen goal

On Setting Kaizen Goals

We ran a two-day kaizen last week and I learned something very useful.

If all else fails, make sure you set the goal well.

We had the kaizen dates set about three weeks ahead of time. We had a general idea of what we needed to do. But yours truly, who was in charge of the event, got trapped in the tyranny of the urgent. As such, the planning for the event stunk...it was virtually non-existent. We have simple forms to do the planning (thanks to our friends from Wiremold). But I simply didn't do it.

Eating crow with my colleagues on the kaizen, I started the event by admitting the non-performance and we sat together and did the planning. We paid particular attention to the goal. Specifically, we worked it and worked it to make sure we a) met the requests of the recipients and b) stated a goal that was SMART (Specific, Measurable, Achievable, Relevant, Trackable).

It delayed our actual work by an hour or so...quite a chunk in a two-day kaizen. Yet, it proved a key touchstone as we proceeded. And, at the management review at the end, the customer stated his clear satisfaction.

Whew.

The goal is key. Take the time. Even if you do it late.

I hope this is helpful.

Feel free to forward to a friend. Email me

 

Gutter Project Update 

Several weeks ago, I posted the first intro to the Gutter Project, an effort on my part to learn more about lean project management by actually conducting one.  I also committed to doing it “in public” and letting this group view what we were doing.  We have been working on it, even though other events events have gotten in the way of my writing.  Here’s the latest though. 

• Keeping the story of “why are we doing this” is crucial.  More so than I imagined.  Just this morning, Chad asked what the point was.  Not that he had a problem…it is just that he has other jobs too and wanted to reorient. Dave did an excellent job of capturing the story; so well, he did it by asking  great questions of the group.  ( More on project story telling )
• Promises are an effective tool for maintaining progress.  I use a simple spreadsheet to keep track of these, leading to a weekly calculation of “Percent Plan Complete” or PPC.  If you’d like to see what this looks like, Email me and I’ll send it to you.  Feel free to use or modify.
• Mock ups really have helped in our “design” process.  I constructed a simple scale model of the space we had to work with, and then made same scale models out of the two gutter machines, coil storage racks and wrapping table.  We then simply began to move the “machines” around the space.  It brought many issues to light about real world flow issues we would not have seen otherwise.  It also brought about a much simpler system for handling coils than we had earlier. 
• We have consciously not set deadlines for the entire project, even though we have set clear expectations of each promise.  Why?  The project is uncertain; we are in new waters, as we’ve never roll-formed metal before.  We did not believe it was prudent to set a time to build until we believed we had a reasonable flow for the end product.  In this case, the implementation costs have kept going down, as we get the layout and machines cleaner and cleaner.
• All of us are smarter than any of us.  While we’ve heard this old saw, it is true.  Bringing in key players to review the progress has vastly improved anything that any one of us, particularly me, would have come up with. 
• We miss us when one of us is not there.  As a corollary, it is key to have regular participation.  Three of us were gone one Friday (our regular meeting day) and that knocked things back for a week.  One colleague had a surprise conflict come up last week and his wife go in for surgery…we’ve missed him now for four weeks.  And we need his expertise. 
• PPC is a useful metric.  We are cumulatively at 87% PPC right now.  We have worked at getting the conditions of satisfaction for each promise stated clearly and agreed to.   

We have a long way to go to start building our own gutters.  I’ll keep you posted as we go along.   

I hope this is helpful. 

 

“..and all of the children are above average” 

Garrison Keillor uses this tag line to conclude his monologues on A Prairie Home Companion and it is funny because it lays out a common truth in an unusual way…we want to make things better than they can possibly be.

Well, I read a marvelous description of this tendency to misuse averages in a weblog I have grown to enjoy.  Jeff Angus writes a blog that combines two of my very favorite subjects: business and baseball.  Called Management by Baseball, Jeff writes long and insightful posts on management subjects, using baseball as the example.  [If you like baseball, you’ll enjoy Jeff’s blog…if you are into art history, you probably won't.  But if you are into art history, you are probably not reading this blog either J  ] 

In the piece I cite above, Jeff describes how three-fourths of baseball writers believe that their team will have a better record this year than last year.  A statistical impossibility…as the sum of all wins and losses for all teams will always be equal.  And thus, unless one or two teams are totally abysmal, only half the teams can improve…half will get worse.   

All of the children can’t be above average. 

A core practice in a Lean enterprise is to “Document Reality.”  Dreams and hopes have a place; we live in reality.  I do a disservice to my company and my colleagues by not capturing reality.  Do capture some reality today.  Look it square in the eye; write it down; ask what you can do about it.  

I hope this is helpful. 

 

 

Getting Boatloads of Ideas

Just received the latest newsletter on Lean from the Society of Manufacturing Engineers .  Included is a terrific article on cultivating ideas from staff .  It describes a method and power from getting lots and lots of ideas…2-5 per employee per month.  Not suggestions, but implemented ideas, at the workplace level.  

It stems from a new book, Ideas Are Free by Robinson and Schroeder.  I haven’t read it yet, but it appears to be useful.   

My experience (further grounded by observing two daily start up meetings just this morning) is that the team leader is a key person in getting these local improvements.  When she a) identifies an annoyance and then b) asks for a way to address that annoyance, she lets the team know that it is OK to make proposals.  When she then follows up on them, encourages them, charts them, and (gasp) requests others to make further improvements on the improvements, the team gets the hang of it.   

OTOH, when the team leader sees local improvements as an imposition of paperwork and/or boring and/or irrelevant, surprise, the group shows little involvement in improvement.   

Check out this book or The Idea Generator: Quick and Easy Kaizen by Norman Bodek.  Great material.  And then you can make it happen on the shop floor. 

I hope this is helpful. 

On Pain and Change

In an invigorating conversation this afternoon, a colleague in another company and I wondered aloud "what is it that causes one to initiate change?" To make any process improvement requires doing something different. And, if we are to be about process improvement, how do I, as a catalyst for such improvement, initiate such a change?

We realized as we talk that most change seems to stem from some pain. Some undesired feeling or event that is worse than making the change. Two personal examples:

• I started flossing my teeth regularly right after college when I had my first job and was paying all my own bills. No dental coverage at the time, though and a mouthful of cavities. "If you flossed, you wouldn't be in here," was the fact put at me bluntly by the dentist in beautiful San Bernadino, California. And, seeing my small paycheck made even smaller by repeat payments to the dental office, I decided that flossing wasn't such a dumb idea after all.
• I began this blog when I realized that I added clarity to my thinking about lean and about business by writing. And, by writing in "public" was far less painful than just "wondering" in private. So I took the plunge and, 2.5 years later, still write, still value public discourse in this venue.

So is pain necessary for change? Do you have examples? Can you assist the effort to understand this a bit better? If you do, post a note in the "comment" section below or email me directly. I'll write more on this...it helps me learn.

I hope this is helpful.

Feel free to forward to a friend. Email me