The Meaning of “Total” in Japanese Improvement Programs

As Armand Feigenbaum originally formulated Total Quality Control (TQC) in 1951, it meant quality control from product design to after-sales service. It had to do with the scope of the activity, not with who participates. In 1984, when Kaoru Ishikawa described the Japanese version of TQC, “Total” had come to mean “company-wide” (全社的,  zenshateki). Sometimes, it is even explicitly stated to mean “with participation by everyone” (全員参加, zenyinsanka).

It can be argued that the Japanese side mistranslated “Total,” but it makes no difference. If we want to understand TQC or TPM, we need to go by what they mean by it, and realize its implications. “Participation by everyone,” in particular, means the following:

  1. The CEO and the janitor both participate. Personal involvement by top management is essential because it prevents anybody else claiming they are too busy.
  2. Training in the activity must cascade down from top management through all the layers in all the departments.
  3. There must be sanctions for refusal to participate.

As a consequence, the “Total” programs are difficult and expensive to implement. Before starting one, you must be sure that:

  1. It is worth it.
  2. The work force has the needed skills.
  3.  Management relations are conducive to success.

Otherwise, it most often fizzles out after a flurry of initial activity. In the worst case, it leads to a mutiny. When starting improvement in a manufacturing plant, the prerequisites for any kind of “Total” program are rarely met. It is safer to start a with activities  involving local, small teams of volunteers, whose success motivates others to join in. This gradually strengthens the organization to the point where it is able to pull through a program that requires participation by everyone.

Top 10 Reason Why Lean Transformation Fails | Tim McMahon

See on Scoop.itlean manufacturing

“In my experience these are ten reasons why Lean implementation fails:

  1. “No Strategy  […]
  2. No Leadership Involvement  […]
  3. Relying on Lean Sensei/Champion  […]
  4. Copying Others  […]
  5. Thinking Lean Is A Tool  […]
  6. Lack of Customer Focus  […]
  7. Not Engaging Employees  […]
  8. Not Educating Employees […]
  9. Lack of Understanding  […]
  10. Conflicting Metrics […]”
Michel Baudin‘s insight:

Would my top 10 list be exactly the same? Probably not, but there would be extensive overlap.

See on

The Truth about Lean Failures | Vivek Naik

See on Scoop.itlean manufacturing

The truth is, most lean implementations are a failure over long duration.Some of them are the major causes, as identified by the people involved in the implementation. They may be the right or maybe these are just the symptoms.

Michel Baudin‘s insight:

In this post, Vivek Naik presents the results of a survey about the causes of Lean implementation failures conducted among the readers of his blog.

The respondents, of course, are not representative of anything except a self-selected subgroup of followers of a blog on Lean, but Naik, to his credit, asked open-ended essay questions like:

  • What is your Biggest problem to implement lean in your organisation?
  • What would help you overcome this challenges?

And he didn’t tally percentages of responses, which would not have been meaningful. What he does is simply list and categorize the causes that the respondents have put forward.

What I find striking in this list is that no one mentioned insufficient mastery of the engineering and management tools of Lean. ‘Lack of understanding” appears only under Culture. What about the ability to achieve SMED, generate heijunka schedules, or design a bonus system that supports improvement without turning employees into bounty hunters?

Along with the majority of Lean implementers in the US, Naik’s responders take the tools for granted. In that attitude, I see a major cause of Lean failures.

See on

One More Time: Lean Is Not Just For High-Volume Producers | Gregg Stocker

See on Scoop.itlean manufacturing

“One of the most common arguments against the adoption of lean is that it applies only to high volume manufacturing operations.  Much of the literature available on the subject, as well as the close association with Toyota has created the misconception that lean is not applicable to organizations that deal with a small number of large projects or highly customized products or services.

There are three basic questions related to the application of lean that demonstrate that it is not dependent on the volume of product or services produced…”

Michel Baudin‘s insight:

Gregg Stocker’s perspective on the broad applicability of Lean.

See on

To consultants on point Kaizen: forget about it | Bodo Wiegand’s Watch

See on Scoop.itlean manufacturing

“Sometimes, I can’t believe it – within the past 2 weeks, I was at 2 plants in Switzerland and Germany, that have both tried to introduce Lean for a year and a half, using Point Kaizens in the whole company, and failed mercilessly…”

Michel Baudin‘s insight:

This is Bodo Wiegand’s monthly newsletter. It is in German. In the past, I have provided complete translations of some of his letters and may do so again if there is popular demand.

In the meantime, if you cannot read German, you can use Google translate to get the gist of what he is saying.

See on

Wanna Sabotage Your Lean Implementation Effort? Try This | Lonnie Wilson | IndustryWeek

See on Scoop.itlean manufacturing

Most facilities that fail in a lean implementation have failed to create stable process flow. And by stable I mean statistically stable — a process that is predictable. (Wanna Sabotage Your #Lean Implementation Effort?

Michel Baudin‘s insight:

The way I read Lonnie’s article, he is saying that neglect of the engineering dimension of Lean manufacturing is the primary cause of implementation failure. I agree. It is a long article, but worth reading.

See on

3 reasons why you need a [your-company] Production System

See on Scoop.itlean manufacturing

Do you need a company-specific Production System (XPS) to boost your operational improvement? Yes you do. Here are three reasons…


Michel Baudin‘s insight:

I agree with  Torbjørn Netland’s post, with one caveat. In any XPS, effectiveness should always trump standardization. Many XPS’s turn into premature standardization efforts that stifle creativity in plants and turn the implementation effort into an exercise in formal compliance.

In a company with many plants worldwide, making different products for different markets by different processes, local teams need to be allowed to find their own solutions. What the XPS must not allow them to do is to keep these solutions to themselves. Instead, it must organize the sharing of knowledge and skills across sites by such means as periodic technical conference hosted in turn by each plant and a private collaboration web site with wikis and forums.

See on

RICKS versus 5S

In the TPS Principles and Practices discussion group on LinkedIn, Frederick Stimson Harriman started a thread about why it is silly to translate 5S into English.

I think the main problem with the commonly used translation of 5S is that it is wrong and misleading. I don’t think it is silly to translate if you can get the meaning right. What is truly silly and hopeless is trying to find 5 English words with the right meaning and starting with “S.”

Back when 5S was only 4S, I heard the following in the UK: “Remove, Identify, Clean, and Keep clean” or R.I.C.K., and I thought it was both reasonably accurate and mnemonic.

For the fifth “S,” Shitsuke, I see it as the state you achieve when you have done the first four S’s long enough for the activities to become second-nature. If telling your kid every day to brush his teeth is Seiketsu, what you have accomplished when he does it on his own without prompting is Shitsuke. So I would translate Shitsuke by “Second-nature,” which happens to start with S.

With that, we could have R.I.C.K.S. as an improved translation. What do you think?

Using project charters: not as easy as it seems

In a comment on a previous post, the Virginia MEP’s Bill Donohue  listed several tools that he feels are particularly useful, among which were Project Charters, and I would like to share my experience with them. The concept is self-explanatory, and you can see a variety of examples by just googling “project charter.” It is simply a form intended to provide a one-page summary of a project.

I have been involved with two multi-year projects with clients who wanted to use this tool, and it seemed such a simple, common-sense approach that I embraced it with gusto. To my great surprise, the project teams didn’t. It just required them to fill in such data as the name of the project, the list of team members and roles, short descriptions of current, ideal and future states, the main implementation milestones, and estimates of what good it would do.  It would be a great summary on an A3 sheet of paper, and a perfect tool to communicate with peers and management, while keeping the team focused on the goals.

But it didn’t turn out that way. Working with teams to generate charters took much longer than anticipated. These documents were perceived as a hurdle to clear before implementation could start. Once generated, they were never referenced in the inner workings of the team but only trotted out for management meetings. They were generated on Excel worksheets based on templates supplied by management and primarily used in PowerPoint slides, in which the font was too small to read on screen. Since most teams did not have access to a large format printer, whenever they were printed, it was on A4/letter-size paper rather than A3.

I wondered why the teams were not embracing this tool. They had a feed-the-bears attitude to it. Managers were the bears that periodically had to be fed, and the charters were offerings to keep them at bay. I thought the charter should instead be a project management tool used primarily used by the team itself, and only secondarily for management communications.

I had previously used a more informal approach, where we would write a one-page memo explaining in plain text the who-what-where-when-why-how of the project. With the signature of the manager in charge of the target area, this memo would then be posted on the shop floor for every affected person to know what was going on and the extent to which their cooperation was needed. It was generally well accepted by project teams as “Communications 101.” One reason management wanted formal charters was standardization. They wanted all projects in the program to have descriptions in a common format to make them easier to review.

Lean implementation was starting in these companies, with management keen to engage employees at all levels and tap into their creativity, but filling out a form is not an activity that we usually associate with creativity. Possibly, management’s demand for charters was sending a mixed message: be creative but follow these standards. It was saying “think out of the box but stay within this box!”

Perhaps the form itself was a problem. In both cases, it had been designed by a committee of managers who were as new to Lean as the rest of the organization, and I thought the following features were mistakes:

  1. There were too many different roles identified for team members. The relevant distinction in practice is between core members, who are committed to the project, and the others, who are only involved. In a line redesign project, for example, the production supervisor in charge and the manufacturing engineer are both core members, but the plant safety expert who needs to approve the design is only involved. In the form, members could be assigned one of four different roles. Some were accountable for the outcome, others executed the project, others yet were consulted on it, and finally, there were those who were just kept informed. It sounded great, but, in fact, created unnecessary complexity and wasted time in discussions of which category each member should be in.
  2. The form confused PDCA with a project plan. The main phases of any project were identified as Plan, Do, Check and Adjust. It really didn’t fit any non-trivial project, which you would break down into smaller tasks each defined by deliverables. PDCA is a discipline you would apply to each of the tasks, as well as to the project as a whole, but Plan, Do, Check, or Adjust would not appear as bars in a Gantt chart or entries in an action item list.  In a setup time reduction project, for example, one task is to shoot a video of the current method, but you cannot fit it under Plan, Do, Check, or Adjust.
  3. The form had boxes for information that the teams could not possess until the project was completed. If you are a carpenter building your 50th staircase, you should be able to summarize current and future states, how long you will need, what good it will do, etc. But if you are a team undertaking setup time reduction on a machine for the first time, you are entering what is for you uncharted territory. Upfront, you don’t even know the details of the existing state, let alone the future. At this point, all your setup time reduction team knows is that its goal is to achieve changeovers under 10 minutes on a specific machine in daily practice. When JFK said “this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the Earth,” this one sentence was enough of a charter to focus the work of tens of thousands of people for the following eight years. There would have been no way, at that point, for fill out an A3 form with more details, because they were unknown.
  4. Project teams are also ill equipped to estimate the economic benefits of their project, and wary of writing down amounts they may be held accountable for. In fact, the first few projects that mark the beginning of Lean implementation are never grassroots initiatives. They are selected by management, for their combination of economic value and skill development potential. The setup time reduction team in our example does not need to estimate the benefits of quick setups; they just need to achieve them, promptly and within budget.
  5. The committee that designed the charter form had also come up with a “smart” naming scheme for projects.  It had codes for site, department, project category, and start date. It was a conditioned reflex for people who had grown up with such naming systems, but it served no useful purpose while adding complexity.

After a long struggle, the teams managed to produce at least partial charters. The managers  were not happy, but they had to make do and let the projects proceed. As they did, however, the charters rapidly became obsolete. The teams did not pay much attention, but the charters had to be updated for management presentations, which revealed another problem: there had been no plan for revision management on the charters. The charters had been generated as worksheets in Excel books, that had been emailed around, copied on memory sticks, and printed. There are technical solutions to manage documents so that revisions are made by authorized editors, reviewed properly, and stored in such a way that you can trace back the history of revisions, but this was not one of them.

What lessons have I learned from this experience? Not wanting to throw out the baby with the bath water, I still think of project charters as a useful tool, but it has to be introduced in phases, initially giving project teams the freedom to experiment with both content and format to come up with documents that are useful to them. The handful of pilot projects at the start of Lean implementation requires management attention, but not much administrative paperwork. Never mind standardization at this stage. Soon afterwards, you have tens of projects running in parallel, orchestrated by a steering committee, and, at that point, project charter A3s can be helpful.

Rather than being defined upfront by a committee of managers, charter formats should be allowed to emerge from the organization’s project experience, with current and past project leaders in charge. There may also be different templates by category of project, considering that different contents may be appropriate for setup time reduction, assembly cells, machining cells, milk runs, supermarkets, kanban, etc. The need for revision control on these documents should also be considered when selecting tools to generate them, which requires more IT expertise than either the project leaders, the managers, and even most Lean consultants have. Their first choice is almost always Excel, and it does not meet the needs. Alternatives to be considered include, for example, Infopath for form generation and Sharepoint for storage, retrieval and revision control on charters.