<?xml version="1.0" encoding="iso-8859-1"?>
<rss version="2.0">
	<channel>
		<title>Six Sigma Blogs at the iSixSigma Blogosphere</title>
		<link>http://blogs.isixsigma.com/RSS2.asp?action=full</link>
		<description>Six Sigma Blogs at the iSixSigma Blogosphere</description>
		<language>en-us</language>
		<copyright>Copyright 2004-2009 iSixSigma</copyright>
		<managingEditor>blogosphere@isixsigma.com</managingEditor>
		<webMaster>blogosphere@isixsigma.com</webMaster>
		<generator>iSixSigma Blog 1.0.5</generator>
		<lastBuildDate>Fri, 20 Nov 2009 15:35:09 -0800</lastBuildDate>
    	<ttl>60</ttl>

		<item>
			<title><![CDATA[Six Sigma Blogs: Swansong]]></title>
			<link>http://blogs.isixsigma.com/archive/swansong.html</link>
			<description><![CDATA[Time are topsy-turvy, and change is in the air. My role has evolved away from Six Sigma over the past several months, and my readers – both of you – may have noticed I’ve been posting here less and less. This will be my last post. Thanks for all the comments and emails. It’s been fun and I’ve very much appreciated the pulpit and bullhorn that iSixSigma has provided.
I’ll enjoy being a reader for the rest of the excellent bloggers on this site in the future. Keep up the good work.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General]]>
			</category>
			<pubDate>Thu, 30 Apr 2009 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: WWDD?]]></title>
			<link>http://blogs.isixsigma.com/archive/wwdd.html</link>
			<description><![CDATA[Perhaps you all arrived at this conclusion way ahead of me, but I’m starting to worry more and more about the way we, as continuous improvement professionals, are spending our time.
It’s becoming increasingly clear that the world in general, and the economy in particular, has gone off meds. Yes, I know, this isn’t news at this point. But lest you think I’m the last one to get the message, seek out the open letter that John Stumpf, The CEO of Wells Fargo, recently placed in the New York Times and elsewhere. He was explaining his view on “the value of team member recognition”…which apparently boils down to paid travel to fun places in his mind. Clearly there’s at least one other person slower on the uptake than me.
The press has been all over this letter, including this piece by Maureen Dowd. I don’t have anything to say about it that hasn’t already been said by smarter people. But it does highlight that there is a true shift going on out there. What used to be reasonable, even commendable, has become detestable.
Deming exhorts me to create constancy of purpose, and Wheeler explains to me why reacting to random variation is a bad thing. I feel I have both and intuitive and statistical understanding of “special cause”, and I try to apply that understanding to the work in front of me. Usually that means resisting the tendency to chase special causes in favor of common cause work, and for a long time I have been confident that was the right thing to do.
But now? A lot of things are changing. Those changes feel drastic. Is it time to react in a special way? Or is this just fluctuation of the larger system? Do we keep running our Six Sigma programs, Lean initiatives, and Quality Management systems and wait it out? Or has the time come to move on to changes and initiatives that are more radical and sweeping? More special? Deming does advocate constancy of purpose, but in the next breath he points out the need to adopt a new philosophy for a new economic age. Which advice applies now? What would Deming do?
Let me offer a few more things to think on to frame this question. Continuous improvement programs usually rely on projects as units of work. Using various toolsets, each project is able to return more value to the organization than they consume in money and resources. Group a bunch of these projects together, add up the saving, and you have a program.
Successful programs might generate 5% productivity each year. In other words, if we do things right, we might produce 105% of what we produced last year for the same amount of money. Or maybe we produce the same amount for 95% of the cost. You get the idea. For the past several years, maintaining that sort of incremental improvement in consecutive years was a great result. 
But now? Your sales are down 80%. Your raw material cost are up 150%. You can’t spend $100,000 even for a guaranteed return of $125,000 because credit is frozen. Double digit percentage layoffs abound. In this environment, that ongoing 5% productivity that was great a few years ago is less than a rounding error compared to the huge swings that are happening largely outside our control.
Take Wiremold as a cautionary example. If you are reading this blog, there’s a good chance you already know something about this company from Womak and Jones’ book “Lean Thinking.”
Great company, hugely strong in Lean, right? Well, read this. Sure, there were clearly other factors involved, and maybe their commitment to Lean isn’t as strong as back in the day. But anyway you slice it, this is a titan in the continuous improvement world staggering from a serious blow. Lean can’t help if there is no demand. You can’t save your way to top line growth. It doesn’t matter how efficient you are if no one has money to buy what you are selling.
I think we at least need to ponder whether anything that we are doing matters at this point. Whether we are maybe even part of the problem. It’s easy to spank Wall Street CEOs as they assume the position in front of Congress, but are we just as guilty of failing to confront a new reality?]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 12 Feb 2009 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Act II]]></title>
			<link>http://blogs.isixsigma.com/archive/act_ii.html</link>
			<description><![CDATA[Six Sigma, which is beginning to acquire some grey around the temples, has now advanced to the stage where the basic requirements for success of the program are fairly well known. That doesn’t stop it from being screwed up in about 95% of installations, but no one can say that’s due to a lack of reference material detailing what’s required to be successful. Implementing Six Sigma has become a matter of excellent execution rather than invention and discovery. Or at least it should be.
The same is true of many other large-scale organization programs and installations. Converting to Oracle or SAP, for example. Building a performance management system. Opening and managing a call center. Developing a strong Innovation or New Product Development process. Outsourcing. The list goes on and on. There are a lot of things under the general “organizational transformation” umbrella that while still very difficult to pull off, require excellent large-scale execution skills rather than a lot of invention.
All of this leads to what I call the “Act II” problem. As you might guess, Act II follows Act I. Act I can be any of the things I described above, including starting a Six Sigma program. It can also be fixing or “re-energizing” previously botched execution, which is actually more common with Six Sigma programs these days. Whatever the case, the defining feature of Act I is that is it usually so pressing and painful that no one is thinking ahead to Act II, especially the person who was hired to produce Act I.
So what is Act II? Simply put, it is making use of what was produced in Act I to achieve some desired end. Wait, you might say, isn’t that the point of Act I? Generally speaking, not really.
Take a Six Sigma deployment, for example. Act I usually consists of hiring or training belts, engaging consultants, conducting training classes, filling a project pipeline, getting initial projects done, delivering results, etc. Many (most?) organizations fail at some point in Act I, which is why Act II doesn’t get much mainstream attention. Act II can only begin when Act I is complete – that is, when the program is already up and running and hitting on all cylinders. The project and talent pipeline is flowing well with little intervention, and results are being regularly delivered. Six Sigma isn’t new or exciting anymore, it just a part of the fabric of the business. Though rare enough, all of that just gets you to the starting line of Act II.
Act II is where you start to think beyond the simple running of the program. Now that you have all the machinery, what are you going to do with it? How does it play with the other processes in your business? How will what you have built evolve over time? If you’ve mastered the basics, what do the advanced levels look like? How can what you’ve got become a competitive advantage in the marketplace? What should be emphasized and what should be dropped in the future? In short, what will you do with what you have built? Act II is all about answering these questions, but only after the initial execution has been completed at a high level. Only after the initial build is done.
The problem is that Act II takes a much different skill set than Act I, so it is rare to find one person who can do both effectively. And many people who have built careers on Act I – particularly those who are called in to fix an ailing Act I – simply have no Act II. When the time comes, they let the results of their excellent execution operate on a performance plateau. They, and the organization, will often feel they’ve earned the right to do so. But unfortunately, in the world of organizational change, standing still means moving backward. If you’re not growing, leaping, expanding, and evolving with whatever you are doing, then you’re marching to the grave. There really is no in between, no time to enjoy the plateau. If you have no Act II waiting to begin, you might as well not even have done Act I. That’s a tough lesson to learn, but non the less true for it.
I think this explains why the business landscape is littered with the carcasses of many once-strong programs. They had a strong Act I, but there was no Act II, so the show ended abruptly. As hard as Act I is, and as rare as it is to see an Act I successfully conclude, Act II is even trickier to plan for and pull off, and consequently more rare and valuable.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[Change Management&nbsp;,&nbsp;Leadership]]>
			</category>
			<pubDate>Wed, 26 Nov 2008 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Rigmarole]]></title>
			<link>http://blogs.isixsigma.com/archive/rigmarole.html</link>
			<description><![CDATA[Six Sigma is an amazingly persistent program. I was left off the list for the official birth announcement, but someone should probably be planning ahead for a thirtieth birthday party in the next few years. That’s remarkable longevity for trumped up flavor-of-the-month program.
I think Six Sigma is utterly absurd in many respects. Even if you love the methodology, you have to admit that the jargon and belt terminology are over the top. Honestly, to the uninitiated we must sound like a group of arcane techno-monks spoiling for a fight. We're the drag queens of the quality world. Six Sigma training methods are generally excruciating, and often rooted in dubious pedagogy. Quality control at the program level is non-existent. Statistical methods are routinely abused. Many conclusions reach are just plain wrong. I can see all this quite clearly, and I like the program.
So why does Six Sigma survive? If it is patently ridiculous, potentially misleading on crucial questions, and generally very annoying, why do people keep using it? The answer is simple, I think: because despite all that, it works. But not for the reasons you might expect.
Consider the window dressing that accompanies a full-blown Six Sigma project. For the sake of this example, let’s assume we’re looking at one of the first projects in an organization. The process probably kicked off with the search for a consulting partner. Six Sigma consultants come at great expense, so some native set of requirements likely kicked in that required multiple consultancies to be evaluated by a high-level team. Once the consultant was picked, candidates for training had to be selected. Because the training is so expensive, this again required a great deal of concerted time and attention from the organization. Ditto for project selection. Finally training takes place, and everyone has to learn a whole new dictionary. The project gets rolling, toll gate reviews start up, and they’re unlike any project meetings ever seen before. No one really understands anything. Questions are asked, arguments begun, experts called in. Eventually paths forward are determined, and execution starts. Implementation is carefully staged and monitored because, let’s face it, no one involved can afford for the project to fail at this point. Results occur, processes are changed, metrics are reported, and success is celebrated. Everyone is happy, and not a little bit relieved. Now repeat, and repeat, and repeat.
That’s a lot of rigmarole. And it’s generally considered to be the ugly side of Six Sigma, the messy underbelly that necessarily accompanies the elegant statistical approach, the data driven decision making. But I think that view gets it backward, suggests that the tail wags the dog. Far from being undesirable, I think all that rigmarole is actually what adds the value in the whole process. I’m convinced the content of the program is immaterial. All the program content needs to do is trigger the window dressing, because the window dressing is what gets the right people in the room.
Let me put it another way. Many companies hire consultants to do things that they supposedly cannot do for themselves. But it is sometimes the case that consultants come in to the organization and seek answers to the question being asked entirely within the organization. Which is strange because logically, consultants are not needed if the answer is already present in the population hiring the consultant. (If you haven’t experienced this phenomenon you might think I‘m making it up. But ask around, because I’m sure you won’t have to go too far to find someone who can provide relevant story from your part of the world.) Development of corporate strategy is an archetypal example. So why use consultants in such cases? They are extremely expensive, and the answer is already there. Well, you use them precisely because they are expensive. Writing that check triggers a set of behaviors in the organization. It forces important players to take notice. It makes it politically dangerous to ignore the outcome of the project. It means people show up at meetings and complete their action items on time. And all that means that the answer is suddenly taken very seriously, even if it was known all along, and even if it happens to be incorrect.
I think Six Sigma works the same way. The crushing structure, bureaucracy, and cost of a deployment sends all kinds of signals to the organization that the program is important and needs to be taken seriously. I’m not saying it makes sense, but I am saying it works. All the rigmarole serves the very important purpose of getting the right people in the room, which means decisions can be made and execution can happen. The guts of the program don’t matter, as long as it serves that purpose in the end. Six Sigma does this by accident rather than by design, but it nonetheless does it very well. And that’s why I think we should probably be planning for a thirtieth birthday party.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 13 Oct 2008 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Thinking Ahead]]></title>
			<link>http://blogs.isixsigma.com/archive/thinking_ahead.html</link>
			<description><![CDATA[One of the central problems all organizations face is balancing long term thinking with short terms needs. It is clear that time and resources need to be devoted to both; companies that live moment to moment don’t survive very long, while those that focus on the big picture without worrying about the details usually don’t live long enough for their vision to matter. So the question isn’t which is more important, the question is how to do both simultaneously.
The strategies :

Ask everyone in the organization to simultaneously focus on long term vision and short term execution. 
This is the most intuitively attractive answer. It’s the one that various business books and seminars recommend. And it would be a great strategy if it could be pulled off, but I’ve never seen it happen. Toyota might be a counter-example based on books I have read, but I’m guessing insiders could educate me about the ways in which it is difficult there as well. If you know of others, please comment.
The problem with this strategy in my experience is that firefighting always wins. No business I’ve ever seen has been willing to let a short term issue fester in favor of providing time for employees to think about the long term. “Oh, I’m sorry we just short-shipped out biggest customer…but we’re in a long range planning retreat this week so I’ll deal with it on Monday”. That sort of thing gets you fired at most companies. There’s no question which takes precedence.
Interestingly, I think continuous improvement as it is practiced today is part of the problem rather than the solution. Many companies now run so lean in terms of personnel that there is no excess capacity to fight minor fires, and everything becomes an emergency. At the same time, positions on the floor and elsewhere have been time-studied to death, so there is no extra seconds in the day to devote to long term thinking. Individual projects are optimized like crazy with very little though given to the whole. I know it’s not supposed to be this way, but often it is.
The answer to this is widely seen as the next strategy.

Ask everyone to worry about long term vision and strategy at certain times, while focusing on short term execution the rest of the time.
Future state mapping is a great example of this strategy. You haul people out of their normal responsibilities for a few days to consider what the future state should look like. People who are practiced at this develop not only an ideal state, but a few interim states along the way as well. Then when the mapping is done, the team goes back to their regular jobs, which are usually execution focused.
The follow-on strategy often involves projects and/or Kaizen events. Both of those can work. Projects work by forcing project leaders (and sometimes their teams) to continue working towards a long term goal, balancing that with their short term responsibilities. In essence this strategy works by forcing the first strategy (above) to occur for some period of time. Because projects are inherently limited in duration, this can be successful. Kaizen events, on the other hand, work by forcing the second strategy to occur for some period of time. Both projects and Kaizen events function by preventing the natural tendency of an organization to focus on short term needs.
The problem with this strategy is that the short term and long term thinking usually become divorced from one another. The classic example of this is annual “Strategic Planning” (which goes by many names), wherein everyone works like crazy for a month or two to prepare an X-year plan and get approval for it up the chain. Then once that’s done, the plan it put away and never seen again. Everyone goes back to managing the short term. Projects and Kaizen events still occur – and may even help the organization –but they are rarely explicitly connected to the broad strategic plan.
Recognition of this tendency is, I think, what makes the third strategy most common.

Employ a few people to worry full-time about long term vision and strategy, while most others focus on short term execution.
This is a very common answer. Maybe the most common. Especially in corporations for which selling the product (or otherwise dealing with a customer) is resource intensive. Consider a retail chain, for example. If there are  1000 people working for the company, 900 of them might be on the sales floor selling products directly to customers. Another 50 might work in logistics (distribution, transportation, warehousing, etc), perhaps another 25 are support staff of some sort. On a good day, that might leave 25 people to think about long term strategy for the company. And not just standard business strategies like how to market, what to sell, and where to operate, but also things like how to attract and retain employees, where to hedge and where to spot-buy, and who to fire. Oh, and maybe how to run a continuous improvement program.
If you are part of an organization, you probably already know the problems that crop up here. In the example above, 25 people who are sitting somewhere other than the front lines are trying to determine strategy for the 975 who actually know first-hand what is going on. The ones who are closest to direct feedback and subtle shift are the ones least empowered to influence and select the strategy. It’s a set up doomed to failure for all but the most talented (and rare) of leaders. It’s a strategy that looks good in theory, but is devilishly hard to successfully practice. And even when you get it right, you’re not taking advantage of the knowledge and expertise of all those people out in the field.
The saving grace for this strategy, and the reason it is so common, is that it is a stable structure. Even if it isn’t a great strategy overall, it’s better than the other two because it is tenable. It is a compromise way for the organization overall to pay attention to both short term and long term thinking, even if no individual within the company is doing so. It survives and flourishes not because it is a great way of doing things, but because it is slightly better than the alternatives.
Is there a better way?]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership]]>
			</category>
			<pubDate>Sun, 14 Sep 2008 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Being Right]]></title>
			<link>http://blogs.isixsigma.com/archive/being_right.html</link>
			<description><![CDATA[There are countless business books out there that present good reasons why it is not necessary to be 100% right all the time. Beyond being unnecessary, I think being completely right is highly over-rated in the context of business. Being 80% right and good at executing is probably more than sufficient in most cases. Not all cases, of course, but most. Being 50% or even 25% right and good at executing is certainly better than being 100% right and unable to execute. But clearly, this message is not getting through to the Six Sigma crowd.
I say this because the majority of philosophical conversations I hear about continuous improvement still revolve around a driving need to be right. These range from high level (Is Lean or Six Sigma the right program for this company? Have we got the right set of tools? Are our senior executives saying the right things?) to very specific (Are we doing measurement system analysis right? Do we have the right project selection process? Is our interpretation of capability indices right?). But they all rest on a common assumption that being right about the various aspects of continuous improvement is necessary.
I’ll do the 80% contingent one better and propose that being right is neither necessary nor sufficient for a continuous improvement program like Six Sigma to work. I’m not even sure it is worth worrying about.
The sufficiency clause is easier to argue, because libraries are filled with books by people that are right. Deming was right. Shewhart was right. Ishikawa was right. Juran was right. Womack is right. Wheeler is right. There are even some consultants out there who are right. Plenty of people over time have got things right. But there are still many of organizations doing it wrong, even though they’ve read all of the books and hired the consultants. So clearly being right isn’t sufficient for being successful.
There is also ample evidence that being right isn’t necessary for being successful. I’ve seen multitudinous cases where flawed methodology or assumptions were used to generate genuine process improvements. And not just by luck. There are plenty of Green Belts and Black Belts out there who misuse the statistical toolset they have been handed and still turn out great results. Same thing for Lean or any other methodology you care to mention.
Indeed, this latter phenomenon is a fixation both in the community and in the popular business press. There are plenty of detractors out there who gleefully point at holes in the methodology, highlight inappropriate shortcuts, and take pride in identifying errors. I’m tired of hearing from those people…not because they are incorrect, but because what they are correct about doesn’t matter. What those folks don’t realize is that being wrong doesn’t have much of an impact on the success of the program as a whole. Because being right is almost irrelevant.
You only have to be vaguely right – let’s say 25% for the sake of argument – to have a program that adds significant value for an organization. That’s because the real value of these programs is forging a common approach and methodology across the organization. Getting people on the same page and (to mix metaphors) marching in the same direction.
Let me put it another way. Take the usual assumptions about running a successful program. Any book, consultant, or expert will tell you that the following are needed (your list may vary):

The support of senior management
Top-notch training on the methodology
The best people assigned to the most important problems
Adequate resources, support, and budget
The focus of the organization for a sustained period of time
My point is simply this: if you manage to get all of those things in place, what you decide on as the content of the program is largely immaterial. You want to teach DMAIC? Fine. Want to make Lean your thing? Fine. Want to invent your own methodology? Fine. Want to have hula classes and a luau every Friday? Fine. It really doesn’t matter. The entire point of the program is to force the bullet points above to happen. Do whatever you have to do, call the program whatever you have to call it, just make sure those things happen. Because once they do, the rest is just details. Hula and luau can work just as well as Lean and Six Sigma.
This, ironically, is why Six Sigma has been so successful and so long-lived. Not because it is especially right - Lord knows there are holes in the philosophy and methodology you could drive a truck through. (1.5 sigma shift, anyone? CpK without control charts, anyone? I could go on…) But rather because it is very, very good at motivating the organization towards the goals described above. And that turns out to be much more important than being right.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Sun, 03 Aug 2008 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Cargo Cults]]></title>
			<link>http://blogs.isixsigma.com/archive/cargo_cults.html</link>
			<description><![CDATA[I can’t remember the first time I head the concept of a “Cargo Cult” used as a business analogy. But I can recall thinking that it was a powerful way to explain the dangers of throwing money and resources around trying to duplicate what another company had done without really taking the time to understand exactly what they did and why they did it. There were obvious applications to Six Sigma deployments in particular, since Six Sigma is rife with rituals and jargon.
And I was right. It was very effective. So I used the analogy in conversation, in training, and during presentations with great frequency for quite a while. Others were out there doing the same. At some point I became convinced that everyone in the world must have heard the story. Plus, I’m not a big fan of making arguments by analogy because you open yourself up to a simple, but devastating criticism. So for the past few years I stopped talking about Cargo Cults.
Then, the other day, I brought the Cargo Cult idea up in conversation again. To my surprise, no one around the table had heard of it, and they all reacted enthusiastically. I admit the possibility that the crowd was just being polite, but on the other hand maybe it’s time to polish this chestnut and put it back on display. If you’ve heard it a million times, you can stop reading now. If you haven’t…
I’m not sure if he was the first to do so, but Nobel Prize-winning physicist Richard Feynman eloquently described Cargo Cults it in his 1974 Commencement Address at CalTech as an evocation of science done badly:

"In the South Seas there is a cargo cult of people. During the war they saw airplanes with lots of good materials, and they want the same thing to happen now. So they've arranged to make things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head to headphones and bars of bamboo sticking out like antennas--he's the controller--and they wait for the airplanes to land. They're doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn't work. No airplanes land."
The entire speech is available here if you want Feynman's context, but it's not essential to the story.
An interesting fact (but also not essential) is that Cargo Cults are real. Wikipedia has some history, and also makes the following point:

"From time to time, the term 'cargo cult' is invoked as an English language idiom, to mean any group of people who imitate the superficial exterior of a process or system without having any understanding of the underlying substance."
If you’ve ever worked on a Six Sigma deployment, this has to sound familiar. How many deployments were launched simply “because GE did it”? And how many deployment were launched just like GE did it? I’m not knocking GE – quite the opposite. But for some other organization to simply mimic what GE did in an attempt to achieve the same results they did is the worst kind of Cargo Cult behavior. Still, it happens all the time, and is still happening to this day. And as detractors are fond of pointing out, the planes don’t land.
The power of this analogy arises for three reasons. First, the Cargo Cult story is fun and very easy to tell. Second, the link between Cargo Cults and Continuous Improvements deployments is easy to recognize. And third, there are so many botched deployments out there falling prey to the fallacy of Cargo Cult thinking that your audience will immediately start nodding their heads if you bring it up in conversation.
So, there you have it: the Cargo Cult analogy. Stifle a yawn if you’ve heard it too many times before, but try it out on your friends if you haven’t. It can be strecthed and pulled in a hundred directions to illuminate a hundred different points. Unfortunately, using it to talk about Six Sigma deployments doesn't require much stretching at all.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership]]>
			</category>
			<pubDate>Sat, 28 Jun 2008 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Simplicity]]></title>
			<link>http://blogs.isixsigma.com/archive/simplicity.html</link>
			<description><![CDATA[I was recently perusing Time magazines “Top 100” list for 2008, and came across this entry for Peter Pronovost. I had never heard of Pronovost. Here’s part of what profiler Kathleen Kingsbury had to say about him:

“A critical-care researcher at Johns Hopkins University, Pronovost may have saved more lives than any laboratory scientist in the past decade by relying on a wonderfully simple tool…”
I know what you’re are thinking, but no, Six Sigma is not the tool. Before I tell you what it is, consider that after implementing it in hospital ICUs in Michigan, hospital-acquired infections dropped from 2.7 per 1,000 patients to zero. That means more than 1,500 lives were saved in the first 18 months.
So what is this ingenious invention? What critical breakthrough occurred? What fancy bit of science and statistics produced these stupendous results? Which process improvement methodology was put to work? 
A checklist.
That’s right, Pronovost provided physicians with a list of steps as a reminding them how to complete routine procedures. 1500 lives were saved over 18 months in one state by writing down the steps for procedures, photocopying them, and handing them out. Pronovost estimates he could roll his system out across the entire US for three million dollars. Which, I think it’s worth noting, might be comparable to the annual budget for a corporate Six Sigma deployment in bigger companies.
One of the reasons I was so captivated by this story is that more and more, I find myself returning to the basics and fundamentals of process improvement methodology. I read the primary literature and wonder at the complexity of current process improvement methodology. I wonder where the power of elegance of simplicity has gone.
For example, one of my favorite books is Kaoru Ishikawa’s “Guide to Quality Control”. It’s long out of print, but you can still pick up used copies online and elsewhere. You might not know Ishikawa by name, but if you’ve ever done a fishbone diagram, you know his work. He introduced his now-eponymous diagram along with six other quality tools in the Guide. Each was elegant and simple. Things like check sheets, Pareto charts, scatter plots, basic control charts - simple tools explained concisely. It’s a slim volume, but everything is there. Every time I read it, I wonder to myself how on earth we’ve allowed the continuous improvement world to become so complex and unapproachable. I’m at a loss to explain what value Six Sigma and similar methodologies add to Ishikawa’s approach. Sure, they provide the sizzle that sells programs to organizations, but it’s quite possible that that’s all they do. Which is worrisome.
Ishikawa and Pronovost have proven that very clear and simple approaches can yield stunning results. Much as Deming and others did before them. Modern Six Sigma is anything but simple. Most Black Belts take four week to train. But I can get through Ishikawa on a flight from Chicago to Denver, and I’m guessing Pronovost can train his folks in about five minutes.
Have we taken a wrong turn?]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;History&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 22 May 2008 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Innovation and Six Sigma]]></title>
			<link>http://blogs.isixsigma.com/archive/innovation_and_six_sigma.html</link>
			<description><![CDATA[There has been a lot of ink spilled lately dithering about Six Sigma and Innovation. Most of it by naysayers who feel that Six Sigma is antithetical to Innovation, or zealots who feel some version of the opposite sentiment. For the life of me, I can’t wrap my mind around either position.
To illustrate my view, let’s talk about some other processes you find in most organizations – perhaps budgeting and talent development. Most businesses have at least an annual budgeting process and an annual talent development process. These are fundamental, and exist in most places out of necessity. Clearly the two have links: it takes money to develop and retain talent, and it takes high caliber people to manage all aspects of cashflow and propel the organization forward. Without good talent development there would eventually be no budget to allocate, and without good budgeting all the talent in the world isn’t going to matter after a couple of quarters.
So talent development and budgeting are both necessary for the success of the organization, but neither is sufficient. Hardly an interesting observation, right? Now suppose someone told you that “your budget process is killing your talent development process.” Well, it could be true, and if so you’d have to fix it. But suppose they went on to say that “talent development is much more important, so you should get rid of the budget process.” That’s ridiculous, right? The very idea makes no sense.
But that’s exactly the argument that is made regarding Six Sigma and Innovation. If I had a nickel for every article I’ve read concluding that Six Sigma kills Innovation so we should jettison Six Sigma, well, I’d probably have about a dollar. But you get my point.
There are two things wrong with this conclusion, regardless of how it is reached. The first one is described above. Six Sigma and Innovation are two separate but related processes that must co-exist in a healthy organization. Both are necessary and neither is sufficient for success. Suggesting that one should be pursued to the exclusion of the other is infantile thinking. I don’t care what you call the attendant programs, but new ideas need to be encouraged and developed, and continuous improvement needs to occur. Of course, Six Sigma can’t be the Innovation program either. Organizations that lack an Innovation program and try to make Six Sigma stand in for it are bound to be disappointed. If you have no talent development process, having a great budget process isn’t going to help.
So the first thing wrong with the conclusion that Six Sigma kills Innovation is that it suggests an opposition between the two processes, falsely implying a choice that isn’t there. You don’t get to choose one or the other. Both are necessary. The trick is to make them work together, just like budgeting and talent acquisition.
The second thing wrong with the conclusion is that, properly structured, Six Sigma and Innovation have an intrinsically synergistic relationship, not an antagonistic one. Just like budgeting and talent development do when properly executed. Despite what you may have read, process and structure are not natural enemies of Innovation.  Bad process and inappropriate structure…maybe those are enemies of Innovation, but then they are the enemy of many other things in the organization too. A bad Innovation program will certainly be a drag on your Continuous Improvement program, and vice versa. But as I have pointed out many times before, the conclusion that poorly run programs perform poorly is not useful or interesting.
It has been my experience that well-run Six Sigma programs generate a tidal wave of new insights and ideas. Indeed, managing the flow of those ideas becomes a central, consuming, happy problem for successful programs. This is true even when a very structured approach is taken. I’m reminded of a story I was once told about an author who decided to write an entire novel without using the letter “e”. You’d think this would be incredibly limiting, but in fact the author ended up learning many, many new words and taking his writing in entirely new directions. The structure forced him to break old habits and think in new ways.
A recent New York Times article by Janet Rae-Dupree makes this point in fascinating depth. Here’s a tease:

“So it seems antithetical to talk about habits in the same context as creativity and innovation. But brain researchers have discovered that when we consciously develop new habits, we create parallel synaptic paths, and even entirely new brain cells, that can jump our trains of thought onto new, innovative tracks.”
Far from killing it, a well-deployed Six Sigma program (or any structured approach to continuous improvement) can be a great partner to Innovation. The reverse point is also true, that Innovation can help Six Sigma. I’m not going to construct an argument to support my belief that Innovation is a necessary component of Continuous Improvement, as I take it to be true almost by definition.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[Buzz/Press&nbsp;,&nbsp;General&nbsp;,&nbsp;Innovation]]>
			</category>
			<pubDate>Thu, 08 May 2008 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The Consultant Within]]></title>
			<link>http://blogs.isixsigma.com/archive/the_consultant_within.html</link>
			<description><![CDATA[The state of the US economy notwithstanding, retention of talent is a major issue across many organizations these days. Operational Excellence, Six Sigma, and related disciplines are no exception, with a lot of the mobility fueled by the same high standards for training and certification that are intended to attract folks in the first place.
Indeed, that sucking sound you hear just might be the vacuum created as Black Belts bolt one manufacturing company for another. Or perhaps they’re leaving for jobs in healthcare and finance, both of which seem to be consuming experienced practitioners at an alarming rate. And if you are in China or other similarly hot economies, that sucking sound is probably closer to the wail of a hurricane, as the best talent ricochets from employer to employer with all the subtlety of a midnight freight train.
For the organization suffering defections, there are many downsides to this churn. Consistency is hard to maintain. Standards are hard to enforce. Long-term projects and initiatives are hard to complete. Relationships suffer. Departments break down. And organization memory shrinks to a pinprick.
Priority number one in this environment is, of course, to hold on to your talent. I won’t go into that lengthy topic (others could probably do it more justice anyway), nor will I tarry for an admittedly interesting discussion about why a lot of technical folks feel the need to hop employers to get ahead  in their careers (although I do think that is a fascinating phenomenon).
Instead I want to talk about the flip-side of the phenomenon, and why it can actually be a good thing for an organization. Even the best organizations lose people sometimes, and those people are generally replaced with people from other good organizations. So there is a constant stream of people and knowledge going back and forth. All of which means that, big or small, you probably have a lot of “outside” knowledge resident in your organization. This is old news, and I’m hardly the first one to point it out. But I think its especially true of continuous improvement professionals, and in my experience there isn’t a whole lot being done about it.
This is in part due to a love affair with outside consultants. Many of us were initially trained by outside consultants, and out first instinct in new situations is to look towards them. This is a familiar mode for all involved, but is very expensive and results tend to be mixed at best. What if there was a way to get exactly the same benefits with virtually no cost and very little risk? With as much cross-fertilization as there is going on between companies these days, the best consultants are probably already colleagues just waiting to be consulted. That’s always been the case, but it is exacerbated as the flow of talent is becomes ever more fast, furious, and global.
Like I said, this is hardly an original thought. But even so, I see a lot of consultants engaged for jobs that could very well be done just as well by internal employees. The missing link is a high degree of communication and organization, especially across geography and business functions. For example, if a large company needs 5S help in a plant in Chicago, it is very easy to go out and hire a consultant. But if the company is large enough, there’s probably a distribution center in Warsaw that has already been through a 5S journey and has plenty of expertise and experience to share. The trouble is that the folks in Chicago almost never know about the people in Warsaw. And even if that connection is made, doing something about can look pretty daunting. Getting the domestic consultant in is a lot easier. It may cost more, but it is the kind of cost that the organization is used to paying. 
All of which means that in an environment where talent and experience are migrating both in and out of the organization – like they are right now in Six Sigma and related areas – having the infrastructure and processes in place to identify and leverage expertise globally is at least as important as any other task a deployment executive has. You’ve got people coming in with new skills and experience all the time, and you need to be learning from them and leveraging what they know. You can be victim to the sucking sound, or you can profit from it. Setting up to do that looks and feel a lot different than a traditional deployment, but we’re no longer living in a world where big companies don’t have Black Belts or Continuous Improvement specialists. The question isn’t whether you have them, it’s what you know about them and what are you doing with them.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management]]>
			</category>
			<pubDate>Sun, 27 Apr 2008 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: A System Beyond Their Control]]></title>
			<link>http://blogs.isixsigma.com/archive/a_system_beyond_their_control.html</link>
			<description><![CDATA[Deming proposed his famous “Red Bed” experiment more than half a century ago. These days, videos and descriptions circulate freely via the web, and there are many books and other publications that describe the experiment. But even for those who are familiar with its lessons, the applicability of the experiment and what it teaches are as striking today as they must have been the first time it was run.
If you aren’t familiar with the Red Bead experiment, there’s a pretty good overview here. Briefly, the Red Bead experiment can be summarized like this...
Workers are asked to “produce” red beads by dipping a dimpled paddle into a large container full of beads. Management has set up “the system” such that the container is filled with a mixture of mostly red beads, but also a small fraction of white beads. Thus, when workers pull out their paddle, they inevitably pull out some white beads along with the red ones. Regardless of how workers try (and if you’ve ever done this experiment live, you’ll know that they do try), their paddles always pick up some white beads. In fact, the red bead experiment is set up such that there is very little that can be done by the worker to influence the results. The point, to paraphrase Deming, is that all workers perform within a system that is beyond their control.
Beyond that fundamental message, there are many, many things to be learned from the Red Bead experiment. Deming, for example, famously tracked the performance of various paddles over time, noting that even paddles that were “the same” regressed to different averages and standard deviations over time. Thus different workers in the same system who are ranked according to the defects they produce are being ranked on random differences attributable to the system, rather than on their own individual performance. This is just one example - Deming and others have taken the basic lessons of the Red Bead experiment in scores of directions to illuminate all sorts of lessons.
In my experience, the most common reaction to seeing, playing, or reading about the Red Bead experiment is this: so what – isn’t that obvious? And it is, of course. The genius of Deming’s set up is that it is completely, blindingly obvious what will happen. The genius is that is strips away all the smoke and mirrors of real life situations and makes the conclusions obvious. But even so, the lessons of Red Bead still haven’t sunk into general consciousness. Even for those of us who study it and ruminate on it, the lessons are easy to forget and hard to implement. This must be the case, because the experiment keeps repeating itself over and over again in real life, and we keep trying to blame the workers for the failings of the system.
Consider the recent foibles of trader Jérôme Kerviel and French bank Société Générale, described here in an account by the New York Times.
SocGen and Kerviel’s story has been smothered n coverage – a $7 billion USD loss will do that – and virtually all of the articles (including the one cited above) describe Kerviel as a “rogue trader”. In fact, a Google search combing the terms “Kerviel” and “rogue trader” turns up no less than 700-800 results.
But was Kerviel’s behavior really “rogue”, as in aberrant, different, or going against the usual behavior at SocGen? To be perfectly honest, I don’t have any sort of informed opinion of the answer to that question. I’m not well versed in the general area, and I had never heard of Société Générale before this story broke. But I do have a hunch. I can tell you that all the accounts and interviews I have read, including comments by other employees, indicate that the far from being rogue, Kerviel’s behavior and practices were encouraged and expected. My reading is that he was a classic manifestation of a system carefully crafted and maintained over time by SocGen. All of which makes the a classic case of the Red Bead experiment.
Let me be clear that this hypothesis did not require and special cleverness on my part. In fact, the New York Times article makes the same point:

While management depicts the 31-year-old Mr. Kerviel as a lone operator who spiraled out of control, interviews with current and former Société Générale employees suggest that he was also the product of an environment where risk taking was embraced, as long as it made money for the bank.
To put it in Red Bead terms, Kerviel was doing nothing more than sticking his paddle into the container and pulling it out. For a long time, he had seen a normal number of white beads come out. One day early this year, he stuck in his paddle like he had been taught to do (heavily rewarded for doing, in fact) and got a few more white beads than normal. Random variation is like that. But for Kerviel on this day, voila, he became an instant pariah. SocGen built the container, added the red and white beads, designed the paddles, and taught Kerviel how to put his in and draw it out. Kerviel what he was expected to do. In December he was up $2 billion. In January he was down $7 billion. Like I said, random variation is like that. So who should be made the pariah?
If you don’t like Red Bead, you can think of it in control chart terms. Standard six sigma control limits mean that normal variation will fall within the control limits 99.99967% of the time, right? Which means that one out of every 300,000 will fall out of the control limits with no attributable cause. Now, are there 300,000 folks like Kerviel out there? Or maybe 3000 who perform strings of trades 100 times in a year? If there is, then sooner or later one of them is going have results that fall outside the limits, just like Kerviel did. If that happens to go in the right direction, they get a huge bonus (like Kerviel probably did in years past). If it goes in the wrong direction, they get to be the subject of an uncomfortable article in the New York Times. Even though it is all normal variation, even though it is all the Red Bead experiment, playing itself out again and again.
Now, I certainly don’t mean to absolve Kerviel of guilt. What he did was clearly wrong; it threw up a number of warning flags and violated all sorts of rules. But it can’t be called unexpected in any way. It was a logical output of the system that SocGen built. Punishing Kerviel isn’t going to do a thing about that. Red Bead.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[Buzz/Press&nbsp;,&nbsp;General&nbsp;,&nbsp;History]]>
			</category>
			<pubDate>Fri, 21 Mar 2008 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Getting There From Here]]></title>
			<link>http://blogs.isixsigma.com/archive/getting_there_from_here.html</link>
			<description><![CDATA[It is the aim of most Continuous Improvement programs to transform the organization. Six Sigma usually attempts to do this in one of two ways:

By taking top-down approach, wherein the end state of transformation is articulated and communicated by organizational leaders, and stages and activities of the transformation are painted only in very broad strokes;
By taking a bottom-up approach, wherein the end state of transformation is either not clearly articulated or not known, but incremental activities within the transformation are planned and managed in great detail.
Of course, neither of these approaches can succeed on its own. But that doesn’t stop most organizations from trying one to the exclusion of the other. The approach chosen is often driven by the personal style of the figurehead for the transformation, which in turn is dictated by the general culture of the organization. While there are exceptions, it is rare to find a senior leader whose personal style diverges significantly from overall the organizational culture. This is for the simple reason that senior leaders typically don’t become senior leaders unless and until they learn how to fit in.
Intellectually, most people leading continuous improvement programs have the mental horsepower to figure out that neither approach works on its own. But realizing that and being able to do something about it are two different things. In my experience, leaders who are capable of giving birth to great and clear vision and rallying others to that vision are seldom equally capable of doing the detailed work necessary to actually get there. These folks can state with great conviction and clarity where we need to be a year from now, but they have no ability to describe what has to happen tomorrow and the next day and the day after that…eventually leading to the goal. They understand the destination, but not the route.
On the other hand, those who revel in the detail and are capable of writing the detailed plan to arrive at the destination are seldom equally capable of conceiving of and articulating a vision that will rally the organization. They understand the route, but not the destination.
The solution to this dilemma is clear: both skill sets are required, both things need to be done. You can’t choose one approach or the other of the two listed above, you need elements of both to succeed. We all know this. But doing it is excruciatingly difficult. It is very tough for a single individual to function equally well on both ends of the spectrum, and even tougher to put together a pairing or small group that does so.
I suspect many of you reading this will disagree with me, perhaps point out that all you need is a well rounded team of individuals with compensating strengths and weaknesses. But I just don’t see that happening very often, if ever, in real life. What I want to know is…why. Given that the solution isn’t hard to comprehend, why is it so difficult to make it happen?]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[Change Management&nbsp;,&nbsp;General&nbsp;,&nbsp;Leadership]]>
			</category>
			<pubDate>Sat, 26 Jan 2008 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Verisimilitude]]></title>
			<link>http://blogs.isixsigma.com/archive/verisimilitude.html</link>
			<description><![CDATA[I can save you the trouble of reading the blog entry below. I realize you are very busy. Here’s a summary:

Communications in the business world rely heavily on PowerPoint-style summaries.
At best, summaries omit crucial information and context present in the work being summarized.

Without this context, conclusions have to be accepted on faith.
At worst, summaries attempt to mask the fact that there is no foundational work to summarize in the first place.

This is usually an indication that the topic being summarized has not been explored with much enthusiasm, rigor, or depth.
PowerPoint-style summaries should be treated with great caution.
You’re welcome.
Business communications these days rely heavily on PowerPoint-style summaries. I can’t speak to non-business oriented bureaucracies, but I suspect the same is true of many of these organizations as well. Other, greater thinkers than me have already eviscerated PowerPoint as a cognitive tool (get yourself a copy of Tutfe’s essay The Cognitive Style of PowerPoint here, or read a bit about it here if you don’t want to spent the $7)
I don’t have much to add on that subject. But I do want to weigh in on what I perceive (anecdotally) to be a growing trend towards "high level" summarization of complicated subjects. And even though I already said I didn’t want to talk about PowerPoint, it’s almost impossible not to. PowerPoint is chicken to the egg of high level summaries prepared as bulleted lists.
The good news about well-prepared summaries are that they can distill a lot of complicated information down into a few concise, statements. Done well, this can turn voluminous data into relevant information, and relevant information into good decisions. But even when this is the case, more data and information is lost than retained. That has to be the case, otherwise the summary is useless. And unless the author is also the audience for the summary (which, outside of studying, is seldom the case), the process of summarization requires a whole string of subjective decisions that are not being made by those who require the output of the summary.
There are two problems with this. First, the reasoning behind those subjective decisions is seldom captured. Indeed, there may not even be any reasoning behind what stays and what goes. Which may or may not be okay, but failing to make the subjective reasoning explicit surely isn’t. Second, in the business world, summaries are almost always presented "up", which means the author of the summary usually has a vested interest in presenting "good" information. Summaries provide an excellent opportunity to do this, since they demand leakage of information. If 90% of the news is rain, it is possible to create a wholly accurate summary that is exclusively sunshine. Sometimes that isn’t just possible, it is required.
With both problems, the foundational issues is that a summary usually presents information devoid of the context and reasoning used to create the summary in the first place. This works well when the presenter and the audience are very much aligned in their thinking, or the basic assumptions required to create the summary are well-understood and agreed-upon. But these conditions are almost never satisfied, and when they aren’t summaries have to be taken on faith. In hierarchical organizations where “good” conclusions are rewarded, that’s a mighty scary prospect.
An even bigger problem is the growing number of "summaries" that masquerade as concentrated distillate, but don’t actually summarize anything at all. These PowerPoint decks inevitably state conclusions that seem to be commonalities teased from many observations, or numbers that appear to be statistics describing vast, carefully sampled populations. But ask a single question, scratch just below the surface, and you quickly find out that the surface is all there is. There is nothing being summarized at all.
Infinitely worse than the problems described above, this means that there was no context to be lost in the first place, no additional information to be omitted. No study has been conducted, no report prepared, no decisions made about what does and does not belong in the summary. There is just a series of semi-connected bullet points which, having been typed in PowerPoint and dimmed with each mouse click, inexplicably acquire a patina of veracity. There is an old word for this: verisimilitude. There’s a new one, too: truthiness.
Summaries are not inherently bad. Indeed, with the volume of information available in the business world today, summaries are often required for survival. When thoughtfully prepared and well-explained, summaries are a gift from the heavens to those drowning in data. But they almost never are, and it’s worth taking a step back now and then to think about what isn’t being included. Many times, the information left out, and the reasons for it’s omission, are just as interesting and informative as the summary itself.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management]]>
			</category>
			<pubDate>Tue, 01 Jan 2008 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Organizing Concepts]]></title>
			<link>http://blogs.isixsigma.com/archive/organizing_concepts.html</link>
			<description><![CDATA[A conversation I regularly get into involves discussion of the difficulties encountered when deploying Six Sigma in an environment that is already saturated with other programs and toolsets. A majority percentage of the time the discussion is about deploying Six Sigma in an area where Lean is already well established, but there are many other variations out there.
Certainly it is possible to create conditions where Six Sigma plays nicely with other disciplines. First order combinations like Lean Sigma and its many variants are an example of this. So are higher order hybrids, like Design for Lean Six Sigma Using Triz. And from an intellectual perspective, there is a lot of appeal to this approach. If you think about it hard enough, there are significant synergies to be explored and interesting combinations to be leveraged.
But from a practical perspective, I’m not so sure. For my money, a significant amount of the value of a program like Six Sigma comes from its ability to function as an organizing concept. It gives the organization something to rally around. It crystallizes diverse thoughts and aligns what might otherwise be diverse efforts as improvement. Six Sigma has value simply as an excuse to get everyone thinking about problems in the same way. Diverse groups come together through training programs to have prolonged discussions about approaches to problem solving. Results (and lack thereof) start to get visibility. Executives take an interest. People on the shop floor get involved. Everyone goes on the journey together. Even if you don’t think that the content of Six Sigma is useful, the cohesion of thought and action it produces clearly has value.
The thing is, this is true of almost any program properly deployed. Lean will certainly do it. Numerous safety programs do it. Good business transformation initiatives do it. Implementation of major systems like SAP or Oracle do it. Assuming you can execute, the one thing you need to get this sort of benefit is a simple, compelling organizing concept. Or to put it more colloquially, you need an approach. The simpler and more persuasive, the better.
If you buy this line of thinking – that a large part of the value of any particular organizational program lies in the fact that it is a program at all, not in its content – then the question of how to deploy multiple overlapping programs becomes easy to answer. Don’t do it. If you already have an organization succeeding with Lean, don’t mess with it by deploying Six Sigma on top. You’ve got your organizing concept. Adding another program on top (or even worse, visibly switching to the new program from the old one) can do nothing but detract from that focus. Simpler is better in terms of rallying a group around a way of thinking, even if there really are synergies to be explored through more complicated approaches.
Don’t get me wrong – I’m not suggesting that new toolsets and approaches shouldn’t be added in over time, and that new techniques shouldn’t constantly be considered. But I am suggesting that moving too far away from an organizing concept that is already working well is a mistake to be avoided.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Lean]]>
			</category>
			<pubDate>Thu, 08 Nov 2007 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: To p Or Not To p]]></title>
			<link>http://blogs.isixsigma.com/archive/to_p_or_not_to_p.html</link>
			<description><![CDATA[Let me end the suspense: not to p. At least for me. Also not to F. And not to t.
I got thinking about this topic after reading an article in the Wall Street Journal about “sloppy analysis” in scientific studies. That article is here, but you'll have to pay to see it. However, the primary source for the article, available here, is an open access study by John Ioannidis. What originally caught my eye in the Wall Street Journal article was this zinger:

Statistically speaking, science suffers from an excess of significance. Overeager researchers often tinker too much with the statistical variables of their analysis to coax any meaningful insight from their data sets. "People are messing around with the data to find anything that seems significant, to show they have found something that is new and unusual," Dr. Ioannidis said.
This situation sounded very familiar to me. In fact, substitute “Six Sigma” for “science” in the first sentence and I think the passage becomes even more true. We, as a Six Sigma community, rely far too much on formal tests of statistical significance to tell us what to do.
Statistical significance is nothing more and nothing less than a comparison of one thing to another. A comparison of a supposed “signal” to observed “noise” is the classic example. What gets forgotten is that when we experiment or otherwise collect data, we have complete and total control over what goes in both buckets. We decide what gets counted as signal, and what gets counted as noise. So the results depend entirely on how we sample. And there is no statistical test that can assess significance with this in mind,  because it's not a statistical question. It's a practical one. Want better p-values? Sample differently. Want to make your F-test look good? Or bad? Change how you collect the data. Want that t-test to have a different result? Run the study again. Go ahead. Try. It's really easy.
Don't believe me? Check out Ioannidis’ study, which goes into much greater depth on this topic than I have the time (or admittedly, the intellect) to do. And note in particular the comments about lack of replicability of most studies, regardless of p-values. In other words, a study with a high p-value is no more likely to repeat than one with a low p-value. And the standard of p must be less than 0.05 has no practical relevance at all. To anything. Scary, right?
Now don't get me wrong; I certainly don't intend to condone manipulation of data to make things “look good” or support some pre-determined outcome when they really don't. But on the other hand, I want to be very clear that blind faith in statistical test is just as bad. If you are letting software make business decisions for you on the basis of a p-value or F-test, you are behaving foolishly. After all, who made up the rules about what does and doesn't constitute statistical significance? What were the circumstances, and what were they trying to do? Unless the circumstances were the same as yours and they were trying to do the same thing you are, you should make up your own mind. What your software package happens to think about statistical significance out to be immaterial.
So what good are these tests of statistical significance? Well, for enumerative work on historical datasets they can be useful. But in the world of Six Sigma where we are charged with predicting the future behavior of a process, let me be clear: they aren't much good at all. You should be making your own decisions on what is and isn't significant in your data. This will be based on tolerance for risk and how well you have sampled the process, among other things. You need to fully understand the level of knowledge you have based on your sampling strategy, assess your confidence in your conclusions accordingly, and make the best decision you can about how to proceed based on the particular situation you are in. Beyond some basic number-crunching, these are practical questions and concerns, not statistical ones.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Sun, 23 Sep 2007 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Candy]]></title>
			<link>http://blogs.isixsigma.com/archive/candy.html</link>
			<description><![CDATA[Things that make you feel good in right away aren’t always beneficial in the long run. Some things, like candy, are actually harmful in the long term. While others, like getting the high score on Space Invaders, just don’t end up mattering very much. You feel good as they are happening, but beyond that they don’t improve your life too much. A lot of things that make us feel good fall into this category. Maybe even most things.
Now this is hardly news. It’s not a novel insight into the human condition. But it is remarkably tough to remember in the moment. Human nature makes it very difficult to pass up short term gratification in favor of long term rewards. Especially when those long term rewards might require not only missing out on short term pleasure, but perhaps even opening ourselves up to short term pain. It’s one thing to understand the equation on an intellectual level, but quite another to have the discipline to put it into practice. After all, who doesn’t like candy?
So what does this have to with Six Sigma? Well, even in the best intentioned organizations, people like candy. For deployment leaders, that means there is strong temptation to dispense instant gratification to the organization. Training programs that are short, snappy, and enjoyable. Projects that deliver immediate return on investment. Minimal disruption. Quick results. Excitement. Fun. Candy.
How powerful is this temptation? Very. And enablers abound. Consider, for example, the graphic below, which appears on the homepage of SBTI. What does it suggest? That within five months (roughly), return will exceed investment. That within twelve months, return will be more than three times greater than investment. In short, it suggests candy. Which I suppose might be okay, if that’s what you are looking for. And if you are a deployment leader, it probably is what your boss is looking for.

The trouble is, just because our kids want ice cream for breakfast every morning, feeding it to them doesn’t make us good parents. The entire point of an intensive methodology like Six Sigma is to go after difficult, thorny problems. The kind that have been around for a long time. The ones with solutions that are not obvious. The ones that require time, effort, expertise, creativity, deep thought, and hard work to solve. For goodness sake – if you have a list of projects that can be easily solved and deliver return on investment within five months, what on earth are you messing around with Black Belt training for? You don’t need Six Sigma, you just need focus.
Perhaps the most concrete manifestation of this phenomenon is Six Sigma training. Those of you who have lived through Six Sigma deployments, tell me if the following conversation sounds familiar: “Black Belt training? Way too long – we can’t spare our people for four months.” How about Green Belt training? “Two months is better – but how about we do the second week online so they don’t have to travel?” Well…I guess we could… . “In fact, can we do the whole thing online?” Um, not really… . “Perfect! And we can get champions through in a single day, right?” Curricula shrink to the point of becoming series of self-evident statements spread over PowerPoint slides. Any sense of challenge and achievement disappears. The chance to modify the behavior of a class over a significant time period evaporates. But, boy, do we ever get good a delivering a snappy one-day class.
If you think I’m exaggerating, I encourage you to troll the websites of major and minor providers of Six Sigma training today. You’ll find a lot of candy. Six day, online MBB certification, anyone?
You already know where I’m heading with this. Like I said in the beginning, it is something we all realize intellectually. It’s just tough to actually do it. Our job as Six Sigma professionals can’t be to dispense candy to the organization. No more ice cream for breakfast. Even though it’s no fun for anyone involved, we need to become the bringers of organizational All Bran. We all know what to do, we just need to have the courage to do it.
(One final note: Shortly after I wrote this entry I stumbled across this article by Mark Kiemele on the Air Academy website, which makes many of the same points I make here.)
 ]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Sat, 25 Aug 2007 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: For Example]]></title>
			<link>http://blogs.isixsigma.com/archive/for_example.html</link>
			<description><![CDATA[If you do any sort of training, you’ve probably struggled to come up with good examples to drive a concept home. Nothing crystallizes difficult material like the perfect example to make it all real. Every train-the-trainer workshop you’ve ever been to has doubtless spent time worrying about this. And if you’ve ever been through the experience of having one of your carefully constructed examples picked apart at the front of a training room, you’ll know that it’s important to think hard in advance about examples you are going to present. Very hard. Because having your example unraveled is not pleasant, especially when a few dozen sets of eyes are watching you every step of the way.
Many trainers confuse analogies with examples. Personally, I try never to rely on analogies to prove a point. Why? Because by definition, situations that are analogous are different. Same with similes and metaphors. If you find yourself arguing some point by saying “a project is like running a race…”, I guarantee half of your audience is thinking “no, it’s not”. And they are right. Projects are not races. They aren’t fruit either, and they can’t be “low hanging” or “sweet”. And managing using Cpk is nothing like parking a car in a garage. I could go on, but I probably don’t have to. I’m sure you’ve seen all the classic PowerPoint slides just like I have. Points made this way are inherently weak because if pushed, analogies cannot possibly hold. Even a mild inquisitor can undo you. Sure, use these devices to illuminate and enrich understanding, but don’t base your arguments on them. You need a more solid foundation.
Which brings us back to examples. Examples have a weakness too, which is that they are inherently specific. For every example that fits your argument, there will be another example that does not. So selection of illustrative examples in the context of training becomes very important. Not only do your examples have to be clear, concise, and obviously linked to the concepts in your material, but they have to be persuasive enough that folks can easily generalize from the specific to the general. That’s a tall order.
If you ask most audiences, they will tell you that they want examples that are clearly related to their work. Put another way, they want examples that are almost the same as what they will have to do in real life. Fair enough, but as a trainer, it is practically impossible to deliver those kinds of examples unless you have a lot of prep time, a very homogeneous audience, and a big library of examples to work from. If you are teaching a lot of classes in a row, or if the folks in those classes are working on different things, or if you are treading new ground, forget about it. There’s not enough hours in a day to do it right!
Happily, there is a way around this problem. One so blindingly obvious that a lot of people miss it. Eliminate the examples altogether and work on projects live, in class. Make all the points you need to make in real time, using actual situations being encountered right now. Go straight from presentation of the concept to application in a real situation. Know your project portfolio like the back of your hand, and rely heavily on project reviews to back up your points. This is old news to folks who run kaizen events, where the journey from theory to application is often measured in minutes. But for whatever reason it seldom seems to happen in longer Six Sigma training courses. Too, bad because it’s an extremely powerful way to make points. Not instructor friendly at all, but much more powerful in the long run than prattling on about making cookies to explain interactions.
The downside to this approach is that, in the short term, folks in the class don’t like it very much. People want the comfort of easy, familiar examples. Skip those examples and your scores on end-of-class surveys will plummet. Be prepared for that. You might even lose a few people entirely. Possibly those already on the low end of the distribution, and probably those that aren’t doing project work like they should. But who you should be catering to anyway? And is the job to change behavior and deliver results, or make participants feel good?]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 01 Aug 2007 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Documentation Dilemma]]></title>
			<link>http://blogs.isixsigma.com/archive/documentation_dilemma.html</link>
			<description><![CDATA[“Dilemma” is term properly reserved to describe a situation in which we must choose between two more-or-less equally unpleasant alternatives. This pretty much sums up how most organizations feel about documentation for Six Sigma projects.
On the one hand, there is always an organizational craving (note that I am specifically avoiding the term “need” here) for templates, documents, forms, and metrics that can feed the dreaded “roll-up” of information. These roll-ups often result in dashboards or scorecards that are supposed to be used to make decisions and steer a program.
On the other hand, there are Black Belts and their teams who are probably already working 16 hour days and still not finding enough hours to get everything done. They are digging deeply into problems and opportunities using techniques and tools they have been trained to use at great expense to the organization. They see documentation mostly as a distraction (“non-value-added work,” they will knowingly mutter) and something that takes away from their more important tasks.
A dilemma indeed. On the surface of it, the organization has to choose between having limited visibility and little information on which to base decisions, or saddling the “best and brightest” with a lot of busy work filling out incredibly repetitive templates and forms. Neither alternative is palatable.
In a sense, the answer is simple: strike a balance. But from what I’ve seen, finding that balance is very tricky, and organizations rarely get it right.
Part of the problem is that often the higher one goes in a company, the more simple and summarized information becomes. This phenomenon drives a pyramid of information collection in which many people at the bottom scramble to produce information and reports in a pre-determined format at whatever frequency is seen as “necessary” to a small audience at the top. The “roll-ups” thus produced containing a surprisingly small amount of information which may or may not accurately reflect what is actually going on. This is almost certainly not what the folks at the top want to have happen, but it’s usually what does happen.
At the other end, Black Belts and template designers often prefer to provide information that is easy to provide, rather than what is useful. Automated software “solutions” are terrible for this, enabling the tendency rather than reversing it. For example, many electronic dashboards ask users to enter project phases so they can show a roll-up of, for example, what percentage of projects are currently in the “improve phase.” This is what I like to call a “feel good” metric; it doesn’t really mean anything, so the presenter can spin it any way they want to make the audience feel good. Number of projects in the improve phase going up this month? Great! We love improvements! Number of projects in the improve phase going down this month? Great! More project proceeding towards completion! I can’t imagine a scenario in which we could make a decision based on a metric like this, but it makes us feel good to see it displayed (in color) on a dashboard. Trouble is, it takes a huge number of people building and maintaining projects plans, then doing data entry on a repeated basis, to generate the dashboard. It’s a huge investment of time just to make a few people feel good.
And no small part of the problem are the template-and-form crowd (which includes me, by the way). Buy a few drinks for your table at any Six Sigma conference and you’ll soon hear a litany of complaints about being forced to re-format templates so they are in the “right” font, or fit on two pages instead of three, or meet any number of other arbitrary requirements. Black Belts hate doing all this, and the people who have to provide the roll-ups hate it when Black Belts don’t do it.
So what to do about all the dilemma? Like I said above, the answer is simple: find the right balance. Design project tracking processes to be minimal in terms of the work required. Ask only for information that will inform decisions at some level. Provide a mechanism to flag problems and exceptions when they arise rather than monitoring whatever is convenient to monitor. Roll-up where you need to roll-up, but don’t assume the recipients of that rolled-up  information are incapable of understanding complicated relationships between variables and non-intuitive conclusions. In short, treat documentation like a process, strive to manage the inputs and outputs, and keep your Lean and Six Sigma hats on when you do so. Easy to say, very hard to do it right. ]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 28 May 2007 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: VOC Gone Wild]]></title>
			<link>http://blogs.isixsigma.com/archive/voc_gone_wild.html</link>
			<description><![CDATA[It seems "Voice of the Customer" (VOC) is a label applied to almost any interaction between a business and a customer these days. Anything from direct interaction to the vaguest involvement along the periphery.  Anything from highly structured, planned, and observed interactions to informal, anecdotal, and third-hand accounts.
Some VOC is certainly useful. But more and more, my experience with VOC as it is typically gathered and used causes me concern. For one thing, I find VOC usually ignores even the most basic statistical thinking - especially special cause/common cause and notions of representative sampling. But even if we assume the best VOC methodology, there are two additional problems:

Customers usually aren’t well qualified to tell us what they want. What customer ever stood up and said they wanted an iPod? Or eBay? Or Facebook? And even when customers can accurately articulate what they want, it’ not always something that is practical or wise to deliver. For these reasons among others, direct VOC may be very useful for incremental innovation and improvement, but in my opinion it’s a unreliable path to breakthroughs.
The definition of "customer" is more difficult than it first appears. For example, are shareholders of public companies customers? Surely they are. And surely hearing their "voice" is not difficult. They vote each and every day on the markets. And we don’t have to conduct special studies to know what they want - most companies report to shareholders every quarter, and the shareholders make it instantly and extremely clear what they like and don’t like.
This second issue is especially problematic. Take airlines. Traditionally we think of the customer of an airline as the person flying. But obviously airlines don’t care too much about the voice of these "customers" - if they did, air travel would be a lot different. Every seat would be roomy and comfortable. Food and drink would be plentiful and of high quality. Airlines would do everything in their power to take off and land every flight on time, including having extra planes and crews on standby at every airport.
So why aren’t things this way? Because the actual customer being served is the shareholder, who demands that airlines do only what is necessary to be profitable and deliver results quarter by quarter. The shareholders care nothing for the voice of the flying "customers" - indeed, the average shareholder almost certainly has no idea how to run an airline or serve the flying public. In fact, given the prevalence of mutual funds, pension funds, and similar investment vehicles, it is doubtful whether most shareholders even know they own a given stock. But even so, they definitely want their stocks to rise. And despite thier mostly irrational behavior, it is these customers that make their voice know most clearly, and drive the most behavior by businesses.
The thorny part is that the actions that will make the stock rise can be very different from the ones that would make flying passengers happier. Diametrically opposite, even. Of course, the airline can’t lose market share - no one involved wants that - but if all airlines offer equally poor service and the total number of people flying still increases each year increases, then the rate at which customers come and go from any particular airline isn’t likely to matter (at least among the big players). I have virtually no knowledge of the airline industry, but I’m guessing this is the situation we’re in. And because of this, the voice of the shareholders becomes much, much more important than the voice of the flying customers, and we get the kind of airline service we have today.
As I said, I’m not an expert on airlines by any means, and anyone who is should feel free to pick apart my example. But the root cause stands, regardless of the specific example chosen: customers in general, whether shareholders or consumers, are unlikely to know anything about the business they patronize or own. And because shareholders demand only that stocks rise quarter by quarter, regardless of the good of the business in the long term, they are very likely to demand behaviors that directly injure "customers". Examine any publicly held company and you’ll be certain to find similar tension between these different groups of "customers", and neither group is particularly concerned about the long term well-being of the business. All of which means that reading too much into VOC is a very risky proposition.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Sat, 05 May 2007 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The Next Next Big Thing]]></title>
			<link>http://blogs.isixsigma.com/archive/the_next_next_big_thing.html</link>
			<description><![CDATA[Six Sigma critics are right about one of their chief complaints: the program is a re-packaging of a lot of tools and ideas that have been around for a long time. Personally I don’t think that’s a bad thing, since many of the ideas that have been re-packaged were languishing before. Regardless of where the tools and ideas originally came from, the hype of Six Sigma has driven a lot of useful activity in areas where it wasn’t happening before.
Trouble is, the same thing is happening in a lot of different areas. Six Sigma as a program has several analogs, some competing and some in areas that Six Sigma hasn’t reached yet (like software design). You could argue that each program is different, but I would counter that even if that’s true, all of them have a similar aim. You could also argue about which of them is best; indeed, a great amount of energy seems to go into this argument every day.
But back to the aim. Beyond the specific project-level objectives of each program, what they all seek to provide is a conceptual framework. They collect different tools and ideas and put them together in a way that tries to be easily comprehensible. Lean does this. Six Sigma does this. 5S does this. SMED does this. 23 other continuous improvement programs do this. All of which leads to another question: what do you do in an organization that has Lean, Six Sigma, 5S, SMED, and all 23 of those other programs?
This is not hyperbole. In more and more organizations with good programs in individual discipline, it is a real problem. Just as Six Sigma provided and organizing framework for of a lot of disparate ideas and tools, we now need something to organize the various organizing frameworks. Failure to do this results in lack of alignment and missed synergies at best, and utterly disconnected silos working in opposition at worst. And it tends to be very difficult to address, because everyone involved is already genuinely working towards continuous improvement to the best of their ability. Change management experts will tell us we need a burning platform to make change happen – that’s unlikely to be the case in this scenario.
So what to do? How do we move up the next level in the hierarchy of organization? Once the Six Sigma program is running on all cylinders, the SMED team is in a groove, and the 5S group is having wild success, how do you tie them all together without killing the individual components? The obvious answer is not to let it happen in the first place. But in organizations of any size, it has almost certainly already happened. And it happens precisely because people on the ground want to do the right thing.
I don’t have the answers yet, but I think I’m coming closer to asking the right questions.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 26 Apr 2007 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Global Process? No Such Thing.]]></title>
			<link>http://blogs.isixsigma.com/archive/global_process_no_such_thing.html</link>
			<description><![CDATA[The first business process I ever put together was heavily indebted to Kevin Costner. If I build it, I figured, they will come.
And I did build it. A perfect process, polished in every detail. A global process, that everyone involved would adopt. A useful process, that would solve many disparate problems in a foul swoop. The documentation gleamed. The diagrams leapt off the page. The prose flowed like a swift mountain stream. It was a thing of beauty. Everyone was going to do everything the same way, and life would be perfect. But no one came.
In fact, my first process was a complete and utter flop. Despite being well thought out (all the right people were involved), well designed (people smarter than me worked on it), and otherwise pretty solid on paper, we ended up building a road that led precisely nowhere. Why? Because we set out to design the fabled “global process.” And it’s taken me a long time to learn why that almost never works.
The idea of global process is enchanting. Left alone, most organizations will develop several variants of even the simplest common processes. Over time, this leads to variation in output, inability to communicate between areas, and eventually a move away from the very idea of process as “a repeated set of actions.” The endpoint of this progression can be chaos, and chaos is mighty hard to manage.
Faced with this possibility, global process seems like a very good idea. The higher you go in an organization, the more fervent the desire to have everyone doing things the same way. And as the experience I described above illustrates, it’s not hard to put a team together to develop a good single process that maximizes benefit to everyone involved.
But once you have that global process in hand, a thorny questions arises. What do you do with it? A good process that exists only on paper is useless. Change management and similar methodologies can help us a lot here, but whatever the new process is and whatever methodology we use to deploy it, we have teach individuals to interact with the process. And it’s generally right around this point that global anything goes out the window.
It has to. Process lives in individuals. As any line manager can tell you, even if you have only 10 individuals to worry about, you can easily spend your entire day trying to get folks to operate a simple process in a consistent manner. You might accomplish it in a technical environment through rigorous, ongoing training and techniques like poka-yoke. But in a transactional or business process environment you wouldn’t have a prayer. Now what about 100 people? Or 10,000? Or 100,000? You get the idea. Unless you intend to hover over every one of them every moment of the day, you can toss the notion of global process out the window.
I suspect the halls of most corporations are littered with the skeletons of global processes that fell prey to this failure mode. It’s incredibly common. Teams are chartered every day to design processes that never achieve the intended result, or even see the light of day. So what do we do about it? How do we get around the paradox that even global process must necessarily be customized to the environment of every single user?
For me, the answer can be summed up in a word: robustness. The best place to start is not by asking “how can we make everybody do the same thing?”, but rather by asking “how can we accommodate the differences that we know are going to exist anyway.” Or by asking “what do we absolutely have to make consistent?” rather than “what can we make consistent?” This subtle difference in thinking can have a profound effect on the outcome of process design.
Take project tracking. Most Six Sigma programs tend towards forcing all projects into a global tracking system; everyone is asked to do it the same way, with the same templates, forms, deadlines, etc. This is a logical response to the question of “what can we make consistent?” The answer is “just about everything.” But if you scratch below the surface of this supposedly global process, you’ll either find a team of people running hard (and probably failing) to try and make everyone do everything the same way every time, or a lot of practitioners simply ignoring the global process. If you don’t see one of these things, you’ll almost certainly see the other. Which is why global process usually doesn’t exist in practice, although it’s alive an well in theory.
But what if we design our system by asking a different question: what is the smallest number of things we can get away with making consistent? The answer is usually a tiny subset of the things that we could make consistent. Maybe we need a few pieces of crucial information on each project at a particular time to feed our roll-ups. Maybe we need a consistent way to view progress towards goals. As for the rest…who cares? So what if everyone does it differently? Does it really matter if a Black Belt working on widgets in Wichita uses the same PowerPoint template as a Green Belt working on new hire provisioning in New Hampshire? Does it matter if their team meetings have the same agenda? Does it matter if they follow the same roadmap? Not to me, and I suspect not to anyone. And furthermore, the chances that I can optimize the process for every environment better than the person actually doing the work are vanishingly small.
Armed with this realization, I figured I would work towards an 80/20 rule. That is, I’d build in robustness by leaving 80% of the process local in nature, while doing my best to maintain global consistency around the remaining 20%. In other words, for every 1 thing I was prepared to insist folks do my way, I tried to leave 4 things that they could do however they wanted. This made a tremendous difference in my day-to-day activities (wow – I have time to eat lunch again!) and an even bigger difference in the reception I got. Managing change became a whole lot easier, because the magnitude of change at the individual level was minimal. But the process still looked global from above, much more than when I was trying to make every single thing consistent. It really was paradoxical. It felt like I was doing a lot less work and catalyzing a lot less change, but the outcomes were far more successful that when I had tried to make everything global.
Think of this as the YouTube approach. To get something on YouTube you need meet only a tiny number of consistent criteria. Your content needs to be video, and you need to be able to upload it via the YouTube interface. What device captures the video? Doesn’t matter. What kind of computer do you use? Doesn’t matter. How do you describe it? Doesn’t matter. When should you upload it? Doesn’t matter. I could go on, but you get the idea. The very little bit of global process that YouTube employs meshing with the massive amount of customization done by the user, which has the effect of democratizing the process as a whole. And paradoxically, this makes the process seem globally consistent, even though it’s almost entirely different for every single person. This is intelligent use of robustness in process design. And it works beautifully.
If those initial efforts taught me one thing, it was that I hadn’t gone far enough. I now tend towards a 90/10 rule, and I’m toying with a 95/5 rule. It works for YouTube, and it’s been working for me.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Fri, 23 Mar 2007 00:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: On Averages]]></title>
			<link>http://blogs.isixsigma.com/archive/on_averages.html</link>
			<description><![CDATA[(Or “On Arithmetic Means”, if you prefer.)
I hardly need mention in this forum that as a standalone descriptive statistic, the average can be a dangerous piece of information. Averages quoted in the absence of other descriptive statistics are generally insufficient at best, and downright misleading at worst. I’ll skip the lecture on the importance of variation and related topics (Wheeler already has it nailed in this book anyway), but I do want to focus on one particular aspect of averages that I find a lot of people forget. Including me.
A lot of the time, the average never occurs.
For example, the average weight of the four residents in my household is 31 pounds. No, we aren’t long lost Lilliputians – in fact, no one in the house (me, my wife, the cat, the dog, 6 fish) weighs anything close to 31 pounds. Or to paraphrase the old joke about statisticians, on average they feel like the temperature is just fine if they are sleeping with their head in the freezer and their feet in the fire.
To a statistician or Black Belt or anyone else suitably well versed on the topic, this is hardly earth-shattering news. But to some people, the fact that a statistical average isn’t synonymous with a “usual” or “typical” value within the population is surprising. And even to those of us who know better, this fact can be a slippery one to hold on to.
Mathematically, the fact that the average might never occur in a population is not hard to understand or explain. And I don’t have trouble remembering it mathematically. The mistake I tend to make is conceptual.
Suppose, for example, you are designing a project tracking process. You might be using Excel spreadsheets and creating a home-grown solution for a dozen projects, or working with a vendor to roll out something much bigger and more complex for hundreds of projects. Either way, in my experience the tendency is to design the system for a project with “average needs” and “average complexity”. The problem is that the "average project" isn’t in your portfolio – it’s an entirely hypothetical entity. Design for it, and you’ll have a solution that perfectly fits a need that doesn’t exist.
Another example is assigning pre-work before Black Belt training. Sure, we might know what the “average person” needs to do – we’ve almost certainly designed our class for the “average participant” who has an “average background”, right? But our classes don’t fill with average people. They fill with some people who know a lot and don’t need much pre-work, or with people who don’t know much and need a lot, or for people somewhere in between. Assigning the same pre-work to every person will serve none of them adequately. We’d be far better off assessing each individual and offering a range of options based on specific needs. But for whatever reason, that's almost never done. We get stuck on the "average need" and cater to it exclusively.
In both of these cases, the problem is that we use summary statistics like the average even though probably we shouldn’t be summarizing at all. If we are interested in accommodating every member of the population, what business do we have basing anything on summary statistics anyway? The entire point of many summary statistics is that they hide variation and complexity – they hide the mess, if you will. But sometimes the mess is exactly what we need to see and deal with. Which is counter-intuitive, and counter to a lot of the training we Six Sigma folks give and receive. 
(For some related thoughts on this topic, see Holly Hawkins last blog entry. Standardization is not always the answer!)]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 21 Feb 2007 00:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Off The Map]]></title>
			<link>http://blogs.isixsigma.com/archive/off_the_map.html</link>
			<description><![CDATA[If you’ve read some of my previous blog entries, you’ll know I’m no fan of roadmaps. I used to think this was a radical proposition in the Six Sigma community. But more and more, when I talk to practitioners – the people on the ground who do the hands-on work of process improvement – I am finding that this opinion is perhaps not a minority view after all.
Yes, this is even true of DMAIC, the Lord’s Prayer of Six Sigma that is etched into Black Belt brains around the globe. And to be perfectly clear, I realize that in many places DMAIC is considered past its prime, having been supplanted by various Lean-Six Sigma hybrid roadmaps, or design roadmaps like IDOV and DMADV. To be fair to acronyms of all stripe, I’ll go on record and confess that it’s not any one specific roadmap I have an aversion to, it’s the use of roadmaps in general.
To be sure, roadmaps do have several advantages. They’re easy to teach. They lend themselves well to dashboard displays. They provide and easy point of reference for senior executives and other stakeholders. They make projects seem like they are progressing. And they’re a crutch, especially for beginners. But beyond this last point (which I’ll get to in a minute) I don’t think they’re especially useful for the people actually doing the work. In fact, in my experience, they lead to a lot of waste as folks “check off the box” on various tools in each stage of the roadmap as opposed to doing strictly what is necessary to advance the project. And on the flipside, they let people get away without thinking through the best approach for themselves. Think of it this way: the roadmap is an a priori answer to the question of “how should this project be done” that utterly ignores variation in circumstances. For the life of me, I can’t understand why we as a community believe it’s going to be the right answer in more than a few lucky cases.
Then again, maybe we don’t believe it. When I’ve asked around, I’ve found that projects that truly follow a roadmap are far and few between. This is puzzling, given the standard Six Sigma dogma. But it has been my experience that the vast majority of good work going on out there involved subverting whatever roadmap it’s supposed to be following. Experienced Black Belts regularly skip stages, do them out of order, repeat them, and add new ones of their own invention. Master Black Belts speak in hushed tones about projects that succeeded after a simple visual display of data showed what changes needed to be made. Green Belts sometimes find that they need to work on the measurement system again after doing some “improve” work. Gasp!
My point is that disregard for roadmaps is an open secret. Turns out my views are probably within the distribution after all. Given this is the case, what I can’t figure out is why roadmaps are still peddled so aggressively in the Six Sigma community. If every project is an exception to the process, why are we still teaching the process? Why not embrace the freedom of a non-roadmap approach?
Don’t get me wrong: I love organizing concepts for continuous improvement work, and understand the necessity of having something more than a random collection of tools. I’m especially enamored of iterative models like the scientific method and PDCA. (Even DMAIC becomes a lot more palatable to me if we admit MAI are likely to iterate along parallel paths between D and C, but that’s a pretty messy acronym.) But beyond that, I think what we ought to be doing is encouraging folks to understand data: collection, display, analysis, uses and abuses of data. We ought to be encouraging them to think for themselves what sequence of steps are necessary to get through a project, what data are required, and how those data should be collected and analyzed. And if we want folks to truly get good at this, I contend that handing them roadmaps when they start out hinders rather than helps the journey.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 01 Feb 2007 04:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Reports of Our Demise]]></title>
			<link>http://blogs.isixsigma.com/archive/reports_of_our_demise.html</link>
			<description><![CDATA[Okay, okay. I know this has already been covered to death in other blogs and various discussion forums. But I am nonetheless compelled to offer my own take on the Wall Street Journal’s article concerning the departure of Home Depot CEO Robert Nardelli. And more specifically on the comments within that article suggesting that this is a substantial example of Six Sigma “not panning out as promised.”
The article prominently cites a study conducted by QualPro Inc. Before I get started, I’ll freely admit I haven’t read the study. I couldn’t find it on their website, or anywhere else online. (If anyone knows where to get it, please let me know.) So, I’ll have to rely on the words of the article’s author to describe it:

“Now QualPro Inc., a company that markets a competing process-management technique, has issued a study comparing the stock performance of companies that adopted Six Sigma with the performance of the Standard &amp; Poor’s 500-stock index. QualPro has done work for Lowe’s Cos., Home Depot’s main competitor. 
“Given that the study was issued by a Six Sigma competitor, it isn’t surprising that the comparisons aren’t flattering.”
They go on:

“A number of former GE executives -- including W. James McNerney Jr., former CEO of 3M Co.; Dave Cote, CEO of Honeywell International Inc.; and Mr. Nardelli -- helped spread the Six Sigma word but have seen their companies’ stock prices lag.
“Since announcing the adoption of Six Sigma on July 1, 2001, Home Depot shares are down 8.3% compared with a 16% rise in the S&amp;P 500 over the same period. The stock rose more than 2% yesterday on the New York Stock Exchange, to $41.07, after Mr. Nardelli’s resignation.
“Honeywell shares are down 7.2% since its Six Sigma announcement in early January 2000, compared with a 3.6% fall in the S&amp;P 500. Shares of 3M are off about 1% since late December 2003 versus the S&amp;P 500’s 29% climb. GE shares rose sharply in the 1990s, but they’re down 16% since July 2000, when the company adopted Six Sigma, compared with the 2.6% fall in the S&amp;P 500.”
First of all, I know I speak for most of us when I howl: correlation does not necessarily indicate causation. There’s enough material for several blog entries here, but I’ll restrain myself because there are more interesting things to quibble with here. For example, what to make of this?

“Of the 58 companies reviewed in the QualPro report, 52 underperformed the S&amp;P 500 index from the time they launched their Six Sigma programs through Dec. 5, 2006. Other underperformers include Lockheed Martin Corp., Ford Motor Co. and Xerox Corp.”
Yet the George group claims on their website that “our client index has tripled in value while the S&amp;P 500 has declined.” Further, on the back cover of this month’s iSixSigma magazine you can see their data indicating that “George Group clients outperform all major indices.” Presumably a large portion of those clients deployed Six Sigma. So what does it all mean? Is Six Sigma a good thing or a bad thing for stock price? George Group and QualPro both cite Xerox as an example – what are we to take from that? The point is, it’s impossible to tell. I’ve no doubt that QualPro and George Group both used accurate data analyzed correctly. And yet they report diametrically opposite conclusions. Clearly what was measured and how it was measured must be different, but none of that nuance is communicated. Again, there are several blogs’ worth of questions to ponder here.
More importantly, neither study asks the more interesting question, which is: what would the stock price of these companies have done over the period of the study if they had not deployed Six Sigma? And that’s a question that we can’t answer, because it requires an experiment that’s impossible to run. No one understands Y=f(x) for stock price (at least, no one worth less than 10 figures), so talking about single data points collected on a single x for a particular company doesn’t carry much weight. And given the massive differences company-to-company, I’m not sure aggregating 50 different companies together in a single study is any better. It just sounds better to the casual reader.
While I’m on the subject of QualPro, I found some of the statements on their website, um, interesting. For example, they say:

“Most of us were taught that the optimum process for gaining knowledge is to test one-thing-at-a-time and hold everything else constant. It is called the scientific method. MVT® (Multivariable Testing) proves that the scientific method doesn’t really work in the real world.”
I feel compelled to point out that the scientific method has been around for about 2900 years. Has QualPro suddenly discovered something that minor logicians like Aristotle, Descartes, and Gödel missed? Can QualPro seriously believe what they are saying? It’s ridiculous. In a sense they win by default, because I can’t even formulate a cogent argument to the contrary. It’s like trying to box with a swamp vapor – you can’t hit a bad smell. 
And don’t even get me started on marketing multi-variate testing as “better” than Six Sigma. What decent program doesn’t include muti-variate where appropriate? As for equating OFAT with the scientific method, I’m personally insulted by the comparison. What is it about the induction/deduction cycle that precludes testing more than one variable at a time? Nothing. The scientific method says nothing about how to go from induction to deduction. DOE or “MVT” is a great way to go. Fine, promote MVT, but why denigrate the scientific method to do it? MVT and the scientific method are perfectly compatible.
Finally, just to continue being picky, despite QualPro’s claims to the contrary you can learn about interactions via OFAT experimentation. If you don’t believe me, believe Daniel:

Factorial One-Factor-at-a-Time Experiments Cuthbert DanielThe American Statistician, Vol. 48, No. 2 (May, 1994), pp. 132-135doi:10.2307/2684266
In the end though, I guess none of this matters because:

“QualPro’s proprietary Multivariable Testing (MVT®) system uses more complex mathematics than is used in a Polaris Missile.”
Boy, I can’t think of a better reason to adopt a continuous improvement methodology than that.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[Buzz/Press&nbsp;,&nbsp;General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 09 Jan 2007 00:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Touching the Fire]]></title>
			<link>http://blogs.isixsigma.com/archive/touching_the_fire.html</link>
			<description><![CDATA[We all want to get it right the first time. And a brief browse through the business section of any major bookstore, or even various sections of this website, will turn up hundreds of best practices and other bits of advice that promise to help us get it right the first time. Consultants would never get the job unless the promised they could help us get it right the first time. Who would hire an expert that gruffly suggested we all muddle through it together, and promised only that we’d learn from our mistakes and get there somehow? There is tremendous desire and pressure to get it right, right away. Even though this almost never happens in real life, there is a negative stigma associated with failing to cite it as our target.
“It” can be just about anything in business, but let’s stick to Six Sigma deployment. We all want to have a perfect program, preferably right out of the gate. At the very least we want one that is better than that of our (internal and external) competitors. And we certainly don’t want to make the same mistakes that others have made. We want to benchmark, learn from the experts, and use established best practices to ensure that our deployment is smooth and successful right from the start. Right?
Well, maybe not.
Every single Six Sigma deployment success story I’ve ever heard and believe to be true involves a significant period of fumbling. Many of them have full-blown episodes of tremendous counter-productivity. The most entertaining involve heated disagreements and intrigue worthy of a king’s court. Programs that thrash and flail like a drowning man are not at all uncommon. Idiocy is not unheard of. But nonetheless, these truly are success stories in every sense of the phrase. These are programs that are strong and productive today at companies we have all heard of, big and small.
While it’s tempting to believe that these programs are successful in spite of the trials and tribulations they have gone through, I am increasingly of the opinion that they are successful because of those trials and tribulations.
Best practices are informative, and we should learn from them where we can. But by definition, they are solutions for problems encountered elsewhere. If company A runs into a problem or opportunity and finds a way to profit from it, it does not immediately follow that company B can apply the same solution and be successful with it. In my opinion this is widely misunderstood: the best practice is not what company A did, it is how company A decided what to do. Put another way, the best practice should not be the solution itself, but rather the method of developing the solution. Not the outcome, but the structure of the struggle.
The struggling, in my opinion, is unavoidable. As an analogy, a central tenet of change management is that resistance positive insofar as it is a sign that change is occurring. The longer you avoid resistance the longer you put off true change. The sooner you embrace it an deal with it, the sooner you can move on to a new state. I think the same thing is true of many of the struggles encountered in even the best planned Six Sigma deployments. It is precisely those struggles that catalyze the necessary learning by the organization. I’m not quite ready to suggest that we should intentionally create difficulties, but maybe that’s just my own timidity. Maybe touching the fire earlier and more often in a deployment would get us to the desired end faster. At the very least, I no longer believe we should put a lot of energy into avoiding the messy bits – it never works in the long run anyway, and only delays the inevitable.
As an example, take project selection. Every deployment I’ve been associated with has had significant angst around what projects to work on, how to select them, who works on them, etc, etc. These are classic deployment questions. And despite reams of advice and best practices galore, I still find the most efficient way to find the “right” answer for a site/plant/business/division/group/company is simply to pick some method and give it a try. No matter what the first iteration is, intelligent people disagree about its efficacy and execution, sometimes loudly. So discussions are had, flowcharts altered, criteria changed, and a new iteration develops. And this repeats until a workable solution develops. Is it messy? Yes. Is it painful? Yep. Does it work? Every time.
I don’t want to construe these observations as license to deploy without careful thought and planning. Without significant vigilance and strong guidance the mess stays a mess. But I do think many deployment leaders (me included) tend to shoot for perfection instead of simply reaching out to touch the fire now and then. Minor burns heal quickly, after all.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General]]>
			</category>
			<pubDate>Tue, 02 Jan 2007 00:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The Finish Line]]></title>
			<link>http://blogs.isixsigma.com/archive/the_finish_line.html</link>
			<description><![CDATA[I have been wrestling lately with the question of when a Six Sigma project should be considered “done”. From the perspective of the organization, it’s common to say that done means finished through the control phase or it’s equivalent, including process changes or other implemented solutions. From the financial perspective it’s tempting to say that done means solutions have been implemented, controls put in place, and savings documented for some pre-defined period of time.
But from the perspective of the Black Belt (or whomever is leading the project to begin with), these answers often don’t make sense. Rarely will the Black Belt have the knowledge, authority, or resources to implement and monitor process changes, or the bandwidth to stick around for a year to make sure that the dollars flow as expected. One could argue that perhaps the world would be a better place if Black Belts were truly accountable for these things, but in practice it is usually a process owner and/or finance rep who are responsible for ensuring that changes stick and dollars flow. And given what they are trained to do, we probably want Black Belts moving on to new projects anyway. Instead, we seem to be moving the finish line farther and farther away, and keeping Black Belts involved in more and more things.
For example, consider a classic Six Sigma project aimed at reducing scrap and increasing throughput on a high-volume manufacturing line. Any competent Black Belt ought to be able to do the basic work of defining and measuring, then using statistical techniques to sample and understand the process, and finally running the experiments necessary to arrive at a proposed solution. But if that solution involves re-training the operators, installing new measurement equipment, and reducing changeover times, then the Black Belt is probably the last person I’d want handling the implementation. Give me the process owner, a good trainer, a capital engineer, and an experienced SMED expert to do that. If that Black Belt is all of those things, fine. But in the other 99% of cases, I think a hand-off is by far the best path forward. Even if the Black Belt is accountable for these things on paper (as is often the case), in reality it seldom works out that way for successful projects.
In fact, once a Black Belt arrives at a proposed solution, I’d argue that there’s usually little “Six Sigma work” left to be done. More often that not the change to be implemented involves other tools and skill sets like SMED, Lean, kaizen blitzes, cellularization, training or re-training, capital installations, etc, etc, etc. And given that’s the case, there’s almost always a better person or group than the Black Belt to get it done. Let the Black Belt move on to another opportunity where Six Sigma skills are needed. Why train people up on one thing and then devote them to another?
One answer to this problem is to try to make Black Belts experts at, well, everything. Hence the proliferation of various hyphenated and hybrid techniques (DFLSS with an extra week for change management, anyone?). And as a result, we get what seems like a never-ending curriculum creep: 40 hours online plus five weeks in class for Black Belt isn’t uncommon anymore, and both the online and in class parts seem only to be growing.
But maybe a better answer is to move the finish line forward. Perhaps the job of a Black Belt ought to be to deliver one thing and one thing only: the knowledge necessary to make the improvement. Maybe past that point there are others who will always be better at executing.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Sun, 03 Dec 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Deployment Music, Part 3]]></title>
			<link>http://blogs.isixsigma.com/archive/deployment_music_part_3.html</link>
			<description><![CDATA[In my previous two posts, I talked about the fugue and the symphony as metaphors for Six Sigma deployment.
A fugue is a  musical form in which a single theme is repeated or imitated successively by different instruments until eventually the entire orchestra is involved. This strategy isn’t a bad one for Six Sigma deployment, especially in cases where human resources are tight but time is not. By contrast, symphonies start with some multiple themes deployed differently in different areas. The program doesn’t have to be the same everywhere, as long the themes and their relationships and well planned. The key for a symphonic deployment is that it requires excellent planning and coordination throughout.
Of all my previous blog posts, these alone garnered no comments whatsoever. But what is blogging for, if not to air thoughts that might be interesting to me and no one else? With that in mind, it’s time for the third (and possibly most esoteric) topic in this series: the tone poem as a model for deployment.
With respect to the amount of structure involved, tone poems are at the other end of the spectrum from fugues. In short, there are no rules. There might be one movement, there might be many. Tone poems can have one single theme, a few, or many. Some of these themes can exist in isolation and may be played only by one instrument group. Other themes interact, overlap, and play off one another. Some tone poems are completely original, while others quote freely from other sources in whole or in part. Some are harmonious and pleasing to the ear, while others are random and cacophonous.
The problem with this method of deployment is the same as the problem with tone poems: the outcome is different every time. Actually, that’s not a problem in the world of music at all; creating and driving that variety is the point of the form, and the fact that I might hate the outcome while you might love it is one of the joys of musical expression. But in the world of Six Sigma deployment, we’re faced with the reality that to some extent, our target audience has to love it.
This isn’t to say that any one of these three strategies is inherently good or bad. Rather that one is generally more appropriate than others based on circumstances. The problem is when the wrong choice is made, or worse, no choice is made at all and we default to some version of the tone poem.
Although it’s probably not intentional, most Six Sigma deployments share a lot of characteristics with tone poems. In my experience, it’s easily the most common of the three strategies discussed here. Part of this has to do with the inability of large organizations to formulate complicated plans and then keep the faith long enough to focus and execute those plans over years. Part of it has to do with our desire to emulate the deployments of others, quote from other sources, even though our organizations are different in every respect. And part of it certainly has to do with the fact that most deployments are designed by large groups rather than individuals.
Faced with these real-world difficulties, a lot of deployment champions choose the unstructured tone poem rather than something more structured like a fugue or symphony. And for a composer that is both brilliant and empowered, the tone poem can be a beautiful this. But say what you want about the limited creativity allowed in a fugue, if you follow the basic rules you end up with something that is a recognizable fugue even if you make some major blunders along the way. Ditto for a symphony. In contrast, tone poems and deployments based on the form can end up being a jumble of noise if the composer isn’t careful or talented. To put it another way, the structure and framework actually adds robustness to the deployment, just like it does to the musical form. Unless we’re brilliant, we ought to go for the structure.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management]]>
			</category>
			<pubDate>Sun, 12 Nov 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Deployment Music, Part 2]]></title>
			<link>http://blogs.isixsigma.com/archive/deployment_music_part_2.html</link>
			<description><![CDATA[In my last blog entry, I wrote about the fugue as a model for deployment. A fugue is a  musical form in which one or two themes are repeated or imitated by successively entering voices, until eventually the entire orchestra is playing the same tune. I suggested that this might not be a bad way to deploy, especially in cases where human resources are tight but time is not.
But this won’t make sense for all organizations, just like it doesn’t make sense for all pieces of music. An alternative musical form worthy of consideration in this context is the symphony. A symphony is a relatively long musical composition with several interweaving themes. Symphonies are often  based on the sonata form, which comprises multiple movements in different forms and keys.
Symphonies are usually freer in form than fugues, and often feature different parts of the orchestra being used in different ways. Whereas in a fugue every plays practically the same tune, in a symphony different groups are depended upon to play different tunes. The composer develops and allocates separate but related musical themes according to the unique characteristics of the various sections. These tunes play off one another and combine to express more complex musical ideas. The tubas can do what tubas do best while the violas do what violas do best. Each group certainly needs to be cognizant of what others are doing, but the various groups are not doing the same things most of the time. As long as each plays their part and follows the conductor, beautiful music is made.
Mapping the symphonic form to Six Sigma deployment yields a familiar model. We start with some central themes but deploy them a differently in different areas. What we do in the supply chain can be different than what we do in manufacturing which can be different than what we do in IT which can be different…well, you get the idea. Or maybe what we do in business X can be different than what we do in business Y which is different that what we do in business Z. Not entirely different – there needs to be some degree of coordination through the composer and conductor –  but not the same either.
The point is that the program in each place doesn’t need to be the same, as long the themes and their relationships and well planned. And furthermore, we’re free to include different “movements” in our Six Sigma symphony – maybe we start out with DFSS, then move on to traditional Six Sigma, and finish up by modulating to Lean Sigma. We can do that without losing the overall structure of the program. This can work, and when it’s done well it’s a very powerful model.
The key for a symphonic deployment is that it requires excellent planning and coordination throughout. There needs to be a highly skilled composer to plan things ahead of time, and there needs to be a highly skilled conductor step up on the podium and lead all the diverse groups. Most organizations don’t have a resident Mozart who can put all the pieces in place. Most organizations don’t find and free up the resources to plan a deployment in detail well before it happens. And most organizations, especially large ones, aren’t good enough at communicating within and between silos to keep several different but related deployments playing nicely together.
In short, a lot of pieces need to be in place to succeed with this model of deployment. Organizations that have these pieces in place can and do run with this model and develop very powerful and successful programs. A few high-profile examples of this are probably why so many people gravitate towards this model. But woe to organizations that try it without having the enabling pieces in place first! Unfortunately, that’s most of us.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 24 Oct 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Deployment Music, Part 1]]></title>
			<link>http://blogs.isixsigma.com/archive/deployment_music_part_1.html</link>
			<description><![CDATA[One of my favorite pieces of music is Benjamin Britten’s “The Young Person’s Guide to the Orchestra.” In it, Britten decomposes then reconstitutes a fugal work for orchestra based on a much older tune by Henry Purcell. The work is somewhat unusual in that at Britten’s request, a friend wrote narration that describes textually exactly what Britten was doing musically throughout the piece. Listening to a performance thus becomes not just pleasing, but also explicitly educational. You can learn more about this piece of music here, and elsewhere on the Internet.
Now don’t worry – I’m well aware that the business-as-a-symphony, leader-as-a-conductor, team-as-an-orchestra, and related similes are hackneyed and tired. In fact, as metaphors and allegorioes, they have been done to death. But in Britten’s work in particular there is something new that caught my ear relating specifically to Six Sigma deployment.
As the narration for “The Young Person’s Guide to the Orchestra” explains, each section of the large musical ensemble is approached separately at first, and asked to play a simple tune in their own way. The narration continues:

"After the whole orchestra has been taken in pieces, it is reassembled using an original fugue which starts with the piccolo, followed in by all the woodwinds, strings, brass and percussion in turn. Once everyone has entered, the brass are re-introduced with Purcell’s original melody while the remainder continue the fugue theme until the piece finally comes to an end after building up to a fortississimo finish."
To fill in some context, the dictionary defines a “fugue” as “a musical composition in which one or two themes are repeated or imitated by successively entering voices and contrapuntally developed in a continuous interweaving of the voice parts.” The term “contrapuntally” refers to the technique of counterpoint, which is defined as “one or more independent melodies added above or below a given melody” or “the combination of two or more independent melodies into a single harmonic texture.”
So, putting all that together, the fugue form involves approaching distinct subgroups within the larger organization and giving them a basic template to follow in their own way. Each embellishes and innovates as necessary according to their unique character, while still staying true to the template. This is done throughout the organization to develop and flesh out the basic framework in each place. Once this is done, some of the subgroups come together and repeat the exercise in larger groups. Finally, all groups play their individual variations as one, uniting to form the cohesive whole. The finale is beautiful and powerful, far more than the sum of its individual parts.
The preceding paragraph could, of course, also be describing one way of deploying Six Sigma (or any other program) in a large organization. You don’t even have to change any of the words to make the description fit. Any company big enough to have distinct silos, functions, units, regions, or other identifiable groups could deploy in this manner. It’s not hard to imagine (or find examples of ) deployments where a simple program is rolled out repetitively, with the same thing happening many, many times for various groups within the whole. The nice thing about such a modular or "fugal" approach is that it can go as fast or as slow as necessary – indeed, a very large deployment can literally be done by one person given enough time – and provides tight control over how much of the organization is involved at any time. Of course, if you need to get the whole company on board fast, this might not be the way to go.
Regardless, we have something to learn from Britten about Six Sigma deployment. And if the “organizational fugue” is an easy and apt metaphor and can teach us something about deployment, why not the “organizational symphony” or the “organizational tone poem”? Stay tuned for more on those ideas, and in the meantime, track down and check out a recording of “The Young Person’s Guide to the Orchestra”.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 10 Oct 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Good Process, Bad Process]]></title>
			<link>http://blogs.isixsigma.com/archive/good_process_bad_process.html</link>
			<description><![CDATA[I was in New York City on a busy summer weekend not too long ago. Me and a whole lot of other tourists. In fact, it was the busiest I have ever seen the city in terms of tourists.
Saturday night found me and my companions at one end of Times Square, fighting the crowds to enjoy one of my favorite treats: a smoothie. Sunday night was the same, except that we were at the other end of Times Square fighting the crowds to enjoy another one of my favorite treats: ice cream. You’d think the two experiences would have been similar, but in fact they couldn’t have been more different.
First, a little background. For those unlucky folks who have never had a smoothie, they’re a blended mix of roughly 5-6 fresh ingredients like yogurt, sherbet, fruit of various types, juice, ice, etc. Each ingredient type can be customized according to what the customer wants; one order might mix bananas, strawberries, vanilla yogurt, orange sherbet, and ice, while the next might have blueberries, raspberries, oranges, grape juice, plain yogurt, and ice. On top of that, various additives are available, supposedly for extra fiber, extra energy, extra protein, etc. The ingredients are all combined and then blended before being poured into a cup and presented to the customer.
On the surface, the particular ice cream process I experienced was very much the same. Customers select a base ice cream which is then combined 3-4 additives like fruit, chocolate, nuts, various syrups, whipped cream, etc. These ingredients are all mixed and then transferred to a cup or cone and presented to the customer.
In both cases I very much enjoyed the taste of what I got, and in both cases the total price was in the region of $5. But that’s where the similarities ended. My experience as a customer was sharply different.
When I ordered the smoothie, I entered the building and had to wait about 20s to reach a cashier. The cashier asked me my name, and then took my order, which took another 20s. The physical layout then guided me to a small waiting area where additional products and other information were displayed alongside large windows and other diversions. Meanwhile, my custom order was electronically transmitted to a second worker who put the ingredients in a blender cup. This was fast and easy because all the scoops were sized to deliver single portions of solids, while liquids were automatically dispensed in the correct proportion according to the information the cashier had entered. Approximately 120s later, another worker finished blending the smoothie, poured it into a cup, and called me to the counter by name to deliver it. The place was crowded, but the process was designed to handle it and get folks through quickly. They were serving a new customer every 30s or so with almost no lineups. Another entire cell remained empty and un-manned; presumably to accommodate periods of peak demand. Fantastic.
By contrast, ordering the ice cream was nightmare. We had to line up outside just to join the line up inside. No less than three workers were dedicated to managing the flow of people from the outside line to the inside line – and even then, we watched frustrated as several people simply skipped ahead of us to the inside line. Total time in the outside line was about 15min. As we got inside, it became apparent that the physical layout of the store was incredibly bad from flow standpoint. A single, large station took up so much space that the folks who had received their order had to wedge past those still waiting to get out. Menus on the wall were unreadable from a few feet away, necessitating long conversations once the first cashier was reached. That was difficult, because of very loud music and, bizarrely, singing by the staff that seemed to be mandated every couple of minutes. Worse, the cashiers didn’t know the menu at all – ours argued with us about an item that she didn’t believe was on the menu. (We checked, it was.) Total time in the inner lineup was approximately 30min. Once we actually placed our order, a bizarre dance of inefficiency began. The person making the order was apparently supposed to keep in her head the details of four custom orders. She failed at each, having to ask information to be repeated four times. Again, this was very difficult due to the music and singing, to the point where we left with incorrect products because we gave up. She had to run to several different places for the ingredients, causing more than one physical collision with others doing the same. Labels and scoops were unusable in some cases and absent in others. She apologized that at least one of the things we had ordered “tasted really bad.” When it came time to actually pay (why didn’t we pay the first cashier?), we faced a new person who had no idea what we had ordered. So, we had to explain it again…sixth time in the process…did I mention the loud music and singing? The whole experience took just under and hour. The place was crowded but they were only serving a new customer every 5-7 minute. And if those other customers were anything like me, they left not only vowing that they would never come back, but also determined to warn others to avoid the place at all costs as a public service. It was awful.
The smoothie process was, in my opinion, a thing of beauty. They had obviously borrowed heavily from a certain well-known coffee chain, more than one fast-food chain, and probably some others. And they had innovated where necessary. In short, they had done their homework and thought about it. The beautiful details were too numerous to mention…the consistent way they unwrapped the straws without touching anything but the wrapper…the physical flow of material…it all brought a tear to my eye.
The ice cream process made me cry for different reasons. And what bothered me the most about the experience was that so many potential improvements were obvious and easy. It wouldn’t take a process improvement expert to make things much better, it wouldn’t even take money, it would just take someone with some interest, initiative, and a three digit IQ. With a small budget and little bit of knowledge, I bet even the greenest process improvement effort could turn the customer experience around 180 degrees and cut the time down by 80% in a month. The work wouldn’t be hard. Indeed, if they walked a few blocks across Times Square they could learn everything they need to know for free from the smoothie folks.
My question is this: why don’t they do it? Why is the horrid process allowed to persist? The improvements are so easy, so obvious, and so within-reach. The best practices are so well-reported and well-known. Sure, it would take a bit of work and dedication to make the changes, but if they can hire three people to manage two lines, surely they can afford one to get rid of the need for  two lines in the first place. Why, oh why, does the bad process continue to exist?]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Fri, 15 Sep 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Part-time Help Wanted]]></title>
			<link>http://blogs.isixsigma.com/archive/part_time_help_wanted.html</link>
			<description><![CDATA[In my opinion, one of the key questions to answer when planning a deployment is whether the Black Belt role should be full-time.
While this sounds like a reasonable question to some, many experienced Six Sigma folks find it strange to even ask, because in the majority of programs the Black Belt role is automatically assumed to be full-time. Candidates are identified from within the organization (or hired externally) and trained in the usual way, after which time their job title becomes some version of “Black Belt” and they leave their previous role. In a separate but related process, projects are identified and prioritized. Projects are then matched to Black Belts, who move through the organization as necessary to complete the projects they are assigned.
There are innumerable variations on this theme, but in general it’s a pretty common model for continuous improvement. I think there are two reasons for this. First, it works well, especially at the start of a deployment. If you pick the right projects, provide a serviceable tool set, and 100% focus the right people, good things happen. You get project results and you get them fast. The second reason is that most Six Sigma consultants push this model, which is of course because of the first reason.
I worry about this deployment strategy in the long run though, especially as a path to culture change. This is partly because when I think of culture change, I think of work that should be targeted to address the holistic, system level in an organization. Not any one specific thing, but rather a collection of many aspects that must all be addressed with reasonable simultaneity. In my own mind, I call this “common cause work”.
In contrast, I view deploying specifically trained individuals to work on individual projects as “special cause work”. Here we are thinking less about working on the system as a whole, but rather about a very specific set of activities associated with a specific improvement objective.
(Before I get jumped on for my use of “special cause” and “common cause” terminology in this context, let me freely admit that I am using them conceptually rather than literally. And that I am taking liberties. And that I do understand the formal and correct usage. And that yes, I have read “Out of the Crisis”.)
I don’t mean to suggest that one type of work is better or more necessary than the other, only that they are different in nature and serve different purposes. I have seen successful Six Sigma programs based on both strategies. The problem comes when we address common cause work with special cause responses, or vice versa. As any Black Belt should know, the only exacerbates the problem we are trying to solve.
What this means in practice is that if culture change is the goal of a Six Sigma deployment, deploying full-time Black Belts, which is a special cause response (or at least much more special cause than part-time Black Belts) may not be the right strategy. In fact, as anyone who has done any special cause/common cause simulations can tell you, deploying Black Belts in a special cause fashion may in fact make the common cause cultural issues worse. It’s true that projects will be completed quickly and successfully, but it wreaks havoc on the culture.
Part-time Black Belts, on the other hand, can be deployed against common cause cultural variation as well as specific projects. For example, suppose there is a project that needs to be done in a specific facility which does not have a resident Black Belt. The special cause option would be to bring a full-time Black Belt in; import one from the outside, or take someone from the facility and put them in a new role. This would get the project done. But another – maybe better – option would be to find a subject matter expert from the facility and ask for 50% of their time for training and project work. The downside is that it will likely take that person more time to complete each project. And there will be battles to fight about focus and time balance. But the upside is tremendous. That person will know more than any outsider about the process. They will know the people involved. They will have natural social connections. They are far more likely to spread the philosophy and methodology of Six Sigma than an outsider would be. And when the project is done, they will still be there to for the next iteration, and the one after that. In short, they will be embedded and able to work in a common cause fashion on the culture, as well as being able to work special cause on specific projects in a special cause fashion.
As I said, the downside to all this is that it takes longer to get projects done. And part-time Black Belts are typically not very mobile in the organization, and thus can’t be easily deployed against projects outside their area. There are plusses and minuses to every approach. But the part-time Black Belt strategy is always worthy of consideration, especially when cultural change is a stated goal of deployment, and even when full-time Black Belts are an option. While undoubtedly messier in the short term, it’s a shorter path to culture change in the medium-long term.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management]]>
			</category>
			<pubDate>Tue, 22 Aug 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma Sucks]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_sucks.html</link>
			<description><![CDATA[Over the past weeks and months I have become increasingly aware that there is a grouchy counter-Six Sigma-culture out there. As indisputable proof of this, a Google search on the phrase "Six Sigma sucks" returns no less than 111,000 hits. (See for yourself here.) Even discounting bitter G.I. Joe fans, this is a big number. 
I certainly didn’t read through all of the links, but I did peruse the first score or so. And I also spent quite a bit of time reading through the collected wisdom on a page ostensibly devoted to "The Truth about Six Sigma Quality...Fallacies, Faults and Errors" located here. Incidentally, I was directed to this site from, of all places, the forums on www.isixsigma.com.
Because there is a lot to read on the subject of "Six Sigma Sucks", allow me to paraphrase the vast majority of what is out there in the three points below. And, of course, to respond. Because behind the smarmy smarter-than-thou attitude that pervades most of these pieces, there is little more than a lot of unfounded assumptions, much plain misunderstanding, and no small measure of grumpy complaining masquerading as fact.
1. The math is wrong.
There seems to be a small but dedicated community of folks (mostly academics and consultants) who are obsessed with some or all of the following: the definition of defects; the focus on defect reduction; use of Sigma as a process measure; usefulness of DPMO as a process metric; whether using the normal curve as a basis for process improvement work is appropriate; whether Harry’s “1.5 sigma shift” is real and if so how it may be explained; whether Six Sigma is a reasonable goal in the first place; etc, etc, etc.
Such arguments, in my opinion, entirely miss the point regarding data-driven continuous improvement. Sure, math and statistics get tortured and misused all the time in the name of Six Sigma. And sure, errors are made. That’s not surprising - a few weeks of training and access to a lot of computing power does not make people into statisticians or mathematicians. But if we can get to the point of discussing and debating the problems and opportunities in an organization in a data-driven, consistent way, then the battle is already won. We don’t have to be right in every case, or even most cases, to make progress. Dwelling on the fact that the math is sometimes wrong is a bit like suggesting that we should never start jogging to lose a few pounds unless our running technique is already perfect. In fact, we make a lot of progress even if our technique is terrible. And not to start at all would be a much worse mistake than starting poorly.
Furthermore, "the math is wrong" is not only a weak argument, but also one aimed against a view long since discarded by most serious practitioners of continuous improvement. In my opinion and experience, the best Six Sigma programs today no longer focus on simple defect reduction. Many don’t even teach Z-scores or process capability indices. As the detractors are fond of pointing out, gurus like Deming, Shewhart, Wheeler, and many others have much more sophisticated and nuanced views than simple "Six Sigma quality" on the use of statistics to drive continuous improvement. What the detractors don’t seem to realize is that Six Sigma practitioners realize this too. We’re not dumb or close-minded. We all continue to learn, and Six Sigma curricula have largely moved on in their own cumbersome, evolutionary fashion.
2. Consultants vastly overstate the value of the program.
This one, of course, is often true. But it’s definitely not a Six Sigma-specific problem. And it’s not done by good consultants, consultants who understand the plusses and minuses of Six Sigma, and are careful to talk clients through both. There will always be examples of very expensive programs that start with a blizzard of flashy PowerPoint and end with no results, but that’s hardly the fault of Six Sigma in general. Where and when it happens, it happens independent of the program or subject matter. "Caveat emptor" always applies to any consultant services, and "garbage in, garbage out" always applies to any program or initiative. Six Sigma isn’t any different, but that’s hardly a serious knock against the subject matter.
3. Six Sigma isn’t anything new - [insert your favorite author here] had it right way back when they wrote [insert your favorite book here].
Well of course they did. You won’t find a bigger fan of Deming than me. And Shewhart was absolutely a genius. Every book that Wheeler has written has provided me with numerous light-through-the-clouds moments. Tufte is beyond elegant in his views on the graphical display of information. And yet Deming’s 14 points and PDCA methodology still aren’t common vernacular. The vast majority of people using Shewhart’s control charts still don’t understand them. Wheeler’s intuitive and eminently comprehensible explanations of basic statistics still get misunderstood regularly. And to what I can only assume is Tufte’s ongoing dismay, three-dimensionally rendered bar graphs showing one variable are more common than ever. So apparently just being right isn’t enough. We need a way to institutionalize those realizations across large organizations, a way to create a common vocabulary, a way to get everyone a company moving in the same direction. We need an excuse for everyone to read the magic book. And like it or not, programs that generate hype provide a means to those ends. If there’s a better, more efficient way to achieve the same cultural results, I haven’t found it yet.
What bothers me most about the various "Six Sigma Sucks" pieces I read is that their authors inevitably imbue their words with a certain the-Emperor-has-no-clothes self-heroism, subtly suggesting that they are cleverer than we Six Sigma lemmings who run blindly towards the sea. But what they fail to realize is that those of us on the inside are thinking about the same things they are, wrestling with the same issues, lying awake at night wondering how best to evolve Six Sigma going forward. We understand and worry over the shortcomings of the program more than anyone. The only difference is that we don’t let it stop us from doing the best work we can right now, even as we seek better ways.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 31 Jul 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Which Comes First: Process or Behavior?]]></title>
			<link>http://blogs.isixsigma.com/archive/which_comes_first_process_or_behavior.html</link>
			<description><![CDATA[Fixing or otherwise improving a process usually involves changing it in some way. For this reason, Six Sigma projects almost always involve some element of process engineering or re-engineering. On top of that, folks in deployment leader roles or similar are often tasked with developing brand new processes like project selection, candidate identification, certification, and a range of others. And of course there are a myriad of situations outside the Six Sigma world that involve creating or altering processes.
One failing I see in myself (and in many new Black Belts) is a tendency to develop ideal processes on paper, without addressing elements of human behavior. I suspect it’s a by-product of being trained in a highly data-driven methodology. We expect that if we can use good data to demonstrate that a process change will result in an improvement, then people will automatically change their behavior. Put another way, if we ourselves are convinced by data, we assume everyone else will be as well.
In my experience there are a few problems with this view. One is that it does not hold for everyone: some folks are not, in fact, convinced by data. Another is that complicated statistical data are difficult to communicate effectively across large organizations. And finally, even those who are intellectually convinced will almost certainly need to be provided with additional motivation to change their behavior.
I’m not going to give a lecture on change management here. What I want to talk about instead is the relative difficulty of changing human process behavior versus standard Six Sigma process work. And more particularly, the order in which we address the two related areas.
I have been in many situations when, in response to a genuine gap or need, a new process is designed or purchased. Software implementations are a great example of this. The perfect process is laid out on paper, the process tools procured, and the process rolled out in the organization with the best of intentions. But I have seldom seen it work well, or even have any lasting effect, unless considerable work is done to change human behavior first.
Take, for example, project tracking systems. In more than one case I have been in organizations where there is basically no project tracking prior to Six Sigma deployment. It is identified as a need as part of the deployment plan, and software is purchased. But once the system is set up, no one uses it even though it is a great system.
It has taken me a long time to learn that in this situation, the most effective first step is to focus on behavior and implement something simple. A one-page template that is collected manually each month and rolled up into an offline project spreadsheet is a great first step. Work hard to get folks doing that and see what happens. Learn from the experience and iron out the kinks in the rudimentary process. Once you get good at that and folks are used to it, then take the next step; maybe a simple online database that everyone can access directly to enter their information. Take the time to tweak that database and figure out what reports are useful, as well as what functionality you really don’t need. The take the next step, and the next one, and the next one. Before you know it there will be a robust process that people are used to following. And even if the “home-made” process is clunky and hard to manage, it’s an amazingly short step from here to a beautiful, gleaming, streamlined process. If you grow the process yourself you’ll know what you need from a software vendor when the time comes, and you’ll know what to expect from the folks who interact with the system. In short, you’ll be automating something that already works, rather than trying to go from nothing to perfection in one step. And crucially, you’ll already have established the necessary patterns of behavior among the people interacting with the process. In my experience it’s a lot easier to map the process/software to existing behavior than vice versa. So it’s worth taking the time to get the behavior right before you decide on the software, even though it’s a very messy process.
Project tracking is just one example, but in my experience the general conclusion holds in most situations. “Process or behavior?” is not a “which comes first, the chicken or the egg?” question like I’ve often heard suggested. And designing or purchasing a new process won’t automatically create behavior, the claims of vendors notwithstanding. These days I find it most efficient to crawl before I walk, before I jog, before I run, etc. I live through the messy home-made solutions before I automate or even finalize process in the organization. I work on building the process behavior before I build the process itself.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 25 Jul 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The Fundamental Questions]]></title>
			<link>http://blogs.isixsigma.com/archive/the_fundamental_questions.html</link>
			<description><![CDATA[As I was scanning news this week, a couple of articles caught my eye. The first was a piece by Damon Darling in the New York Times about Farecast, an airfare search engine that aims to predict how much the price of an airline ticket will rise or fall before the flight actually occurs. Says Hugh Crean, Farecast’s chief executive, "This is predictive technology — we won’t achieve clairvoyance. We repredict and resimulate against our database to get better and better at what we are doing."
The second article that got my attention concerned the use of InnoCentive, an online portal that aims to connect organizations having scientific problems with researchers who can solve them. In the piece, Ann M. Thayer of Chemical and Engineering News spoke with Dan Kittle, Vice-president of Research and Development for Dow Chemical’s AgroSciences Unit.
According to Thayer, Kittle admits that “the approach was a bit ad hoc at first.” Kittle himself says of the InnoCentive program that “we learned quickly that we needed to put some structure around it help drive it.” Kittle continues “You’ve got to be able to get a challenge down to something for which you rationally believe there are the expertise, understanding, and capability to directly approach.”
Does any of this sound familiar? It sure does to me. The problem that Farecast faces – the development of predictive models and the accuracy of predictions – is one that occurs to some extent in almost all Six Sigma projects. In programs I am involved with, we even tackle it the same way Farecast does: state a prediction, test that prediction against reality, evaluate the thinking that produced the prediction, and iterate until we have a useful model. It’s not a "Six Sigma" approach per se, but rather an application of the scientific method.
The InnoCentive piece highlights how useful it can be to inject a little bit of structure into the project selection process. And furthermore, that even a very good problem solving method probably won’t be magic. These too are conversations I have had repeatedly in the context of Six Sigma deployment. Even though the Innocentive folks really have nothing to do with Six Sigma, they face exactly the same problems we do.
What to make of this?  The comments from Dow and Farecast illustrate that folks outside the Six Sigma bubble face exactly the same issues that we do. The reason these article caught my eye is because it seems to me the longer I stay in the Six Sigma world, the less "Six Sigma work" I do. In fact, my activities tend to focus, rather generically, on the following:

1. People: Finding the right people and developing them2. Process: Developing effective processes and discipline to process3. Projects: Selecting the right projects and executing them efficiently
Literally everything I do (professionally!) falls squarely in one of these areas. What’s interesting to me about this (admittedly non-novel) observation is that on the surface none of it has anything to do with Six Sigma. Rather, Six Sigma just happens to be a framework in which to work. I honestly don’t believe there’s anything special about Six Sigma other than that. All the hoopla, all the jargon, all the acronyms, all the bizarre terminology – perhaps the real and only value of those things is that they force us to focus and get organized about our people, process and projects. In other words, Six Sigma forces us to answer the fundamental questions. And if we don’t do that, well, there are a million dead corporate initiatives out there that show what happen if we don’t. We spend a lot of money and create a lot of cynicism, only to end up back we started again.
My point is that the fundamental questions of business (examples: How do we decide what work to do? How do we develop our people? How do we innovate? How can we predict more accurately?) never really go away. And I don’t think you’ll find very good answers for any of them within a Six Sigma program. In fact, it’s been my experience that what separates a good Six Sigma program from a bad one is how effectively these questions have been answered before deployment begins. Which is probably true of any initiative within the organization.
So, Six Sigma provides a reason to focus on the important, foundational questions that the business faces. That’s not news. But perhaps that exuse to focus is actually the true value of Six Sigma - not the projects or roadmaps or certifications or belts anything else. Because the business is going to spend a tremendous amount of time, resources, and money on a typical Six Sigma deployment, there is strong impetus to have answers to those fundamental questions before the deployment begins. And maybe once we have some decent answers, what we deploy doesn’t matter very much at all, as long as we do it well.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management]]>
			</category>
			<pubDate>Mon, 10 Jul 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Whither Certification?]]></title>
			<link>http://blogs.isixsigma.com/archive/whither_certification.html</link>
			<description><![CDATA[There’s a lot of talk about Six Sigma certification these days. I remember being asked by a talent acquisition manager at a previous employer what it meant to be a “certified” Master Black Belt. The question arose because a quick search on Google turned up programs ranging from 3 days (online) to 2 years in length, and all of them offered “Master Black Belt Certification” as an end goal. In some cases the certification was automatic on completion of the program, in others it required things like project work, testing, or other forms of independently verifiable achievement. As we quickly established, it didn’t mean much at all to be a “certified” Master Black Belt.
Which isn’t to say that certification doesn’t have value. It’s just that it’s value isn’t consistent. And maybe that’s not a bad thing. In fact, in a roundabout way it might be a good thing.
I’ve been involved with the creation of three different Six Sigma certification programs at three different companies. In every case, we started off with the idea that certification should be tied to some external standard – for example, our Black Belts might have to take a test provided by an external quality organization or consultancy. The argument here is usually that standards may slip and/or be applied inconsistently if certification criteria are evaluated qualitatively from within the organization. The idea is to make certification more like a degree or professional accreditation, which in theory has consistent value across organizations.
I reject this view. Individuals who independently pursue achievements that result in recognizable, external certifications of some sort do so to further their individual goals. And the organizations that award such certifications have a vested interest in maintaining high standards so that the individuals they certify conform to certain expectations, furthering the reputation of the certifying organization. Colleges that award degrees are a perfect example. Individuals choose a college to pursue a degree to further their interests and/or career. Colleges won’t award a degree unless those individuals meet the standards they set out. And that makes perfect sense if you are a college.
But businesses are not colleges, and Six Sigma certifications are not degrees, and businesses pursue business goals not individual ones. There is no automatic value to a business in having either “tough” or “easy” certification criteria, or even criteria which are consistent in their application. Indeed, the only thing that should matter in setting up a certification program is what behavior the business wants to recognize and reward. Want to drive the efficient acquisition of knowledge? Design metrics and base certification around those. Want to complete a lot of projects quickly? Design your certification around that. Want to use Six Sigma certification to drive employee morale and buy in? Then certify everyone as they walk out the door of the training course. I could go on, but you get the idea. None of these methods of evaluation are good or bad ideas except in the context of what the organization wants to do.
If you think this argument is abstract, consider a conversation I had recently about a Black Belt (not at my company!) who was running a fairly complicated DOE and having trouble getting support and resources. I asked why. It turned out that the project was basically dead, but the DOE was being done because a DOE was required as part of the certification process. This was a case where the objectives of the certification process were not just out of alignment with the objectives of the organization – they were actually pulling in opposite directions. I’ve seen variation on this theme happen consistently when certification standards and criteria are out-sourced to consultants or quality organizations. Businesses need to use certification as a way to drive the behavior they want to see, and an outside organization simply can’t do that effectively, especially if it is trying to be consistent across many different businesses.
The key thing to remember is that certification itself has no value to the business whatsoever except as a driver of behavior. Of course, if you take this approach, inevitably someone will howl that “certification doesn’t mean anything”. My response? So what. It doesn’t have to "mean anything" outside the organization. All it has to do is motivate the behaviors that the organization is interested in. Nor do whatever standards you come up with have to be consistent. In my view the tenth person that gets certified in a business unit should almost certainly face elevated standards relative to the first person – that tenth person should be benefiting from the experience of others, and anyway, how else are you going to drive continuous improvement? And a Black Belt in HR isn’t going to be subject to the same set of standards as a Black Belt on the manufacturing floor – why would they, since the nature of the work is completely different? And I’m certainly not above certifying a key individual to drive culture change as opposed to for technical reasons. I do have standards, but I’m also ruthlessly focused on moving the organization where it needs to go. If you overlook certification as a way to do that – or if you’re asking someone outside the organization to do it for you - you’re overlooking a very powerful tool for driving behavior.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management]]>
			</category>
			<pubDate>Mon, 26 Jun 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Why “How Many Samples Do I Need?” Is Not A Statistical Question]]></title>
			<link>http://blogs.isixsigma.com/archive/why_how_many_samples_do_i_need_is_not_a_statistical_question.html</link>
			<description><![CDATA[I recently read through a thread on this site’s discussion forum which started with the question “Sample Size…Why 30?” You can read it for yourself here.
It’s a question I hear a lot, except that 30 is sometimes another number. Like 2. Or 8. Or 156. Or 2068. The thread was intriguing in a number of ways, not least because it has remained active since mid-2002! Clearly there is a lot of interest in this topic.
How to sample a process is a favorite topic of mine as well, but for different reasons: in my experience it is one of the most abused topics in the Six Sigma canon. The “why 30 samples” question is, in my view, symptomatic of a root cause that involves a misunderstanding of enumerative versus analytical statistics.
(Fair warning: I am not a statistician.) Enumerative statistical techniques concentrate on understanding population data via various statistics. For example, we might want to estimate the average height of a 42 year old male in England, and to do this we could sample the population through a census. Enumerative statistics would help us understand how many people we’d need to survey from the population (and maybe something about how to choose them) to get an “accurate” estimate of the true average value at some level of statistical confidence. Techniques such as Chi Square and other tests of significance, confidence intervals, etc, are very powerful tools in the enumerative world for these types of problems. And questions like “how many samples do I need for…?” have well-defined answers.
Analytical statistics, on the other hand, concentrate on predicting the future. Which means the techniques vary considerably from those of the enumerative world. And in my view it should go without saying that the point of any Six Sigma project should be to predict the future in some way. What does Y=f(x) symbolize if not the ability to predict? Yet in my anecdotal estimation, about 95% of the Six Sigma projects I see at conferences, on the web, and in the open literature rely solely on enumerative techniques. Which is probably why there is such intense interest in questions of sample size. This is highly misguided in my opinion. Also in Dr. Deming’s, who has the following to say regarding enumerative techniques for continuous improvement in “Out of the Crisis”:

“Incidentally, Chi Square and other tests of significance, taught in some statistical courses, have no application here or anywhere.”
And later on:

“But a confidence interval has no operational meaning for prediction, hence provides no degree of belief for planning.”
(Note: I copied these quotations from an interesting exchange on this subject here.) 
From an analytical statistics point of view, the relevant question to ask is not “how many samples are needed for…?” but rather “how can a representative sample be chosen such that we can predict the future behavior of the system at a useful level of accuracy?” And the crucial point is this: that second question is not a statistical question. I’ll repeat: the question of how to sample appropriately such that you can accurately predict the future behavior of the system is not a statistical question. It is entirely dependent on your knowledge of how the system behaves, and no piece of software or statistical textbook will help you answer it. You have to study the system itself, and let it be your guide.
The advice we should give in answer to the query “how many samples do I need for…?” is to turn around and ask how much knowledge of process variation/behavior we have, and then discuss how to sample that variation/behavior in such a way that we feel confident that the results will predict the future variation/behavior. In the world of analytic statistics there is no magic number that answers the question of how many samples are needed – it depends wholly on knowledge of the process. 
For the same reason, I almost never recommend random sampling. To me random sampling as a strategy is a tacit admission that variation is not understood and cannot be sampled purposefully. I would rather sample in a very structured, non-random way and gain insights into process variation than sample randomly and mathematically remove the effect of “noise”. Random sampling might get rid of “noise” in the mathematical sense (and hence make enumerative calculations look better), but that noise is still there in the process. Better to sample it, study it, and deal with it than ignore it.
So when I am asked, as I often am, “how many samples do I need for this study”, my answer is always the same: “what is your sampling plan to capture the variation you are interested in seeing?” There is no single, easy answer to this analytic question – it depends completely and entirely on the specific situation.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 13 Jun 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma Trends From Google]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_trends_from_google.html</link>
			<description><![CDATA[
A while back I stumbled on a new part of the Google website called “Google Trends”. You can view this website for yourself here. 
In Google’s words, the website allows users to “compare the world’s interest in your favorite topics. Enter up to five topics and see how often they’ve been searched for on Google over time. Google Trends also displays how frequently your topics have appeared in Google News stories, and which geographic regions have searched for them most often.” Basically it’s a service that allows you to see the number of searches on various keywords over time, broken out by geography, language, etc. All the values are normalized relative to the total number of searches – while that allows meaningful comparisons over time, it does remove the user’s ability to get at raw data, which might be more useful from a data analysis perspective. But it’s a free service, so I’m not complaining.
For example, the this link shows search patterns on the term “Six Sigma”.
I’ll freely admit I was blown away by the distribution with respect to geography and language, and I suspect others in our profession in North America might be as well. For those of you outside of North America, this is probably old news. I wasn’t too surprised to see India on top in terms of searches by country, but I certainly wouldn’t have predicted that Thai language searches for “Six Sigma” outnumber those in any other language. I and definitely wouldn’t have predicted that the USA would rank a mere seventh! (Admittedly Canada, where I live, doesn’t even rank in the top ten.) As with many things, it’s one thing to know what’s going on anecdotally, but quite another to be confronted with the data.
You can also use the site to compare searches on two or more terms, which lends itself well to all sorts of correlation/causation games. If you’ve ever been in a Six Sigma training course, you’ve probably heard some variation on the notion that “correlation does not necessarily indicate causation” (although it can certainly be a big hint!). One popular example of this fallacy is that sharks must like the taste of sunscreen because sales of sunscreen correlate well with the occurrence of shark attacks. The correlation turns out to be true, and apparently interest in sunscreen is not a bad predictor of reports of shark attacks. See for yourself here.
On a less frivolous note, this result shows searches on the term “Six Sigma” compared to “Lean Sigma”. It’s worth playing around with the “regions” and “years” drop down menu to see what has happened in various parts of the world over time. The trend for “Lean Sigma” itself is actually very interesting too – here we see Washington, DC on top, which I theorize may reflect the recent interest in “Lean Sigma” by military and government agencies in the USA.
Anyway, there’s lots there to play with, and it puts some data behind what had been largely anecdotal up to this point. Of course, any data-hound worth their salt will already be wondering where the data is coming from, what it really means, how it was gathered, what sort of processing done, etc, etc. These are all valid concerns, especially since Google takes the time to point out the following:

"Google Trends aims to provide insights into broad search patterns. As a Google Labs product, it is still in the early stages of development. Also, it is based upon just a portion of our searches, and several approximations are used when computing your results. Please keep this in mind when using it."
Elsewhere they go into a little more detail:

“Google Trends is a Google Labs product, which means that it’s still in an early stage of development. The data Google Trends produces may contain inaccuracies for a number of reasons, including data-sampling issues and a variety of approximations that Trends makes use of. We hope you find this service interesting and entertaining, but you probably don’t want to write your PhD dissertation based on this information. We’ll aim to update the information provided by Google Trends monthly.”
So have fun, but consider yourself warned!  If you are interested in Google trends, you can find out more about it here. ]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 31 May 2006 07:30:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: What We Ask Our Black Belts To Do]]></title>
			<link>http://blogs.isixsigma.com/archive/what_we_ask_our_black_belts_to_do.html</link>
			<description><![CDATA[I am regularly asked what characterizes an ideal Black Belt candidate. Like most people in the field, I have a list of adjectives and descriptive phrases I can trot out at a moment’s notice. Mine comprises about 50 items under the following headings: 1) Aptitude For Change; 2) Education and Experience; 3) Intellectual Curiosity; 4) Leadership and Interpersonal Factors. If pressed, I have a PowerPoint version of my list that I can speak to. If really pressed, I have even organized my list into matrix that can be used to score candidates. But to be honest I find that one good conversation with their manager is usually more informative than completing the matrix.
Every time the question comes up, I have the same thought after answering it: in order to define what characterizes an ideal Black Belt candidate, we first need to understand what we expect Black Belts to do. And every time I try to do that, I’m struck by some basic problems. Because often, we seem to expect them to do everything.
Consider a basic tool taught in most Six Sigma curricula: the SIPOC, which stands for Supplier, Input, Process, Output, Customer. (Some organizations cleverly reverse the acronym – COPIS – to emphasize that the customer should come first. Others add additional letters in various spots.) The purpose of a SIPOC is noble – to understand the entire process at high level, beginning with the supplier and ending with the customer. And while the Black Belt normally has a team in place to help them formulate and develop the SIPOC, it’s the Black Belt who owns the tool and the project at the end of the day.
It’s right about here that I start to get confused about what we are asking Black Belts to do. The dogma is that projects need to start and end with the customer, plus include the entire value stream, plus reach out to suppliers, plus touch on multiple functions within the organization. And while there can and should be a project team in place, the ultimate responsibility for all of these things does lie with the Black Belt. But how many Black Belts are suitably qualified (via experience, positional authority, contacts within the organization, etc, etc) to reach out in all these directions effectively? Can you think of a single individual in your organization that you’d be comfortable asking to do all of those things – personally visit with customers, work with suppliers, cut across internal functions, etc, etc? In my experience those people are extremely rare, and many of them already have “chief” somewhere in their title.
So where does that leave us? We need to develop Black Belts through training and experience, of course, but that takes time a multiple projects. What to do on the first, second, and third projects? Picking the right team is one obvious answer, but if the Black Belt doesn’t know what they are doing to a certain extent in all areas, then picking teams members who are very good at their particular function may or may not turn out well in the end. And it’s not easy to do, because those people are typically in very high demand. Anyone who has seen a wave of 20-30 (or more) Black Belts all attack their first projects at once knows this firsthand.
My suggestion is that the organization in general, and the Six Sigma (or equivalent) function in particular, should bear some responsibility for managing the interface between generation of knowledge (i.e. finding out what to do) and the execution pathway suggested by that knowledge (i.e. doing it). Put another way, perhaps the role of the Black Belt ought to be to investigate, understand and recommend…but execution and other aspects of realization ought to be left to those who best understand the area where the activity will occur.
For example, why do we ask Black Belts to go out and listen to voice of the customer? Don’t we have sales and marketing functions that ought to be doing that? Presumably those folks will be much better at it than a newly minted Black Belt anyway because, frankly, they ought to be experts. And if the sales and marketing folks aren’t good at it, then perhaps we ought to focus on that problem rather than institutionalizing a workaround via Six Sigma training. Which I think is what we are really doing if we give Black Belts end-to-end responsibility for a project. We’re admitting that our functions don’t work well together. If we ask a Black Belt with an engineering background to go out and listen to voice of the customer, then we might win the battle for the specific project (although in practice I actually don’t think this happens very often), but we lose the war for organizational effectiveness as a whole. And that’s definitely not what we should be asking Black Belts to do.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 04 May 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Does It Actually Matter What We Teach Black Belts?]]></title>
			<link>http://blogs.isixsigma.com/archive/does_it_actually_matter_what_we_teach_black_belts.html</link>
			<description><![CDATA[In an earlier blog entry (here), I described my feelings on DMAIC and roadmaps in general. To make a long story short, I don’t believe they add much value to the core toolset of Six Sigma. A couple of folks quite rightly expressed their disagreement with my view via comments (here). I say quite rightly, because I don’t have data to back up my hypothesis that the roadmaps don’t matter. To get that data it would be necessary to run experiments at a program level comparing projects (or even entire deployments) done with and without a roadmap. I haven’t done that, and I don’t know of anyone else that has either.
Lack of data, however, generally doesn’t stop me from speculating. And in that spirit, while we’re talking about program-level and deployment-level experiments, there’s one that is even more fundamental that I have often thought about. It’s a scary one to consider about for those of us whose jobs, in whole or in part, involve arranging and facilitating Six Sigma training. The experiment essentially asks the question: does it really matter what we teach Black Belts?
Let me explain. Any Six Sigma program that I’ve ever seen or heard of (or any continuous improvement program, for that matter) starts off with a pitch to executives in which some version of the following conditions are laid out, either by external consultants or an internal champion:

We need your absolute best people;
We need to free up those people to focus exclusively on Six Sigma work;
We need the most important projects to work on;
We need to make sure those projects are properly scoped and resourced;
We need to ensure that the organization supports people working on these projects from top to bottom.
Conditions 1-3 are usually the toughest to satisfy for reasons which are perhaps obvious, although 4 and 5 aren’t exactly easy either. In fact, most deployment leaders will tell you that a high percentage of their time is spent on 1 and 2 alone for the first few years of a deployment. Nevertheless, assuming the program is agreed to and competently managed, we end up somehow bringing our best folks together for four intense weeks of training, during which the concepts, tools, and methodology of Six Sigma are taught. Projects gets worked, and results happen. Everyone’s happy.
My question is this: what if we did exactly the same thing, but didn’t teach Six Sigma? What if we got our best folks together in a room one a week for four weeks over four months, focused them exclusively on the most important projects to the business, and gave them the resources and support they needed to get the job done…but didn’t teach them any new methodology? Would the outcome be materially different than if we taught them some roadmap or program?
In other words, maybe satisfying the conditions 1-5 – which make no mention whatsoever of methodology, roadmaps, DMAIC, statistics, etc, etc – is what continuous improvement really amounts to. Maybe the “sexy” methodology and jargon only provide a to a way to get the organization to agree to conditions 1-5 in the first place. Maybe the whole Six Sigma ball of wax is no more than a means to create the will to satisfy conditions 1-5.
This is the experiment that I invariably run in my head each time I go to a training event. I am struck every time by how bright and energetic the participants are, and how quickly they come together and make progress on their projects. This occurs in spite of – or perhaps because of – the fact that they are usually drawn from different geographies and business units. I’ve been involved with training programs that I think are absolutely top notch, but nonetheless I wonder…would these folks make more progress if we just got rid of the obstacles and let them get down to it with out interfering? Do we really need to teach them anything?
My hunch is no. I suspect if we truly got the best people focused on the most important projects with the right resources behind them, we wouldn’t actually have to teach them a thing. The problem is that conditions 1-3 are extremely difficult (maybe impossible?) to produce in the absence of a program with a lot of “sizzle”. That is, it’s relatively easy at this point in history to sell a Six Sigma program with all the attendant hoopla, but for whatever reason it’s hard to sell the idea of simply getting our best people working on our most important projects with everything else cleared out of the way. Perhaps when it comes down to it, the only reason to have a Six Sigma program at all is to create conditions 1-5. Maybe what we teach truly doesn’t matter.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 20 Apr 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: What's The Point Of A Project?]]></title>
			<link>http://blogs.isixsigma.com/archive/whats_the_point_of_a_project.html</link>
			<description><![CDATA[
In a perfect world, every project would lead directly to financial gain. We’d draft a charter that, when well executed, produced savings or income that translated directly to the bottom line. And this would be good because we all like making money. We can put it in the bank, earn interest on it, add many small amounts together, and eventually buy the things we need and want. That’s true of both businesses and individuals. We like financial gain not for itself, but because we enjoy the benefits that financial gain can bring. So, we conceive of most projects along the lines of the structure below.

Trouble is, the link between project goals and delivering financial gain is seldom as direct as we’d like it to be. Although there are exceptions, most projects require an intermediate series of steps wherein it is necessary to learn something. In other words, although we’d all like to proceed directly to financial gain, we usually don’t know how. So the project ought to be about going out and gaining some useful knowledge, then turning that knowledge into financial gain. The picture ends up looking something like the structure below. As I said before, there are exceptions (a project to increase capacity on a known product or service in an underserved market, for example), but in my experience the vast majority of Six Sigma projects have to follow the knowledge gain pathway because it’s the most efficient route to financial gain. If this wasn’t true, then the project would probably be addressed through some other methodology.

This being the case, it’s worth thinking about what we teach our Black Belts, and what we demand of them in terms of intermediate and final results. Certainly we all want the benefits of financial gain in the long run, and every project ought to have financial metrics. But if we recognize that knowledge gain is almost always a necessary precursor to financial gain for Six Sigma projects (and particularly if we believe that knowledge gain is the most efficient route to financial gain), then we ought to include in our methodology and metrics a way to capture and evaluate what has been learned as well. In fact, I believe this so strongly that I often insist problem statements be re-worded to emphasize knowledge gain at least as much as financial gain. Just like money can be banked and accrue interest, so too can knowledge. If we emphasize and value knowledge gain in our projects we end up not only making money, but increasing the level of knowledge in the organization as well. And just like with money, we can store knowledge away, assemble small amounts into larger ones over time, and pull it when we need it on a rainy day. In others words, knowledge is a bankable currency in the organization, just like money. 

In fact, looking at the diagram above, one might take the view that stored knowledge actually has more much intrinsic value that stored currency, because well-managed knowledge can be converted into dollars more than once; that is, even though we can withdraw at will from the knowledge bank, our store of knowledge does not deplete. Further, we have control over when and how we convert knowledge into financial gain, so it is a very flexible currency as well.
This is certainly not an original observation - indeed, I’m fairly confident that diagrams like the ones above have been scratched out in many organizations for more years that I’ve been alive - yet how many Six Sigma projects have metrics that measure knowledge gain in addition to financial gain? It’s a continuous improvement truism that we need to measure what’s important to us. My contention is that our measurements should include an assessment of what is being learned in addition to what is being accomplished. Properly managed and focused Six Sigma projects ought to deliver both knowledge gain and financial gain, and to make that happen the project (and program) metrics need to reflect both streams.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 06 Apr 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma Beyond DMAIC]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_beyond_dmaic.html</link>
			<description><![CDATA[There is a strong tendency for Six Sigma programs to forge an inextricable link between project management roadmaps, notably DMAIC, and statistical tools. This has never made much sense to me. In my experience, Six Sigma programs can not only exist and survive without the use of typical roadmaps, but prosper and flourish.
In the vast majority of Six Sigma environments, it borders on heresy to even ponder whether some, if not all, projects couldn’t perhaps be completed without the use of a roadmap. While it is probably the case that the DMAIC framework is efficient and appropriate for a certain subset of projects in most organizations, I have never been able to accept it as the panacea that most people in the field seem to. And by people, I mean consultants and executives. Not experienced practitioners, because by the second or third Six Sigma project most folks on the front lines eventually realize that toll-gate driven roadmap processes consume enormous amounts of time and energy in the form of meetings. In fact, I suspect the majority of seasoned Black Belts would abandon toll gate reviews in a hurry if they had the choice.
Consider a class of 24 Black Belts, all of whom will complete 2 projects in a year. Suppose (conservatively) that each project team has 5 members, and (again conservatively) that each toll gate review will take 30 minutes. That adds up to 120 hours of time spent in meetings involving those who are supposedly the best and brightest in the company. And what do those meetings produce? Certainly they gather stakeholders together to inform and discuss aspects of the project. But do they make a material difference to the outcome of the project? In other words, would the end result be better, worse, or the same if we gave the Black Belt responsibility and authority to organize the project and team meetings as they saw fit, as opposed to imposing a DMAIC structure? I submit that in my experience there are few negative consequences to abandoning the toll-gate-roadmap approach, and numerous positive consequences. Fewer meetings are one such benefit…admittedly one of my favorites!
It is undoubtedly true that DMAIC and other roadmaps are: a) easy to teach; and b) easy to administer. This makes the roadmap approach a darling of consultants (who see a consistent and portable program that can easily be taught in many different environments) and executive management (who see that DMAIC in particular lends itself to tidy dashboards and displays). But do the steps add value to a product or service? In most organizations I suspect the Lean folks would consider canceling toll gate meetings an easy, quick-win project. My hunch is that they would be correct in most cases.
What’s the null hypothesis here? If the tacit assumption taught by consultants and embraced by executives asserts that roadmaps and tollgates are necessary, the hypothesis that needs testing is something to the effect of “does a program without any toll gates or roadmaps result in any statistically significant differences compared to a program based on DMAIC or some other roadmap?” And if there were differences, would they be positive or negative? In short, what are we getting for all the time spent on toll gate reviews and roadmap compliance, if anything?
My own view is that there is an infinite variety of improvement opportunities out there, and it’s nonsensical to suggest that any single roadmap will serve a significant portion of them well. Tacit agreement with this view is provided by the flurry of supplemental roadmaps that have appeared (and continue to appear) over the years since DMAIC was first introduced. So the test for the null hypothesis is both simple and audacious: run a Six Sigma program that does not depend on any particular roadmaps and see what happens; teach the tools of Six Sigma without the framework of DMAIC (or any other framework) and evaluate the results; trust practitioners of Six Sigma to decide for themselves how projects should be managed, when meetings should happen, what stages are appropriate for a project. In short, let go of structure and embrace flexibility.
As organizations turn more and more to innovation as a wellspring for continuous improvement, what we ought to be creating is not wave after wave of people who can follow roadmaps well, but rather creative map-makers who can and do chart new paths to any destination. To do that, we need to explore Six Sigma beyond DMAIC.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 30 Mar 2006 07:16:28 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: About Blogger: Andrew Downard]]></title>
			<link>http://blogs.isixsigma.com/archive/about_blogger_andrew_downard.html</link>
			<description><![CDATA[Andrew DownardDirector, Lean and Six SigmaNewell Rubbermaid Andrew Downard is the Director, Lean and Six Sigma for Newell Rubbermaid, a global manufacturer and marketer of consumer and commercial products. Newell Rubbermaid is headquartered in Atlanta, Georgia, and has approximately 30,000 employees worldwide. Currently splitting his time between Atlanta and Toronto, Canada, Andrew is a certified Black Belt and Master Black Belt. His previous experience includes continuous improvement director, deployment leader, and Six Sigma practitioner positions in the chemical industry and global health/medical services. Andrew holds a B.Sc. and Ph.D. in chemistry from the University of Calgary, Canada.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[Blogger Bios]]>
			</category>
			<pubDate>Thu, 30 Mar 2006 07:15:00 -0800</pubDate>
		</item>

	</channel>
</rss>
