If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
Iget a kick out of the sparring that goes on between lean, Six Sigma, TQM, and Theory of Constraints (TOC). One of my colleagues puts it well, "TOC helps us focus on what needs improvement; Six Sigma helps us identify and control the source of waste; and lean helps us keep attention on always delivering more value to customers, employees, and consequently, owners.
For those of you interested in the Battle of Improvement Systems take a close look at the "ASQ Six Sigma black belt body of knowledge" take on Six Sigma vs. TQM. I really appreciate the contributions from the Six Sigma community; I just haven't figured out how to apply it to projects. Have you? For now, Ive placed my bet on project kaizen.
? Guy Kawasaki wrote, "Less is the new more." Easy to learn: symmetry, seduction, subtraction, and sustainability. Very valuable to do. Step 1: Read Matt's book!! just 140 keystrokes.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=03314884-90d1-47e5-acf3-2821313e9fdc)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=4ce3f392-8989-448a-a97a-c1432dd3fce6)
{ 4 comments… read them below or add one }
Hal:
Thanks for this post. I refer to the project (as opposed to the operational) application of “Six Sigma” as “Sick Sigma.” A colleague who was there at the time explained the original idea behind Six Sigma was to create products so robust that they would rarely break. Requirement said it had to support fifty pounds, you engineered it to support 150 pounds. Like that.
Somehow it morphed in to producing products with little variation. Maybe a reasonable shift if you’re manufacturing stuff with fine tolerances. Entrepreneurial project efforts do not succeed on fine tolerances.
Heck, the original problem Six Sigma was created to resolve was variation. The idea was not to eliminate variation, but to make variation moot. Imagine plumb being defined not as straight up and down, but anything plus or minus 30 degrees from straight up and down. That was the original Six Sigma idea.
Six Sigma excellence should mean that if I accidently back my car over the cell phone, it still works. Instead, it means that the little display screen is just barely thick enough to maintain shape, and cracks all by itself when bumping against loose change in my pocket.
Hal, good post.
My developing opinion on the “battle” is that it is most loudly fought by people who don’t understand implementation. Those who are busy implementing Lean, TOC or 6 Sigma know how hard it is and are grateful that SOMEONE is simply out there improving things!
I pretty much avoid the battle now…it is non-productive talk (translate: “no value added” or “only adds variation” or “reduces capacity at the constraint”). If someone asks me, I say, “Each is a strong system and they have much in common…go make something better.” And carry on.
And, to David’s comment above, I agree fully.
Hope you had a Happy Thanksgiving!
One Six Sigma teacher told me that the reason Six Sigma succeeded compared to the others was that it had a focus on quantifying the $$ of results. I find that the framework of Six Sigma can be useful for some people, and knowledge of statistics and probability and variation are useful for helping define what “good” looks like.
I think a good Six Sigma effort looks a lot like a good project, but I’m not sure how a good project would be influenced by Six Sigma.
One thought I had about kaizan: I’ve always practiced continuous improvement, and when the team comes up with a better way, I’m ready to go ahead and implement it. But I’ve also seen how very small process changes can have unanticipated consequences. For example, a change from a batch manufacturing to line manufacturing process resulted in a sudden jump to nearly 20% early product failures, and it took months of intensive engineering effort to find the root cause. How can we balance the benefit of the change with the risk? One piece of advice I would give is to keep good records of when every change is made.
With projects (compared to manufacturing) the risk of making many, frequent, small changes seems low, and the benefits are high. With a larger company, it is a challenge to share the templates/processes among all the project managers, and be flexible enough to get improvements from the different teams, without resulting in a lot of churn of forms/methods/tools.
By the way, your link to the project kaizan is not working — it looks like you left out a letter.
Hal,
I think the basic idea of 6s is to first understand how many opportunities there are for defects, measure them, pareto and attack. Oh heck, let’s just say DMAIC and get it out. Making a high volume, low variation product, e.g. a bar of soap, perhaps inherently limits the opportunities for defects, as well as allow for many possible rearrangements of its value production so as to be conducive to defect reduction.
Projects, with respect to their products tend toward the prototype end of the volume continuum. They are unique productions.
However, as you said in your post a few up, the idea is to “make work ready.” This is the service process that we iterate. If we have a thousand tasks, we are to make them ready as well. Yet those task result in great variety of “products.” There are many thousands of opportunities to screw up a lightbulb change. And all before we actually climb the ladder.
I think 6s has great opportunity, but not if you look to apply it to project product defects. Making work ready is a service which unaddressed is probably 1s, I believe Koskela has said much the same.
Bob