<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.5" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: What Battle?</title>
	<link>http://www.reformingprojectmanagement.com/2006/11/22/706/</link>
	<description>The magazine for the project age</description>
	<pubDate>Sun, 07 Sep 2008 23:37:36 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.5</generator>

	<item>
		<title>by: Bob Wells</title>
		<link>http://www.reformingprojectmanagement.com/2006/11/22/706/#comment-11906</link>
		<pubDate>Fri, 01 Dec 2006 04:25:58 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2006/11/22/706/#comment-11906</guid>
					<description>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</description>
		<content:encoded><![CDATA[<p>Hal,</p>
<p>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&#8217;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.</p>
<p>Projects, with respect to their products tend toward the prototype end of the volume continuum.  They are unique productions.</p>
<p>However, as you said in your post a few up, the idea is to &#8220;make work ready.&#8221;  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 &#8220;products.&#8221;  There are many thousands of opportunities to screw up a lightbulb change.  And all before we actually climb the ladder.</p>
<p>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.</p>
<p>Bob
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Diana Hutchinson</title>
		<link>http://www.reformingprojectmanagement.com/2006/11/22/706/#comment-11875</link>
		<pubDate>Mon, 27 Nov 2006 15:42:30 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2006/11/22/706/#comment-11875</guid>
					<description>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.</description>
		<content:encoded><![CDATA[<p>One <acronym title="Common name for the quality approach focused on reducing variability throughout processes">Six Sigma</acronym> teacher told me that the reason <acronym title="Common name for the quality approach focused on reducing variability throughout processes">Six Sigma</acronym> succeeded compared to the others was that it had a focus on quantifying the $$ of results.  I find that the framework of <acronym title="Common name for the quality approach focused on reducing variability throughout processes">Six Sigma</acronym> can be useful for some people, and knowledge of statistics and probability and variation are useful for helping define what &#8220;good&#8221; looks like.<br />
I think a good <acronym title="Common name for the quality approach focused on reducing variability throughout processes">Six Sigma</acronym> effort looks a lot like a good project, but I&#8217;m not sure how a good project would be influenced by <acronym title="Common name for the quality approach focused on reducing variability throughout processes">Six Sigma</acronym>.<br />
One thought I had about kaizan:  I&#8217;ve always practiced continuous improvement, and when the team comes up with a better way, I&#8217;m ready to go ahead and implement it.  But I&#8217;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.<br />
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.</p>
<p>By the way, your link to the project kaizan is not working &#8212; it looks like you left out a letter.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: .Joe Ely</title>
		<link>http://www.reformingprojectmanagement.com/2006/11/22/706/#comment-11857</link>
		<pubDate>Sat, 25 Nov 2006 13:09:49 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2006/11/22/706/#comment-11857</guid>
					<description>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!</description>
		<content:encoded><![CDATA[<p>Hal, good post. </p>
<p>My developing opinion on the &#8220;battle&#8221; is that it is most loudly fought by people who don&#8217;t understand implementation.  Those who are busy implementing Lean, <acronym title="Theory of Constraints; Eli Goldratt's insight on throughput">TOC</acronym> or 6 Sigma know how hard it is and are grateful that SOMEONE is simply out there improving things!  </p>
<p>I pretty much avoid the battle now&#8230;it is non-productive talk (translate: &#8220;no value added&#8221; or &#8220;only adds variation&#8221; or &#8220;reduces capacity at the constraint&#8221;).  If someone asks me, I say, &#8220;Each is a strong system and they have much in common&#8230;go make something better.&#8221; And carry on.  </p>
<p>And, to David&#8217;s comment above, I agree fully.  </p>
<p>Hope you had a Happy Thanksgiving!
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: David Schmaltz</title>
		<link>http://www.reformingprojectmanagement.com/2006/11/22/706/#comment-11837</link>
		<pubDate>Thu, 23 Nov 2006 12:58:20 +0000</pubDate>
		<guid>http://www.reformingprojectmanagement.com/2006/11/22/706/#comment-11837</guid>
					<description>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.</description>
		<content:encoded><![CDATA[<p>Hal:</p>
<p>Thanks for this post. I refer to the project (as opposed to the operational) application of &#8220;<acronym title="Common name for the quality approach focused on reducing variability throughout processes">Six Sigma</acronym>&#8221; as &#8220;Sick Sigma.&#8221; A colleague who was there at the time explained the original idea behind <acronym title="Common name for the quality approach focused on reducing variability throughout processes">Six Sigma</acronym> 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.</p>
<p>Somehow it morphed in to producing products with little variation. Maybe a reasonable shift if you&#8217;re manufacturing stuff with fine tolerances. Entrepreneurial project efforts do not succeed on fine tolerances. </p>
<p>Heck, the original problem <acronym title="Common name for the quality approach focused on reducing variability throughout processes">Six Sigma</acronym> 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  <acronym title="Common name for the quality approach focused on reducing variability throughout processes">Six Sigma</acronym> idea.</p>
<p><acronym title="Common name for the quality approach focused on reducing variability throughout processes">Six Sigma</acronym> 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.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
