A continuous process improvement (CPI) is difficult to launch, but also difficult to maintain. Control charts are a good starting point for looking at data from a process to determine if it is normal and under control. Process mapping is important to understanding how the process moves through its lifecycle and how it interacts with different teams. Finally, focus groups and brainstorming are great tools to find out if the process you think you’ve documented is actually being followed in practice, or if there are areas crying out for improvements.
To truly succeed with the idea of continuous improvement, however, the core concepts and strategies of this process need to become part of the culture. It’s easy to say, “We support continuous improvement,” but in the day-to-day hustle and bustle of getting things done, it’s really easy to lose momentum. Before you know it, the CPI program has stalled or gone dormant.
So how do you keep it alive? By keeping it in front of the team. Make it part of every meeting and every one-on-one discussion, and encourage everyone to contribute.
A few years ago there was a book called The Toyota Way discussed many of the principles used by Toyota to ensure quality. One of the important details was the scope of their continuous improvement process, which included the ability of any employee to stop a process if they discovered a defect or problem. That’s an ideal culture for CPI, and one that as managers we need to encourage in our own teams. If the team doing the work is afraid to speak up, a process will stagnate and any defects will be passed on to the customer.
The Five Whys & Hows
This leads us to a few people-oriented tools that we can use regularly for continuous improvement. There is a tool in the LEAN methodology known as a Gemba Walk. In Japanese, Gemba means “the real place.” It could also simply be called “management by walking around”. Developing an informal, comfortable rapport with your team will give them the opportunity to provide their insight to management without the stress of a formal discussion. It builds trust in leadership because the team sees that management is interested in what they have to say, and it helps management see the team as individuals with a variety of skills and different ways of approaching problems.
When a problem is found, it’s important to determine the root cause. This is not always obvious, and sometimes what we think is the root cause is just one of the steps along the causal chain. The idea of root cause analysis dates back to the early 1900’s, and can really be boiled down to, “Why is this process failing?” There are a number of tools to help with this analysis, but one of the best and easiest is asking “why” five times. Five times is typically seen as optimal, but the questioning can continue beyond that until there is confidence that the root cause of the problem has been determined.
I consider the 5 Whys to be another people-oriented tool because it needs to involve a group of informed subject matter experts. A Five-Whys analysis can be done informally, but more frequently it is a formalized process, because there are some important rules. When doing this analysis, everyone involved needs to understand the following:
What is the problem? Work together to build a problem statement that everyone understands.
- Focus on causes, not symptoms.
- Take the time to build succinct, precise answers.
- Take it slowly and step-by-step, don’t jump to conclusions.
- Just the facts; avoid opinions.
- Focus on the process, not on people. Avoid the trap of placing blame.
- Keep asking “Why?” until the defect is eliminated.
Let’s look at an example based on an actual issue I encountered:
Without warning, incident ticket volumes increased exponentially, and the service desk and 2nd level support were swamped. The first answer to “Why?” was that customers couldn’t use critical applications. It was mostly reserved to internally developed, proprietary applications, but the issues were spread out across many different applications.
This led to the 2nd ‘Why”, which upon examination of the incident documentation showed that the applications were not displaying properly. The 3rd “Why?” moved us down the causal path by determining that the screen resolution was wrong. The 4th “Why?” got us to a change in the video drivers, and the final 5th “Why?” led us to the discovery of an operating system patch that was responsible for resetting the video drivers to the default resolution. With that root cause in hand, we were able to facilitate a push that reset the resolution back to the proper level.
The American Society for Quality (ASQ) suggests that we can also look at this from a different perspective. The Five Whys follow a causal path to determine the root cause of a problem. The focus is on determining what the problem is rather than finding a solution. As a result, in addition to using the Five Whys, ASQ recommends using the Five hows.
The Five hows tool attempts to drill down to a solution for the problem. So, in the above example, rather than asking why something is happening, the emphasis is on how to remediate the issue quickly. The first ‘How?’ is broad, how do we fix this? The second drills down into the solution – fix the display issues. The third ‘How?’ looks at how that can be done, by changing the display resolution. The final two ‘How?’ questions go deeper into a solution for the entire enterprise, ultimately determining that a patch needs to be pushed out to the desktops to fix the overall problem with display resolution.
The Five Whys and Five Hows tools are great brainstorming resources. The number – five – is just a suggestion, based on the typical number of questions it takes to reach the final outcome. Some problems may be resolved with fewer questions; others may take a few more. Some may result in a whole new branch of causality. The point of both are to help a group of subject matter experts focus on the issues and quickly – and factually – come to an effective result.
Michael Hanson has a broad background in information technology, and is an IT executive with 30 years of experience leading IT Operations, Service, and Support teams. He is ITIL, Six Sigma, and HDI certified, has a BS in Business Technology, and is a regular contributor to industry conferences and publications. His passion is building effective, happy teams and leveraging business and IT process improvement techniques to make processes more efficient, cost-effective, and reliable for both IT staff and their customers. Most recently, Michael was a Director leading IT Service and Support Operations at UnitedHealth group, where he led the global asset fulfillment and recovery teams as well as the national fulfillment center warehouse in the USA.