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.

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.

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:

1. 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;
   
2. 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?

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.

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.

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