Being Right

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.

Handpicked Content:   Communicate to Motivate

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.

Comments 12

  1. Daniel

    I agree totally that it is really important to ’drive’ the change, the program, the method…, there is no doubt. But painting a little bit black and white, driving consistently in the wrong direction (means, you’re just right by 25% leaves 75% undefined or wrong) may never lead to the harbor or town. By being 25% right, you must at least proof that the rest doesn’t have that big impact to the business. Just image driving a car on a public street, being 25% right all the time but wrong about 75%, won’t succeed for long, even if you do this very consistently ;)

  2. Andrew Downard

    Hi Daniel,

    Thanks for your comment.

    I’m not sure your analogy holds, and here’s why: when you are driving a car, you are entering a system with fixed rules that have to be followed to ensure success (and avoid death :)).

    That’s not the case for getting ahead in business. Go far enough up in the organization and you can MAKE the rules. (Subject to laws, regulations, etc, of course.)

    The question is, if you were the one in charge of designing the rules of the road, would you have to be 100% right about the decisions you made? Or would you just need a system that worked well enough, as long as everyone followed it?

    I think there’s an argument fr spending more time and energy on how to get people to follow the rules, as opposed to agonizing over every traffic rule and making sure it is 100% perfect.


  3. Daniel

    Hi Andrew.

    Thanks for the reply. Now I’ve got a better understanding. If we stay within the project scope of whatsoever project methodology, means, kind of micro system, that’s right. But taking a more bigger scope, let’s say, survival in business, the bigger scope has to fit to the market, the requirements of the customer, the rules the whole system is dictating. From my point of view, this is comparable with the traffic situation, you have to follow the rules or you will not survive. But by designing a system with a lot of interaction and ’hard to predict’ situations, it is better to do something and to do it forcefully, with clear guidance and support, that’s absolutly correct, as long as we do not talk about ’data-free’ and ’out of the belly’ decisions ;)

  4. Alex

    I agree with Andrew. Based on my experience, execution is very important for an improvement program like Six Sigma to work. Being right? Well, 25% is perhaps the lower limit (things can get a bit shaky below that level). The upper limit, at the same time, does not have to be at 100%. I’d say somewhere between 50% to 75% right should be good enough to push things ahead provided there is solid execution.

  5. John

    Thanks for your thought-provoking comments. I totally agree, and it was freeing to get out of my typical "six sigma box". My experience has been that organizations have a truck load of problems and opportunities, and if the organization gets focused, with leadership, change agents and some reasonable methodology……..improvement will occur no matter what. It becomes academic and turf protection to argue about being right. Method is not magical. Outcomes can be driven by different methods.

  6. Andrew Downard

    Alex, Daniel,

    Thanks very much for your comments.

    Don’t get me wrong…I’m not saying we shouldn’t TRY to be as right as possible. Things get a lot easier if we know what we are doing. I’m just saying it’s not necessary. It seems to me a tremendous amount of time and mental eneregy is spent agonizing over what amount to trivial methodological concerns. They just don’t matter in the larger scheme of things, especially compared with the problems of good execution, irrespective of methodology.

    This problem certainly isn’t unique to Six Sigma – that’s why there are general business books about it – but I do think it is an especially prevasive failure mode in the community.

    Daniel – I especially appreciate your thoughful response, which I agree with 100%.


  7. Naveen Bachwani

    A very good point, Andrew. And, very well put.

    I may not agree with the figure of 25%, but agree wholeheartedly with the spirit of the message:

    "The real value of any ’process improvement’ program is forging a common approach and methodology across the organization, and ensure that the infrastructural support is available".

    In the past year along, me and some team members have been exposed to training workshops in Six Sigma, Lean, TRIZ and CEMM. The obvious question on returning from any of these is – Which is the best solution-approach to adopt?

    One of the workshop’s trainers actually answered this question by narrating his encounter with Jack Welch. Reportedly, when asked something similar, he’d once remarked: "When you’re in trouble, any thing will work!"

  8. periwan

    A very interesting discussion.

    Just to make sure and to get the percentage right; You have to be right more than 50% of the time or You will go down..
    "Two steps ahead – one step back" or if You should go to the north You have to take more "northish" steps than "southish" to get there in the end.

    But there are also the problem with which problems You solve; You have to be right about the right problems to get it right.
    If You drive a car You better stay on the right side of the street or things will get somewhat troublesome (if You don’t drive in Japan, India, England and some other places, of course) but if You walk around a square somewhere You might just bump into some people without getting hurt and still get to the other side of the square in one peace in the end.

    So it comes down to

    First- Be right in the big issues
    Second- Make more "good" than "bad" decissions because You could always correct them later.
    If you stand still You won’t get anywhere and if You don’t get anywhere You will not get it right.

  9. Sue Kozlowski

    I like the car-driving analogy. You don’t have to drive EXACTLY in the geometrically defined middle of the road to get where you’re going – you just need to stay within the lines. (Although other drivers may appreciate if you learn to control the variation between the specification limits of yellow line and white line!)

    An excellent discussion point – thanks Andrew.
    –Sue K.

  10. Andrew Downard


    A few people have focused in on my "25% right" comment, and I feel compelled to defend it.

    First of all, let me re-iterate that we should strive to be right 100% of the time. I’m not advocating being lazy or sloppy.

    But even if you use control charts (for example)incorrectly 100% of the time, you can still do good work. Even if you violate the assumption of normality 100% of the time in your data collection and statistical calculations, it will seldom prevent you from making the right conclusions. Even you you use the "wrong" map or tool for a given situation every time, you can usually still move in the right direction.

    This why I think being right 25% of the time is sufficient, possibly even more than sufficient. Not desirable, but adequate.


  11. Dean Robinson

    Six-sigma is supposed to be a continual improvement process isn’t it? So as long as the processes are continually improved at a 25% rate then eventually you’ll approach the 100% level, but in the mean time the product will have improved incrementally.
    Maybe it’s also worth remembering that in Boyd’s Orient, Observe, Decide, Act (OODA) loop, an incorrect decision followed in quick succession by a new OODA loop correcting the error is better than a much slower, even if 100% correct, decision cycle.

  12. Andrew Downard


    I love it! I’m not familiar with Boyd or OODA loop, but that’s exactly what I’m getting at.

    I’ll add that the joy of being WRONG in a structured project environment like Six Sigma is you find out you are wrong very quickly. And often what you learn by being wrong is equivalent in value (at least) to what you learn if you are right. When testing a hypothesis, for example, it really doesn’t matter if your hypothesis is accepted or rejected. It just matters that you know.

    Thanks for your comment.


Leave a Reply