Which Comes First: Process or Behavior?

Fixing or otherwise improving a process usually involves changing it in some way. For this reason, Six Sigma projects almost always involve some element of process engineering or re-engineering. On top of that, folks in deployment leader roles or similar are often tasked with developing brand new processes like project selection, candidate identification, certification, and a range of others. And of course there are a myriad of situations outside the Six Sigma world that involve creating or altering processes.

One failing I see in myself (and in many new Black Belts) is a tendency to develop ideal processes on paper, without addressing elements of human behavior. I suspect it’s a by-product of being trained in a highly data-driven methodology. We expect that if we can use good data to demonstrate that a process change will result in an improvement, then people will automatically change their behavior. Put another way, if we ourselves are convinced by data, we assume everyone else will be as well.

In my experience there are a few problems with this view. One is that it does not hold for everyone: some folks are not, in fact, convinced by data. Another is that complicated statistical data are difficult to communicate effectively across large organizations. And finally, even those who are intellectually convinced will almost certainly need to be provided with additional motivation to change their behavior.

Handpicked Content:   Belts in Part Time Roles

I’m not going to give a lecture on change management here. What I want to talk about instead is the relative difficulty of changing human process behavior versus standard Six Sigma process work. And more particularly, the order in which we address the two related areas.

I have been in many situations when, in response to a genuine gap or need, a new process is designed or purchased. Software implementations are a great example of this. The perfect process is laid out on paper, the process tools procured, and the process rolled out in the organization with the best of intentions. But I have seldom seen it work well, or even have any lasting effect, unless considerable work is done to change human behavior first.

Take, for example, project tracking systems. In more than one case I have been in organizations where there is basically no project tracking prior to Six Sigma deployment. It is identified as a need as part of the deployment plan, and software is purchased. But once the system is set up, no one uses it even though it is a great system.

It has taken me a long time to learn that in this situation, the most effective first step is to focus on behavior and implement something simple. A one-page template that is collected manually each month and rolled up into an offline project spreadsheet is a great first step. Work hard to get folks doing that and see what happens. Learn from the experience and iron out the kinks in the rudimentary process. Once you get good at that and folks are used to it, then take the next step; maybe a simple online database that everyone can access directly to enter their information. Take the time to tweak that database and figure out what reports are useful, as well as what functionality you really don’t need. The take the next step, and the next one, and the next one. Before you know it there will be a robust process that people are used to following. And even if the “home-made” process is clunky and hard to manage, it’s an amazingly short step from here to a beautiful, gleaming, streamlined process. If you grow the process yourself you’ll know what you need from a software vendor when the time comes, and you’ll know what to expect from the folks who interact with the system. In short, you’ll be automating something that already works, rather than trying to go from nothing to perfection in one step. And crucially, you’ll already have established the necessary patterns of behavior among the people interacting with the process. In my experience it’s a lot easier to map the process/software to existing behavior than vice versa. So it’s worth taking the time to get the behavior right before you decide on the software, even though it’s a very messy process.

Handpicked Content:   Variable vs. Attribute Data: What’s the Difference?

Project tracking is just one example, but in my experience the general conclusion holds in most situations. “Process or behavior?” is not a “which comes first, the chicken or the egg?” question like I’ve often heard suggested. And designing or purchasing a new process won’t automatically create behavior, the claims of vendors notwithstanding. These days I find it most efficient to crawl before I walk, before I jog, before I run, etc. I live through the messy home-made solutions before I automate or even finalize process in the organization. I work on building the process behavior before I build the process itself.

Comments 5

  1. Diane Schmoller

    I would like to submit another example. One team at work met for 6 months to come up with a new computer screen to communicate shipping dates. The team concluded, and I was tasked to verify its effectiveness. Through quick and easy interviews, I found out that only 50% of the workgroup entered the required data. All the rest were “exceptions” due to “meeting my customer’s needs”. Without verification, the great, new process would have limped along at 50% effectiveness for months, I am sure. Was this was caused by an inadequately designed process or behavioral noncompliance? Why this was not discussed in the team meetings may be the biggest root cause.

  2. Andrew Downard

    Hi Diane,

    Great example! This is exactly the sort of situation I’ve encountered in the past. What might have been a good intermediate step? Perhaps you could have had folks in the workgroup manually fill out forms that you (or whomever) entered then complied manually for 1-2 weeks, or whatever period of time made sense. Sure, the manual work would have been annoying, but the problem you describe likely would have been flagged right away. Then you could decide how to deal with the exceptions: alter the process to deal with them, or work on the behavior so they don’t occur as much in the first place. The choice would be yours. Either way, it could have been ironed out before the screen went online to begin with. Sometimes that bit of “inefficient” and annoying manual work can save a lot of time in the long run.


  3. Bruce Wilder

    Excellent points. Getting the "human sigma" right is a prerequisite for successful six sigma projects. That being the case, why do so many people trained in six sigma methods not guide their teams into considering the human factors when designing for six sigma in the first place. In other words, why are the human processes left out of the DMAIC/DMADV models and thought somehow to belong outside those models? Human factors should show up and be considered in the "analyze" phase.

  4. Andrew Downard

    Hi Bruce,

    I don’t really know the answer. I’m not a roadmap guy, and I’m not prepared to defend DMAIC/DMADV on this point. You have highlighted one of the many failings of these models.

    Also, by its very nature I think Six Sigma attracts those who believe being right is enough to change behavior. That is, if you have the data to show a solution is correct, then everyone should automatically rally around that solution and make it happen. While this response may in fact be be common among Six Sigma practitioners, it isn’t among the rest of the population. That means being right is only the first step in a much larger process of changing behavior. DMAIC and DMADV aren’t well-equipped to support that larger process.


  5. David Beard

    It’s all about the process. And people are typically behind any process. Get to the heart of the matter first, then work out the solution

    -= David

    Read more here:

Leave a Reply