Business improvement initiatives and process improvement efforts work because people adopt new ways of doing things. The key to success is to focus on people and behavior.
Let’s talk about what happens when our process improvement efforts and our business improvement initiatives succeed. Do our initiatives work because we send out a memo? Does process automatically improve because we draft a new process map? Of course they don’t.
We make them work because we communicate, we set expectations, we enforce new rules and policies, we reward good outcomes, and we correct poor ones. In short we follow through and doing so makes our changes take place and improvements happen.
Think about it for a minute. What are we really changing? We change maps and instructions; sometimes we change leadership. We might start using new metrics or vocabulary. That’s all true, but just because those things change it doesn’t mean performance improves.
Some processes work better because we change the process flow and the instructions. Some processes work better when we don’t follow them and we do something else instead (we have all experienced those). However, just because we change everything about the process, or about our business guidance, it doesn’t mean that anything changes except our diagrams and paperwork.
Change takes place when people change how they do things. If you follow my posts, then you have read me write this same message before. I repeat it because it is the “unspoken,” not understood, under-focused secret to performance success. In fact, if we can effectively change the way people do things without maps, diagrams, new vocabulary, new metrics, policies, or work instructions, we can affect change with a great deal less of red tape.
Unfortunately, so many of us, and I think it is safe to say that all of us have at some point, fallen into the trap of focusing on the tangible items to affect change. Yes those things help. They facilitate the change by helping to communicate expectations, correct or incorrect behavior, and sometimes by giving us an enforceable set of rules for reward or disciplinary action. But all those tangible components don’t make the change occur.
Change occurs when people change what they do and/or how they do things. People change when we effectively communicate new expectations and then enforce them.
Where am I going with this? The most important success element to a business leader, a functional leader, a team leader, or a change agent trying to drive change and improvement is the ability to perceive, focus on, and influence people’s behavior. Does that sound like an obvious statement?
Let’s look. Examine the last process improvement or performance improvement change that you drove or in which you participated. Did you focus on people’s behavior when you planned and executed it, or did you focus on the documentation and the map? Did you discuss how people were going to do things differently, or how the process would be diagramed differently?
It’s an easy trap. We make pictures of what people do so we can analyze them. The picture is a communication tool, but we become focused on the picture and sometimes forget what the picture represents. Then, when we are done with the objective abstract of the process or the business program, we use pictures to communicate what we change, but we sometimes communicate how the abstract picture changed, not how people’s behavior is expected to change. Oops.
Let’s look at some real examples to help clarify. First, a very simple manufacturing change. A business decides to eliminate waste in assembly that occurs when one assembler hands off a product to another. Instead of each assembler doing a single step and passing it on, each assembler will complete the entire assembly operation.
The business changes from a linear assembly table with a bin of singular components in front of each station, to a circular table with bins containing all of the parts at the center and tools allocated to each station. The workers are shown their new assembly area and set to work. Someone forgot to explain properly how the new station works (there is a language barrier too between the process designer and the assemblers).
The first few minutes are very confusing. When things finally get going, there is much arguing among the assemblers, more confusion, and finally one of them gets the attention of the line lead, and then the process improver comes over to answer questions and try to understand why the new process is not working right away.
The brave assembler explains that there aren’t enough stations for each of the assembly steps. After much more confusion the problem becomes clear. The assemblers are still performing a single assembly step and then passing the product-in-process to the next station for the next step.
Some of you are reading this and thinking, “there is no way that such a silly example actually happens.” Some of you are reading this and thinking about all of the times you have witnessed such a silly thing actually occur. And no, the assemblers aren’t really that dumb. They aren’t dumb at all. They are only trying to do things the same way they have been trained and told to do them and that worked perfectly well before. It was the process designer who was so dumb that he thought the round table and all the parts and tools would somehow make it work better.
Of course, with some explaining, training, improved communication, and much mentoring among the different assemblers to instruct their team members in the best way to perform assembly steps they hadn’t really learned before, things began to roll.
This is an example of where the focus was directed so completely on the process map that no one took the time to explain it at a person-activity level. And yes, it really happens.
Another example for discussion: I was a manager for an engineering design team and it was performance review time. I had one employee who neglected one objective altogether and I was obligated to reduce his merit reward accordingly. The process for documenting and recording this occurrence worked very conveniently for the management staff and for the Human Resources function, but not so well for the employee.
I followed the process very strictly, and the employee was the last person to find out. As you can guess, and as I should have, he was humiliated and outraged that the management and HR teams knew about it and had already decided the fate of his salary before he even found out or had an opportunity to present his argument. He left the company shortly after and our business lost a very good engineer.
From that experience on, I refused, openly, to follow that particular process. I always addressed my performance evaluation and merit recommendations with my employees first. Yes, this was disagreeable with HR and with the next level of management, because it made things inconvenient if my recommendations or findings were refuted. I was careful to warn my employees that it could happen.
I was given a talking to about it at one point in time. I recounted my experience and pointed out that my employees trusted me, and frankly the process, better when it was done this way. I also pointed out that the process was there to serve the employees, not management or HR. The customer of the process, ultimately, was the employee. Lastly, I admitted that I deliberately did not follow the process, but challenged my leaders to explain where I had done anything unethical or wrong.
I never heard another word about it. In fact my manager at the time agreed to support my decision after the meeting was over, and many of my peers opted to follow suit, because they too felt the conundrum of doing what was right by their employees vs. doing what the process dictated.
This is an example of a process and the right thing being at odds. The process was built to protect the business and to prevent employees from being treated unfairly by managers. Unfortunately, it did not take into account the feelings of the employees if the process was followed. It lost focus on whom it was supposed to serve and it inadvertently drove unfortunate behavior, perceptions, and responses.
One last one with which we might all identify. Let’s look at a common stage-gate or phase-gate style product development process. The purpose of a gated process is to help keep the design effort focused on a reasonable expectation of solving the development challenge by a certain time and to manage risk so that the development doesn’t spend too much of a business’ money developing a failed product.
That is the purpose. However, in just about every application I have ever witnessed, businesses follow a strict gated product development process and still produce products that fail. Sometimes, more products fail than succeed. Where is the disconnect?
Yes, by now you can anticipate my answer. Just because we follow a process map that calls for certain activities in a certain order, and for approvals to proceed based on proving the design is ready to do so, does not mean that the right behaviors to mitigate risk and develop excellent designs are truly taking place.
If the gate meeting ends up with the executive passing the project on to the next stage or phase in spite of evidence that things are not ready (pet project syndrome), the behavior fails to meet the objectives or intent of the process. Similarly, if the same review meeting is simply a brief examination of a checklist to see that all the boxes are marked, the intent of determining if the design is truly ready to proceed is not satisfied.
The gated product development process breaks down in a great many ways. People advance the project in spite of identified risk and development because there is a schedule to keep. People delay the project because a box on the checklist isn’t checked, even if it isn’t really relevant to the product in question. In short, people become concerned with the letter of the process instruction, or in providing an appearance of following the process, and they forget to focus on the reasons and expectations of the process.
The failures are behavioral and not because the process map is wrong.
If you want to truly drive improvement and business initiative success, then learn to focus your insights and attention on the behaviors, not the process. When you plan a change, ask and answer the question, “What behaviors are we looking for?” Don’t just think about them. Write them down in clear terms for each step of the process, and for the whole process.
Digital media is cheap and easy these days; leverage it. Get out of your comfort zone and produce a role-play video of the proper behavior and make that video part of the instruction. Demonstrate the behavior; don’t just show a process map.It also helps if you think there is a behavior that people might be inclined to adopt based on past performances; demonstrate it as what not to do. Also make it clear what is not acceptable. It’s a digital video version of the is/is-not process analysis tool.
In terms of learning how to have an eye or a mind toward behavior instead of abstract process art, here are a few of the questions I find myself asking when I am trying to do the same. I offer them up as inspiration or a starting point:
- Whom does this process or initiative serve?
- Explain to me why this is the best way for everyone involved?
- Prove to me that your decision is right for the business
- What does it look like when a person does that?
- Why is that easier or better for the person doing it?
- Why would a person do it that way?
- How will the person doing that feel?
- How will a person respond to that?
- How will you determine right from wrong?
As you start to make a habit of thinking behavior instead of abstract art, you will find yourself naturally adopting certain questions that spur the correct thoughts for your own analysis. Here is my challenge for you. Start the exercise by examining the improvement you are currently doing, or the one you just did. Re-evaluate it based on behavior. Look for the communication, the understanding, or the opportunity that was missed and fix it. You will see a difference.
Almost all of the improvement training from every flavor across every industry teaches us a methodology using diagrams and maps. They provide tools and vocabulary so we can coordinate our efforts and speak a commonly understood language. But, the part of our training that is woefully under-examined is how to focus our effort on the behavior of people.
Take your personal leadership and change implementation skills to the next level. Move your process improvement and business improvement programs to the next level. Focus on how to influence people to change the way they do things. Let all of the tools and diagrams and documents be secondary. Stop asking what the map should look like and, instead, ask what people doing the better thing looks like.
Stay wise, friends.
If you like what you just read, find more of Alan’s thoughts at www.bizwizwithin.com.