I am reading a paper on why continuous improvement efforts fail.

One of the contentions is that as the technical complexity and organizational complexity of an improvement project grow, the improvement methodologies that work on less complex projects become less and less adeaute for the challenges of improveing complex technical process across multiple organizations.

Therefore, we need to develop new improfvement tools more approriate for the ineractions across organizational units.

Any ideas on what these tools might be?

The paper is "Overcoming the Improvement Paradox" and appeared in the European Management Journal, Vol. 17, No. 2, pp.120-124, 1999.

The theory sounds to be pretty reasonable and typical of a paradigm shift. For this, I would recommend "Paradigms" by Joel Arthur Barker. It is a terrific and quick read.

Basically, as a paradigm matures, it becomes less and less likely to solve new more complex problems. To solve the new, more complex problems, a new paradigm is necessary. The problem is in the paradigm shift itself. Folks are content to use the prevailing paradigm, especially if it has made them successful or helped them to climb the corporate ladder. How fast and brave would any of us be to throw out the tool which brought us our success?

Initiatives like Continuous Improvement require a paradigm shift. It is difficult for Senior Managers to make this shift for the reason noted above. Sure, many want it and ask for it, but they are not likely to give up the command control approach. CI initiatives bring a host of new tools, few to none are experienced with their use or their existance. What is also a hinderence is that to have CI, you must first understand where you are and how the process in play operates. This takes time, which few senior managers are willing to contribute or give financial support to. They are after fast and profitable results. They are, for the most part, results-oriented.

Just an opinion.

Regards,

Kevin

To boil it down, things become boring (optimized) after a while. The less dynamic your company is, the faster continuous improvement dies. FMEAs are a structured way to (if used correctly in concert with an effective nonconformance and CA system) force (institutionalize) Continuous Improvement driven by data.

And you reach a point where all the easy stuff is addressed. The hard stuff and the expensive stuff are next in line and guess what....

Remember that paradigms evolve - sometimes rather rapidly.

I suggest rotation of multiple tools so you don't get stuck.

And everything Kevin said.

And in my opinion run the process through a well defined project management system that allows for free thought and ongoing change.

Also realize that if set up properly, upper management does not need to be involved in the day to day project management process. They need the results.

While not to say that upper management is void of involvement in the development of a robust system, when upper management micro-manages these types of programs/processes they are candidates for a high failure rate.

ASD...

"To boil it down, things become boring (optimized) after a while"

Very well put!! Seeing this written as you did reminded me of a demonstration I saw at the Deming Conference last Fall. The presentered had two 2-liter Coke bottles connected top-to-top. One bottle was about 3/4 filled. When you inverted the bottles, the water would chug from one to the other. We would time the transfer. To improve flow, we created a Vortex my swirling the bottle (optimize flow) and timed again. The water transferred at the quickest rate. The question was asked, "Could we improve upon an optimized flow?" A silent room. The presenter picked up the bottle, began the swirl and the Vortex formed. We watched as the water transferred and then he shook it. The water fell in on itself and to the amazement of the crowd, transferred quicker.

The moral: some chaos is good. It causes a reaction.

Back to the group...

To boil it down, things become boring (optimized) after a while. The less dynamic your company is, the faster continuous improvement dies.

Why do C.I.'s die?

I have been doing C.I. for 18 yrs now. I'm not sure I can list all the reasons, but I will list a few.

No. 1. We don't sent specific goals, we just want to do better than we are doing now, and we want someone to do it for us. -- Lazy

No. 2. We have been doing it this way for 30 years and no lean guy can convince me it can be done better, so I'm just going to ignore him, and if something does happen, I'm going to change it back to the way it was. - - Ignorant

No. 3. I think lean should be done this way so I'm going to do it that way. If it doesn't work, then lean doesn't work. - - Uneducated

No. 4. We did it that way once, and it didn't work. - - Liar

No. 5. Your the lean guy, make it happen. - - Uncommitted

No. 6. I was told to do it this way, its not my fault it didn't work. - - Untrained

No. 7. I hired a lean guy and he did a bunch of Kaizen blitz's, and make things sound good for a while, but things just went back to the way they were. - - Uninformed.

No. 8. Lean is just a catch phrase. - - :ca: Failure

No. 9. We just spend a lot of time cleaning stuff. - - Confused

N0. 10 Tried it at the other plant and it failed their too! - - Afraid

In regards to complexity of tool to fit complex problems - I have never found that situation. What I did find was simular though which was lack of understanding of the process capability with respect to the desired output.

I, on the other hand, do not view any of asutherland's list as anything more than mere "annoyances" for qualified change agent who has plenty of tools in his kit to counter negativism from staff and even managers.

I see two main situations which result in continual improvement projects which produce no net improvement:

Processes running at or near optimal, where continued input may result in improved process, but the cost of implementing the improvement outweighs the value derived from the improvement. (This is by far the most observed situation.)
Change agents with few tools in their toolbox, resulting in what I term the "I only have a hammer" syndrome, resulting in everything looking like a nail.Organizations which experience situation #1 have to concentrate their efforts in "cherry picking" and add controls in their improvement projects (evaluation?) which alert them the improvement initiative is a blind alley.

Frankly, situation #2 only has a chance of being ameliorated when top management recognizes the change agent seems to be creating "busy work" with no real net results - the key being net improvement.

One of the underlying drivers of Situation 1 is blind frenzy on the part of organizations who take the concept of "continual improvement" to mean "continuous activity" rather than continual thinking BEFORE initiating activity. There are some organizations which have whole departments centered on creating and running Designs of Experiments. When a department becomes that specialized, it creates situation #2, and begins running DOE for the sake of running DOE, rather than the goal of net improvement for the organization. This is similar to the situation at GE when Neutron Jack was in charge and competing 6S practitioners were robbing Peter to pay Paul, each showing net improvment for HIS project (but at the expense of some other entity elsewhere in the supply chain, with no real net saving ever filtering through to GE's bottom line.)

I, on the other hand, do not view any of asutherland's list as anything more than mere "annoyances" for qualified change agent who has plenty of tools in his kit to counter negativism from staff and even managers.

Annoyances?

I like that.

I have seen each of these senerio's result in a failed attempt to drive lean. Most of them occured in places where lean has never really been given a good attempt, or chance, AND, as you stated "annoyances for a qualified change agent" is the real key. In most of the aforementions items, this was the case in that the change agent should have been more prepared.

In any event, that has still stopped lean from progressing.

I guess the real underline of this could be accurated stated as " If the student hasn't learned, the teacher hasn't taught". or Lean often fails because of unqualified lean experts, who only think their experts.

Folks often find humor in my "persnickety" word choices.

In my mind (an often scary place), I choose the words precisely because of the nuance.

For example, I rarely use the words "teach" or "instruct" when I am performing that activity. I choose a phrase which seems more descriptive of my intended end result: "help the students learn." It seems to me the task others refer to as "teaching" is not really accomplished until the end result of student learning is achieved.

Similarly, a change agent trying to implement lean or any other initiative, is not finished until the initiative is up and running smoothly. The change agent who blames "them" for a failed installation is as immature and ineffective as the job candidate who applies for the wrong job with the wrong set of qualifications and horridly jumbled resumé and cover letter and then proceeds to blame "them" because he isn't hired to a dream job at $300,000/year.

Similarly, a change agent trying to implement lean or any other initiative, is not finished until the initiative is up and running smoothly. The change agent who blames "them" for a failed installation is as immature and ineffective as the job candidate who applies for the wrong job with the wrong set of qualifications and horridly jumbled resumé and cover letter and then proceeds to blame "them" because he isn't hired to a dream job at $300,000/year.

What? $300k/yr . . . and take a pay cut.

I agree. As often as any tool is used, whether a hammer, saw, or lean tool, the result can be best achieved when the tool is used in the right order, at the right time, to get the best planned output.

Broyal . . . . question? Why write "why lean fails?" I mean, who cares about failures . . . why not write about why and where it succeeds?

Oops, my error. You were reading about it, not writing about it. Sry. Long day.

I think that Continuous Improvements fail because people don't ask the fundamental question of what they are trying to accomplish. They don't do the up front efforts for planning. I think the other thing is they try to tackle the tougher problems and don't have the success to build on.

My top reason: Because of lack of dedication/drive from the top. If the Top Dog really wants it to happen, it will hapen.

Hey, Mike! :bigwave: Long time, no type.

Hey Mike....ditto, good to see your post

My top reason: Because of lack of dedication/drive from the top. If the Top Dog really wants it to happen, it will hapen.

Mike - right on

Years ago the Queen Mary sailed into port. I went down to look at her.

I leaned across the gap from the dock to the hull and put my hands on her. I could feel that it was floating free.

If I pushed hard enough and long enough, there is no doubt I would be able to move her an inch.

However, the Captain could call upon the crew and poweful engines to move that ship anywhere in the World he wanted it to go.

For years, I struggled and accepted the blame for not being effective at making change happen.

I now take pride in moving my ship an inch, and realize that if and when it ever becomes important to the top dog, the ship will move fast and far.

Radical statement follows - I reject completely that it is me who has caused the failure of the organization to change. The organization is happy with the status quo, and when it is no longer happy, they will find me ready and waiting to help with change.

Smoke & mirrors

Shadows & dust

Mike - right on

Years ago the Queen Mary sailed into port. I went down to look at her.

I leaned across the gap from the dock to the hull and put my hands on her. I could feel that it was floating free.

If I pushed hard enough and long enough, there is no doubt I would be able to move her an inch.

However, the Captain could call upon the crew and poweful engines to move that ship anywhere in the World he wanted it to go.

For years, I struggled and accepted the blame for not being effective at making change happen.

I now take pride in moving my ship an inch, and realize that if and when it ever becomes important to the top dog, the ship will move fast and far.

Radical statement follows - I reject completely that it is me who has caused the failure of the organization to change. The organization is happy with the status quo, and when it is no longer happy, they will find me ready and waiting to help with change.


I really like that analogy. It give me hope. :agree1:

I am reading a paper on why continuous improvement efforts fail.

One of the contentions is that as the technical complexity and organizational complexity of an improvement project grow, the improvement methodologies that work on less complex projects become less and less adeaute for the challenges of improveing complex technical process across multiple organizations.

Therefore, we need to develop new improfvement tools more approriate for the ineractions across organizational units.

Any ideas on what these tools might be?

The paper is "Overcoming the Improvement Paradox" and appeared in the European Management Journal, Vol. 17, No. 2, pp.120-124, 1999.




Thats why the new concepts are to implement the Quality in Design.(Preventive)

This is the reason for APQP.

Wheter not downstream it is very difficoult to know what the root cause was.