Author: Rick Bohan

Posted on

5S and Culture Change

I’ve been catching up on my reading on the Industry Week web site.  (Full Disclosure:  I’ve written articles for both the IW website and the magazine but don’t and never have made any money from them.)  I found one that speaks to an issue that I cover here quite a bit: culture change.  The article “10 Steps to Create a Continuous Improvement Culture”, reviews a presentation that Steve Olsen, Executive Vice President of Camcraft, an automotive components supplier, made to the 2016 Industry Week Manufacturing & Technology Conference & Expo.

Managers always like to hear what other managers have to say about what’s worked and what hasn’t for them.  And Olsen has some important things to say.  Here’s a summary of his ten steps:

  1. Get Help
  2. Choose What Fits
  3. Explain Why (Over and over and over)
  4. Keep It Simple
  5. Help People See
  6. Find Allies
  7. Be Open
  8. Be Generous
  9. Be Creative
  10. Be Patient

I’ll let you read the article to get Olsen’s details on all ten steps but there is one I’d like to highlight:  Explain Why (Over and over and over).  In my experience, managers don’t spend enough time…not nearly enough time…talking with employees about the continuous improvement initiative.  Sure, there’s almost always some sort of “launch” where managers express their total and undying commitment to the continuous improvement initiative again.  Too often that’s the last time anyone hears much of anything from management until it becomes clear that the initiative isn’t gaining traction.  At which time management starts asking “What the hell happened?”

I occasionally teach an Organization Behavior course at nearby Kent State University.  In that course, I focus on management of culture change.  I tell my students that change always creates resistance, that there’s no such thing as “no resistance” to change of any sort.  Managers do need to manage resistance as it becomes evident.  In the course, I covered a model for managing that resistance.  An important element of that model was stated this way:  Communication3  (that’s supposed to read “Communication Cubed” but I can’t do the 3 as a superscript).  By that, I meant that, before and during any change effort, managers needed to communicate a lot.  More than they’d think they’d need to.  Then, more than that.  I tell my students that, during a change effort, there’s no such thing as too much communication.

The idea of Communication3 carries with it the fact of lots of repetition.  Managers too often feel that, once they announce something (or, worse yet, once they post it on the bulletin board), everyone ought to hear and understand the message.  It just doesn’t work that way.  Managers need to tell each other and all associates why and how the organization is going about the change effort…over and over and over, using essentially the same words.

Let’s look at an example, one that I might have used before.  A plant manager I once worked with was upset that workers weren’t putting the change over tools back on the shadowboard he’d installed.  He had put the board up, announced to the crew what he wanted to happen, and returned to his office.  As far as I know, he didn’t mention the shadowboard or its purpose again until he complained to me about the fact that nobody paid any attention to it.

I told him that he needed to come out onto the shop floor twice daily (at least) to look at the shadow board and talk to the operators about its use.  If the tools were there, he could say to his supervisors and operators, “Good work.  That’s just what I wanted to see.  Anybody got any ideas as to how we can improve it?”  If the tools weren’t there, he should gather his supervisors together and say, “My damn tools aren’t where they are supposed to be.  I expect them to be where they are supposed to be when they are supposed to be there.  I expect you to reinforce this message with the operators.”  Twice a day.  Every day.

After awhile, he can reduce his communications to once a day, then to a few times a week, then to once a week and so on.

The central message is this:  if you aren’t talking about your continuous improvement effort to others in your organization several times a day at the start and several times a week even after it gains momentum, you aren’t doing your job as manager.

 

 

Posted on

Bad Problem Solving + Dysfunctional Company = Assured Failure: Part Two

Awhile back (too much of awhile back), I posted about an article I’d read on the Industry Week website about six sigma and team problem solving.  (Here it is, if you want to take another look at it.)  In that first post, I ranted a bit about the worst condition highlighted by the IW article: incompetent managers.  I promised I’d make some comments about the inept approach to problem solving described in the article in a followup post.  Well, three months later, here’s that followup post.

Let me start by saying that I don’t want any of my remarks here to be seen as anything like a defense for the utterly, abjectly vacuous leadership described in the IW article.  When nincompoops take up space in the C-suite, no tactic, no tool, no approach, however well conceived and implemented will save the organization.  It’s doomed to a long, slow, tortuous demise.  (Trust me…I’ve worked for such organizations.)

But the truth is…our antagonist didn’t seem to have learned much at his six sigma training.  Let’s look at the evidence for our indictment.  The article says that our six sigma guy and the team used the DMAIC approach to team problem solving but we aren’t provided with much that indicates that he or the team actually followed the DMAIC path.  In fact, the path they actually did follow looks more like:

  1. Make a chart based on only one of the many possible relevant metrics
  2. Jump to conclusions
  3. Present a limited solution that fits the conclusion jumped to.

Now, the article does say that the team spent several weeks in meetings and analysis but doesn’t give us much as to how that time was spent.  It’s not hard to imagine the team spending its time and energy discussing how it was going to go about getting their penny-pinching bosses to spring for the new computer system.

The question posed by the IW article is:  Would Dr. Deming have been a proponent of Six Sigma.  But the example described in the article doesn’t really help address the question because it doesn’t really portray six sigma methods, and certainly not DMAIC.

Within the next few weeks, the blog at Employer Resource Council in Cleveland will start posting my series on DMAIC, so I won’t go into any detail here as to how that approach should actually be undertaken.  (I’ll post a link when it shows up.)

Team problem solving can be hard work.  It can be fun, too and is nearly always effective given adherence to the process and senior leadership that isn’t bereft of even a scintilla of intelligence.  There’s nothing like implementing a solution developed by a team and seeing that solution work to motivate associates at all levels in the organization.   Everyone in the organization needs to keep in mind, though, that it’s not “six sigma”, or “DMAIC”, or any other set of tools that contains the magic.  It’s smart, committed leadership getting smart, motivated employees involved in making continual improvements to all aspects of the business.  I’m pretty sure Dr. Deming would have been on board with that.

 

 

 

 

Posted on

Leadership that Fizzles Out

About a year ago, a small local company got in touch with me with an interest in implementing lean tools. Management told me what they wanted, I told them how I went about things and what it would cost.  We set up a schedule and started the project.  There were a few warning signals early on I suppose.  I’d arrive for our meeting and the managers would appear as if I wasn’t expected.  The conference table would be covered with dirty parts and tools. On the other hand, they were carrying out their agreed upon tasks reasonably well, better than other clients I’ve had. But that problem of not being ready for meetings got worse, so that meetings would be cancelled…after I arrived.  In other cases, some “emergency” or other would pop up and the meeting would be stopped and postponed.   After one such cancellation, management told me, “We’re really busy.  We’ll let you know when we want to get started again.” I waited a few weeks, then sent a few emails that went unanswered and made a few phone calls that weren’t returned.  Finally, I got in touch with the owner, who had hired me in the first place.  He said he was surprised that no one had gotten back in touch with me, but…”we’re really busy, so we’ll let you know.”

I’ve often wondered how it happens that management takes the trouble to find a consultant, get started on a lean initiative, even make a bit of progress before letting the project fizzle out all together.  (I confess I’ve had this happen a couple of other times.  Yeah, I know…it could be they just don’t like me, but I get good feedback from clients that actually do follow through.)  I have to think that a fair amount of discussion among senior leaders and managers took place before the initiative was started.  It’s tough to imagine that someone in the company woke up one morning and thought, “I think I’ll hire a consultant this week and get started on the lean thing to see what it’s all about.”  So, what is it that happens?

I probably should follow up to see just what it is that happened (or didn’t happen) but I don’t.  But I have a few hypotheses.  First, I wonder if lean methods are still being oversold.  I get the impression, at times, that clients, in spite of my admonitions to the contrary, expect that I and they will implement some arcane methods that only smart guys like me know about, after which throughput, quality, customer service, and general employee happiness will leap forward in a month, maybe two.  They nod their heads affirmatively when I tell them that a successful lean implementation will take a couple of years, even in a small organization, but get impatient when sales haven’t doubled and margins jumped up by the third month of the project.

Second, I’m fairly certain that, again, in spite of my admonitions, clients underestimate how…tedious…a lean implementation can be.  Laying the foundation for a successful lean culture is like laying the foundation for a building…first, you gotta dig a hole, maybe by hand.  Then you gotta lay heavy cement blocks…lots and lots of heavy cement blocks.  By hand.  The final edifice is going to look great but that’s a long time away and, right now, the work is boring and hard.  A lean implementation is like that.  The company has to carry out lots of activities that aren’t much fun and the immediate payoff for which is just about nil.  Like getting all the junk off the shop floor.  And, maybe, painting the place.  And labeling all the cabinets and shelves.  And telling that operator for the 33rd time to put his damn tools back on the shadowboard when he’s through with them.  All to say, lean implementations aren’t nearly as exciting as perhaps the client hoped they would be.

Third,  nobody, most especially managers, in my experience, like to be told that they need to change what they’ve been doing and how they’ve been doing it.  I tell managers that they’ll need to take a “gemba walk” through the operations several times a day if they want operators to actually change their behaviors…and they don’t do it.  Then wonder why operators aren’t adhering to the new standards.  A team creates a value stream map and figures that a supermarket between two departments will improve flow and scheduling substantially.  All that’s needed is four squares painted on the floor and some communications between the department supervisor and the operators to get started.  Two months later, there are no squares on the floor and the same flow and schedule problems exist between the departments.  A leadership team agrees to buy a bulletin board and post charts of several important plant performance indicators.  Six weeks later…no bulletin board and no charts.  I know that managers and operators aren’t lazy.  I just think that they aren’t good at changing their routines, even when they agree that change is needed.

I’m not sure how to address all of this effectively.  I feel that I speak to these issues before starting any engagement but I’m not eager to hammer so stridently on these issues that clients become dispirited before they start.  And, perhaps, it doesn’t matter what I say at the start of a project if clients are only hearing what they want to hear.

As I’ve said so many times…the tools are straightforward, it’s the culture change that’s the challenge.

Posted on

Office Process Mapping

I’ve been working with a client recently as part of an initiative to improve several of its core processes.  This is a non-manufacturing client, so the processes we’re working on are all administrative or “office procedures”.  I’ve done a bit of this sort of thing over the years but have never worked with so many process improvement teams in such a short period of time.  It’s been a regular “office process mapping and improvement boot camp”.

Here are some things I’ve learned over the years and that have been reinforced in my recent experience:

Start with a Project Charter

It’s important that the team start with an energetic discussion of “What are we doing here and what’s expected of us?”  That’s what a project charter is for.  It’s not “getting the form filled out” that’s important, it’s the discussion that takes place that serves to get the team members on the same page.  There are lots of Project Charter formats out there.  Choose one that’s available or design one to match your own needs and circumstances.  There are lots of generic forms on the interweb.  Some are simple, others are pretty complicated.  Whatever works for you.  But, again, it’s the conversation that important, not filling in lots of fields on a form.

Map the Process As Simply as You Can

Choosing the “level” at which the team will map the process can be a challenge.  At too high a level, there can be too little detail, at too low a level, too much detail.  I usually talk about the “2000 foot level”; high enough so that the team doesn’t get into the weeds of describing, in detail, each and every task associated with the process but low enough so that the basic steps are identified.  I’ve found that even fairly complicated processes can generally be captured in ten to twenty steps.

It’s important to map the Current State with the assumption that each step is carried out without anything going wrong.  Teams can get way down into the weeds with respect to all the steps that they undertake when things don’t go right.  So, you present the question:  “How does the process work now assuming everything goes the way it’s supposed to?”  You’ll get to all the bad things and problems later on.  Right now, you just want to get the process mapped, not identify everything that can go wrong.

I use three symbols for mapping processes: a circle for the first and last process steps, squares for all the steps in between, and arrows.  That’s it.  No decision diamonds, nothing.  My experience has been that most of the other symbols are used to account for sub-processes and steps that are made necessary by variances and problems.  That’s not what we want to capture at this point.  That said, I admit that I’ve had to occasionally use decision diamonds in a process map to identify legitimate choice points.  But it’s been very occasionally.  The large majority of the time, two circles and a bunch of boxes and arrows works just fine.

Brainstorm Process Step Variances

A variance is something/anything that goes wrong or might go wrong at a particular step of the process.  For example, variances for the process step, “Ship the product”,  might be:

  • Product doesn’t get shipped
  • Wrong product gets shipped
  • Wrong quantity gets shipped
  • Product is shipped to the wrong address
  • Product is shipped via wrong carrier
  • And so on.

The team brainstorms these variances and the usual guidelines to brainstorming apply.  In other words, don’t get wrapped up in long discussions of each possible variance; just write it down and move on.m  You’ll sort through them later.

One useful parameter on the brainstorming of variances to keep in mind:  The variances should occur at the step being focused on at the moment.  If a variance occurred at an earlier step but is caught or observed at the focus step, it goes under that earlier step.  For example, if the step under focus is “Budget requests are reviewed and approved”, a variance like “Manager submits wrong budget format” isn’t a variance at that step.  The manager submitted the wrong budget format at an earlier step, not at the inspection step.  Variances that occur at the “review and approve” step might include:

  • Review and approval is delayed
  • Incorrect format gets approved

By the same token, be careful of brainstorming variances that are actually desired outcomes of the step.  Let’s imagine that you’re mapping the process for hiring and you’re focusing on the step “Review resumes”.  In that case, “No suitable resumes are identified” wouldn’t be a variance.  Weeding out undesirable resumes is exactly what the step is designed to accomplish.  Sure, “no suitable resumes”  might be a hassle for the organization but it’s not because mistakes or errors took place at that process step.

You’ll find that this step of brainstorming variances creates a lot of team energy.  The members will engage in lots of discussion of the variances, even when you remind them of the brainstorming guidelines.  That’s OK…mostly.  You don’t want to squelch energy.  Let them talk about variances a bit and keep them moving.  So long as the team doesn’t get engaged in “debates” as to whether a variance is a big deal or not or discussions of solutions, you’ll be OK.

Prioritize the Variances

The most useful tool to use initially in prioritizing any brainstormed list is polling. I usually give the team members more than three tallies when polling process variances, maybe five to seven, depending on how many variances were brainstormed.  At this point, you’ll have a good visual as to which process problems are front and center for the team.

Develop Improvement Actions for Important Variances

You’re on the home stretch here.  I put up a good, old-fashioned four column action planning page on the flip chart (Action/Assigned To:/Target Date/Status) and go to the variances with the most tallies.  I ask, “What actions or steps do we need to take to reduce or eliminate this variance?”  There is generally a good bit of discussion at this stage.  Some of the “action ideas” will be pretty broad (“A training program for new hires”) and will need to be broken down into specific tasks (“Work instructions documented for all tasks”).  Others will be more specific (“Purchase new copier”) but might need some preliminary work carried out (“Develop business case for a copier and get three quotes.”)

But, hey, you know how to put together an action plan, right?

Follow Up Meetings

Now, we get to, what might be, the toughest stage of the whole enterprise…following up on all that initial work to actually get something done.  Brainstorming and coming up with new ideas is lots of fun.  Developing standard procedures and getting quotes for a new copy machine…not so much.

The team will need to meet no less often than bi-weekly to make sure that improvement efforts move forward.  In most cases, management will need to actively encourage these meetings.  It gets very easy to cancel meetings or for individual team members to miss meetings because of the regular workload.  Managers need to make certain that meetings are being held, attendance is good, and time frames are being met.

Even after the improvement actions are implemented, the team needs to meet to evaluate their effectiveness.  Six to twelve months of bi-weekly meetings can be difficult to sustain but it’s necessary if you’re to have any hope of creating real, lasting change in your business processes.

 

 

Posted on

Polling: How to Narrow a Brainstorm List

In my last post, I went over a few basic guidelines to brainstorming.  In this post we’ll address that important question: “What the heck do we do with all this stuff we just came up with?”

It’s true that “figuring out what to do with all that stuff” is something of an issue.  Do you now start talking about each and every one of those 32 ideas the team just brainstormed?  Do you try to weed some ideas out?  Do you take a vote on which ideas the team likes best?

Polling the list at this state works well, in my experience.  Polling is a method that visually indicates which of the ideas the team has the most interest in.  It looks like “voting”…but it isn’t.  It acts as an informal prioritization method  that doesn’t so much narrow the list as it does uncover which items the team is most interested in pursuing.

Here’s how it works:  Everybody gets three tallies to indicate which items on the brainstormed list are the most important, most interesting, best ideas, most likely to succeeed, whatever.  By “tallies” I mean that each team member gets three check marks to put next to the items they’re most interested in discussing.  All the team members get out of their seats, read all the items on the flip chart sheets (You did write all the ideas on flip chart seats, didn’t you?  Or, at least, a dry erase board?) and mark their tallies

There’s an important twist though: Team members can distribute their tallies any way they like.  In other words, they can put one tally next to each of three items, or all three tallies next to one item if they wish.  The idea is that if someone feels very strongly about an idea, she can indicate that by putting more than one tally next to it.

But isn’t that “gaming the system”?   It would be…if there was a system  to game.  All you’re doing is seeing what items the team is interested in discussing.  If someone is so interested in a topic that she is willing to put all three of her tallies next to it, should the team give that idea some consideration?

Once everyone has completed the task, I usually point out (and, maybe, circle) the items with lots of tallies.  I also acknowledge the items with just one or two tallies.  You might be able to combine some of the items with several tallies to further narrow the list.  In any case, the team likely has a manageable list of items to discuss. I’ve often seen teams decide that the tallied items make a good set of ideas that work together and don’t need to be further narrowed down.

One last thing:  I sometimes will give more than three tallies.  If the list is a long one or if I don’t want to do too much “list narrowing”, I’ll tell each member they can have five or even more tallies.

You’ll find that brainstorming, followed by polling is an efficient way of getting lots of ideas out on the table and working through them.

 

Posted on

Brainstorming with a Team

I’ve found that, perhaps, the most useful tool for teams isn’t used that much:  good ol’ brainstorming. I’m not sure why this is the case.  There’s no better tool for getting lots of ideas on the table in a short order.  (Actually, I do have a few hypotheses as to why teams don’t use brainstorming more, but I’ll save them for another post.)  With that in mind, I’m going to review some guidelines for team brainstorming.

Quantity NOT Quality

When the team is brainstorming, the idea is to come up with lots of ideas.  Lots and lots of ideas.  The goal (at this point) is quantity of ideas, not quality.  Quality will come later…right now: quantity.

I used to train and facilitate employee teams back at Jones and Laughlin Steel.  During the training, I’d have each team brainstorm problems in the department with the intention of picking one  of the problems to address as a team. I’d tell the team, “…and we’re not going to go to lunch until you have 150 ideas on these flip chart sheets.”  Invariably, the teams thought the task to be any easy one: “Only 150?  Heck, we got thousands of problems down there at the mill!”  Just as certainly, the teams would struggle once they got to twenty or so ideas.  Eventually, each team figured out that wild, crazy, nonsensical ideas were allowed, even encouraged:  a team member would brainstorm “Those damn Martians sneak in the plant at night and reset the equipment settings.”  That idea and others like it would get added to the list and we always got to 150 “ideas” by lunch.

I rarely set brainstorming targets as high as that.  In fact, never.  I do use techniques like asking, “What’s another idea?” and waiting until I get one.  Or saying something like, “Let’s get a few more ideas to fill up this page.”  (This assumes I’m writing the ideas on a flip chart, of course.)

Don’t quit brainstorming after the first few ideas are out there and the group pauses.  Keep pushing for a few more ideas.

Don’t Evaluate, Assess, or, even, Discuss the Ideas

Many discussions don’t go well because a “social barrier” to idea generation develops.  Here’s the way the “social barrier” works:  Jane comes with an idea and everyone else starts evaluating, analyzing, assessing, going over, under, and around it.  After twenty minutes of that, no decisions have been made and Bob comes up with a suggestion…which is followed by another half-hour or so of evaluation, analyzation, etc., etc.

Two things happen here:

  • A lot of time is used up discussing few ideas,
  • As team members see the gauntlet that ideas are run through, they become reluctant to participate by tossing out new ideas.

Neither of these dynamics are of much help. To overcome them, let everyone know that the most discussion that’s allowed is, maybe, a bit of clarification.  But let there be no, “How good, really, is this idea?” type discussion.  There will be time for that sort of conversation later.  Write the idea on a flipchart sheet and move on.

If It Comes to Mind, Say It

There’s another barrier to ideas that operates in groups…I call it the “individual team member barrier”.  Ann thinks of an idea but holds on to it:  “Naw, the team will never go for that.”  She thinks of another but hold onto it, too: “Seems like we tried that awhile back.”  She develops a third idea but is silent again:  “I better think that one through.  This team really puts new ideas through the mill.”

The team never gets to hear Ann’s ideas because she’s filtering them herself.  This guideline is meant to overcome that self-filtering.  Crazy idea? Get it up there.  Sounds a lot like something that was already mentioned?  No problem…write it down again.  Exceeds the laws of physics?  Who cares?

There are obvious boundaries to this guideline; personal attacks and so forth would, of course, be out of line.  But most groups understand that.  I’ve never had a team exploit this rule by going too far with it (not even a team back at Jones & Laughlin whose members told me that they had only volunteered in order to figure out a way to get revenge on their supervisor.)

Modify, Change, Tag On, Add to Ideas That Have Already Been Mentioned

Often, a team will become silent simply because everyone is trying to think of a brand new, fresh and novel idea that no one has come close to mentioning.  And that stifles brainstorming.  Members should keep reviewing the list and be willing to toss out variations of ideas already on it.  Arnold sees an idea on the list: “Cellphones provided by the company” and adds “Tablet computers provided by the company”.  Roger looks at the fishbone and sees: “High air temperature” as a cause of PVC pipe scrap and adds:  “Low air temperatures” and “High humidity”.  You get the idea, I’m sure.

The only problem with brainstorming is that it’s not used enough by teams.  You can overcome this by always having a flipchart easel an pad or dry erase board at all your meetings…then say, “Hey, let’s brainstorm this!”

 

Posted on

Bad Problem Solving + Dysfunctional Company = Assured Failure: Part One

Industry Week has a series of articles that you should read: Lean and Continuous Improvement: Twelve in 12.  I haven’t read them all yet, but it looks like a good collection.

Right now, I want you to read the first article, “Would Doctor Deming Have Been A Black Belt?”.  It’s more interesting than it sounds, so go ahead…I’ll wait right here.  I’m especially interested in having you read the case study embedded in the article.

On reading the article, I went down to the comments section, thinking I’d read a set of sharp denigrations of the company and the approach to problem solving portrayed in the example.  None of the commenters mentioned the example.  My guess is that Deming would say something like, “Neither Six Sigma nor any other improvement approach has a chance of providing value in this organization until it replaces some managers and significantly changes its culture.”

ANY manager who would put a team to work on order entry, then threaten the team leader with losing his or her job because the costs of the process weren’t reduced isn’t fit for his or her job.  ANY leadership team that would see fit to take advantage of process performance improvement by reverting back to previous performance so as to enable the reduction of capacity, needs to be replaced by the board.  Right now.  We’re talking about a dysfunctional organization led by utterly incompetent “managers”.  There’s no chance that any approach to continual improvement would work under such circumstances.

All this is apart from the bad approach to process improvement carried out by the “black belt”.  But I’ll address that in my next post.

Posted on

How to Implement Lean Manufacturing: Straighten and See (5S) – Part 6

The last element of Straighten and See assures that information about the work that is to take place at each location is carried out consistently and effectively.   We’re going to discuss three elements of this Straighten and See Component:  Visual Display, Visual Metrics, and Visual Control

Continue reading “How to Implement Lean Manufacturing: Straighten and See (5S) – Part 6”

Posted on

How to Implement Lean Manufacturing: Straighten and See (5S) – Part 5

We’ve been talking about implementing Straighten and See and, in our last post, we listed three elements:

  1. Establishing a marked and labeled home address for everything!
  2. Marking equipment and machinery so that it’s easy to operate and/or monitor safely.
  3. Establishing easy to see information about work station performance and activity.

In that post, we covered the first element in detail.  Let’s look at that second element in this post.

Continue reading “How to Implement Lean Manufacturing: Straighten and See (5S) – Part 5”

Posted on

No Trust, No Quality

In a recent article on the Lean Enterprise website (“Why Are There So Many Opinions About What Lean Is and Isn’t” by Michael Balle), I found the following statement:  “Volkswagen’s latest scandal should not detract from the high overall quality of their cars…”  (Latest? You mean there are others?) That’s kind of like saying John Dillinger’s latest bank robbery shouldn’t detract from the fact that he sends his mother a birthday card every year.

Continue reading “No Trust, No Quality”