Fixing or otherwise improving a process usually involves changing it in some way. For this reason, Six Sigma projects almost always involve some element of process engineering or re-engineering. On top of that, folks in deployment leader roles or similar are often tasked with developing brand new processes like project selection, candidate identification, certification, and a range of others. And of course there are a myriad of situations outside the Six Sigma world that involve creating or altering processes.
One failing I see in myself (and in many new Black Belts) is a tendency to develop ideal processes on paper, without addressing elements of human behavior. I suspect it’s a by-product of being trained in a highly data-driven methodology. We expect that if we can use good data to demonstrate that a process change will result in an improvement, then people will automatically change their behavior. Put another way, if we ourselves are convinced by data, we assume everyone else will be as well.
In my experience there are a few problems with this view. One is that it does not hold for everyone: some folks are not, in fact, convinced by data. Another is that complicated statistical data are difficult to communicate effectively across large organizations. And finally, even those who are intellectually convinced will almost certainly need to be provided with additional motivation to change their behavior.
I’m not going to give a lecture on change management here. What I want to talk about instead is the relative difficulty of changing human process behavior versus standard Six Sigma process work. And more particularly, the order in which we address the two related areas.
I have been in many situations when, in response to a genuine gap or need, a new process is designed or purchased. Software implementations are a great example of this. The perfect process is laid out on paper, the process tools procured, and the process rolled out in the organization with the best of intentions. But I have seldom seen it work well, or even have any lasting effect, unless considerable work is done to change human behavior first.
Take, for example, project tracking systems. In more than one case I have been in organizations where there is basically no project tracking prior to Six Sigma deployment. It is identified as a need as part of the deployment plan, and software is purchased. But once the system is set up, no one uses it even though it is a great system.
It has taken me a long time to learn that in this situation, the most effective first step is to focus on behavior and implement something simple. A one-page template that is collected manually each month and rolled up into an offline project spreadsheet is a great first step. Work hard to get folks doing that and see what happens. Learn from the experience and iron out the kinks in the rudimentary process. Once you get good at that and folks are used to it, then take the next step; maybe a simple online database that everyone can access directly to enter their information. Take the time to tweak that database and figure out what reports are useful, as well as what functionality you really don’t need. The take the next step, and the next one, and the next one. Before you know it there will be a robust process that people are used to following. And even if the “home-made” process is clunky and hard to manage, it’s an amazingly short step from here to a beautiful, gleaming, streamlined process. If you grow the process yourself you’ll know what you need from a software vendor when the time comes, and you’ll know what to expect from the folks who interact with the system. In short, you’ll be automating something that already works, rather than trying to go from nothing to perfection in one step. And crucially, you’ll already have established the necessary patterns of behavior among the people interacting with the process. In my experience it’s a lot easier to map the process/software to existing behavior than vice versa. So it’s worth taking the time to get the behavior right before you decide on the software, even though it’s a very messy process.
Project tracking is just one example, but in my experience the general conclusion holds in most situations. “Process or behavior?” is not a “which comes first, the chicken or the egg?” question like I’ve often heard suggested. And designing or purchasing a new process won’t automatically create behavior, the claims of vendors notwithstanding. These days I find it most efficient to crawl before I walk, before I jog, before I run, etc. I live through the messy home-made solutions before I automate or even finalize process in the organization. I work on building the process behavior before I build the process itself.
