What Battle?

4 Responses to “What Battle?”

1. David Schmaltz Says:
   November 23rd, 2006 at 7:58 am

   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.

2. .Joe Ely Says:
   November 25th, 2006 at 8:09 am

   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!

3. Diana Hutchinson Says:
   November 27th, 2006 at 10:42 am

   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.

4. Bob Wells Says:
   November 30th, 2006 at 11:25 pm

   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

Comment On This