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.

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?

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.

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.

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?

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.

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.

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?

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.

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.