Black Belt Project Part 7: Control Plan

Once we completed our improvement plan, the next task was to build policy and alter our culture to maintain the benefits. This was not particularly difficult given the structure and culture of the advanced technical support team.

First we presented the results of the project to the support team at their weekly staff meeting. They were enthusiastic about the results. This simple presentation served to institutionalize the changes to a large extent. Everyone on that team had a clear understanding of why we changed the process and what the changes did to our output variables. Those involved in the project team were certain to include this accomplishment on their yearly review. Few things leave an impression on employees as effectively as substantial, monetized accomplishments.

We also implemented a poke yoke device of sorts (pronounced poh kah yoh kay). A poke yoke device is a simple, inexpensive feature or addition to a product or process that keeps the operators from making mistakes. Some examples include the spill drains in sinks and tubs as well as the gas cap tethers you see on most newer cars.

In our case, the poke yoke device was a simple alarm in the team’s web-based survey tool that would flag the survey maintenance team if the survey exceeded the agreed upon maximum number of survey questions. The development work was trivial and the potential benefits are tremendous. This would remind the administrator if they experienced a momentary lapse (“Oh, that’s right—need to keep this survey to fewer than 12 questions…”) When the team moves a new administrator into the role of maintaining the surveys, the new administrator will receive automatic training that ensures they are aware of the institutionalized process practice.

Black Belt Project Part 6: Multi-Vari Analysis

The purpose of Multi-Vari analysis is to measure the amount of variance your process produces in the output variable(s) and investigate the relationship between the input and output variables.

My first task, then, was to place the average handle time data for the last 10 months in a control chart. My goal was first to determine whether the group’s average handle time over time was distributed within a standard normal distribution. In laymen’s terms, this would tell me whether my process was consistent enough to manipulate and make calculated improvements.

If a process does not fall within a normal distribution between the third standard deviations, it is likely that the process is not yet standardized. You might, for example, have different operators—agents in my case—that handle calls in significantly different ways.

Fortunately, in our case, the majority of the daily average handle times fell within the third standard deviations. The exceptions occurred on holidays (when call volume is much lower) and on a few very high call volume days when the management instructed agents to abandon the regular survey process in an effort to handle as many calls as possible. Interestingly, the latter variations provided potential evidence that reducing the number of survey questions might, indeed, reduce handle time.

One other curiosity demanded my attention: Did the amount of time that the agent had been performing his or her job relate to that agent’s average handle time? I ran a correlation test using 10 months worth of handle time data and found that there was not a relationship between the two. This analysis served two purposes: 1) it appeared that agent tenure did not introduce systematic variance in the average handle times of the group and 2) it helped to dispel a long-held belief in our organization that more tenured agents on the advanced technical support team will generally have lower average handle times. That said, it is possible that there is a relationship in the other technical support groups.

As a Six Sigma rookie, I moved on to the improve stage at this point. In future projects, I found that it is usually requisite to conduct more in-depth analysis than a simple statistical process control chart and correlation test. In this case, for example, I might have also conducted a multiple regression analysis to see whether the number of questions in the survey (which changed minimally over time) predicted average handle time to any extent. This would have strengthened my case for reducing the number of survey questions.

To some it may seem obvious that removing questions would result in shorter handle times. That was certainly my expectation. However, it is important to note that the advanced technical support group, though they have higher handle times, also obtain higher customer satisfaction scores than the other technical support groups. As such, I resolved to compare advanced and general group customer satisfaction scores after altering the call handling process to assess whether lowering handle times also lowered customer satisfaction scores.

Black Belt Project: Part 5—Failure Mode and Effects Analysis (FMEA)

Now that we have an idea of the relationships between our input and output variables, the next step is to move on to the Failure Mode and Effect Analysis (FMEA). The primary goal of an FMEA is to assess which process steps create the most variation in your overall process–that is to say, the process steps which are most likely to result in defects. For your reference, I used a form similar to the form found here.

The way this works is that you start with the top items from your cause and effect matrix. Recall that these top items will include the inputs that have the greatest potential impact on your customers.

In the FMEA form, you detail the ways by which your inputs can impact your output variables and result in a defect–this is a failure mode. Again, in this case, a failure mode would be an especially long call. I chose the top four or five inputs and mapped out the various ways that each could fail.

In an FMEA you score each failure mode on three metrics: Severity, frequency, and your ability to detect failures. After I mapped out each potential failure mode for the top inputs, it quickly became clear where failures occurred that I might be able to prevent.

In my case, the top two failure modes were related to two of the process inputs: the actions recommended by the technical support resolution tool and the questions asked on each data collection survey. There were several other obvious inputs but the ability to detect them was very low and efforts to build ways to predict them would be very difficult. For example, identifying personality traits of individual agents that lead to longer handle times would be possible. However, attempts to change or work around these traits would likely be more difficult than other “low hanging fruit” inputs.

My FMEA concluded that I should look further into the questions in the data collection surveys and the actions recommended by the technical support tool. I quickly realized that the most direct route to reducing the average handle time of the technical support calls would be to reduce the number of questions on this particular survey. This was because the general technical support survey included several questions that were useful for more advanced technical support issues but that were not necessary for general technical support issues.

Black Belt Project: Part 4—Cause and Effect Matrix (C&E Matrix)

Fancy name for a sorting exercise, I thought. I have found, however, that the Cause and Effect Matrix is more effective than simple prioritization exercises. The primary goal of a C&E matrix is to identify which inputs you should include in your subsequent Failure Mode and Effects Analysis (FMEA)—usually this will include the factors that have the most impact on your final customers.

Most training organizations supply an Excel spreadsheet that you use to detail the value of each of your output measures to your customer(s) and rate the relationship of each of your process inputs to these output measures. The form I used on my project is located here: Six Sigma Templates.

The first step is to identify the output measures that impact your customers. In some cases, you may find yourself asking, “Who are my customers, anyway?” This is also a worthwhile exercise because Six Sigma is supposed to help keep you focused on making tangible results that positively impact your customers and help your organization’s bottom line.

Once you have identified your customers, the next step is to identify the output variables that impact your customers. This essentially weights each of the output variables which is then used in the calculation to identify the steps of your process that are most likely resulting in defects (in the service industry think, “poor service, lost revenue, increased costs, etc.”)

Next you list each of your input variables and rate each in terms of its relationship with the output variables. Once you complete these ratings, the C&E Matrix calculates the impact that each input has on the overall process. Those with the highest scores should be included in your FMEA.

In my project, the output measure was call handle time. I found that the inputs most likely to increase handle time included the technical support database content used by our support agents and the case survey questions the agents filled out on each call. Because the support database did not fall within my control, I chose to focus on the other key input factor: the case survey questions.

The advanced technical support group uses a case survey tool to capture vital information about the issues that customers experience, what they found in terms of diagnostic information, and what they did to resolve the customers’ issues. These data are then fed back to the operations and software development teams so that the issues may be resolved.

Each survey includes several questions and each question takes time for the agent to walk the customer to the appropriate place to obtain the information. This was the process input that I investigated most extensively in my FMEA. Stay tuned for the exciting story of failure modes and their effects!

Black Belt Project: Part 3–The Process Map

I have to make a confession: I did most of the work on this project on my own and then presented it to the “project team” after I completed the work. I have learned my lesson: This was a mistake. Nevertheless, the project was still meaningful and still produced cost savings because I was lucky.

Different Six Sigma training organizations seem to use different methods for mapping out processes. In my case, I initially used an Excel spreadsheet to map out my process at high and detailed levels. This method assumes that the process is very linear in nature. Sometimes I have found that this is not the reality in the service industry.

Others use things such as SIPOC or fishbone diagrams. SIPOC also assumes a linear process but fishbone diagrams trade off sub-process information for a little more freedom. Specifically, they do not require that you identify the order in which sub-processes occur. In fact, they only require that you identify the X & Y variables (inputs and outputs) involved in a process. Fishbone diagrams also have the advantage of working well as a tool for a project team meeting. Leigh provides a good explanation of fishbone diagrams. I believe that it can be useful to have a project team meet, create a fishbone diagram, and then have the black belt (or two, if more than one is involved) go off and create the process maps based on the information gathered with the fishbone diagram.

The main value I found in the process map in this project was that it prepared me to complete the failure mode and effects analysis (FMEA) by identifying the key process steps, inputs, and outputs. I had a clearer picture of the steps involved in the process so that I could effectively evaluate potential failure points.

I also found clarity, definition, and distinctions between the inputs, outputs, and processes. Obtaining this clarity is vital to several of the later steps in the DMAIC approach–gives you a better footing for decisions as to where to attempt improvements, for example.
Lessons Learned:
– Don’t try to do the process map on your own–involve the project team in a fishbone diagram session and then flesh out the detailed process map
– Spend enough time to map out your process well because it is the foundation for the rest of the work in the DMAIC approach. If you skimp on the effort invested here, your project is more likely to fail. Fortunately in my case the process was relatively simple but I have found that I was not so lucky in later projects.

Black Belt Project: Part 2–The Project Charter

Project Charters–when I learned about project charters my initial thought was that Six Sigma is too formal and that it is no wonder that our company has not adopted it formally. Nevertheless, I went through the motions of creating a project charter as part of my black belt project. I used an Excel file template which you can download at the following link: Six Sigma Downloads.

Technically, the project champion initiates creation of the project and team and then the project team completes the charter. At our company, however, we do not have a ranking executive with Six Sigma training that initiates formal Six Sigma projects.

While we do not have a top-down Six Sigma implementation, we do have a Vice President with green belt training that understands the value of rigorous quantitative analysis and she graciously acted as the champion for my project–after I put the bulk of the charter together. She was an obvious choice for the role of champion because she has green belt training but more importantly because she is the overall owner of the process I wanted to improve.

My project team was relatively small: It included the VP champion, another black belt at the company, the department manager (the proximal owner of the process I hoped to improve), a supervisor from the same department, and myself. I wanted to keep the team small for two reasons. First, I did not want to include anyone that was not totally committed to improving this process. By that I mean I did not want to include anyone that would get cold feet and bail out or that would not care about improving the process. Secondly, I have found at our company that larger, cross-functional groups have a terribly difficult time making shared decisions in a timely fashion. That is a relatively kind way of saying that very little gets accomplished in larger, cross functional groups. By larger I mean more than about five people.

As I identified the team, I quickly began to realize the value of the charter. In this and subsequent projects it became very clear that establishing a champion and setting roles for each team member is critical to the project’s success. It is very easy for various people at a company to convince others to shut down your project. Often this occurs as a result of the ignorance of those not involved. A champion is a must.

Perhaps the most valuable part of a charter is identification of the process and definition of the problem and goal. Because I had never conducted a Six Sigma project previously, I took the responsibility of defining the problem statement and project goal. Fortunately, I had an opportunity to run my ideas past the black belt on the team and she confirmed that in this case, we had a clearly defined problem statement with a quantifiable output variable and a reasonably narrow scope.

In the end, my problem statement was, “The average handle time for general technical support calls for the advanced technical support team is 10 minutes higher than the average handle time for the general technical support queue. This higher handle time (just the portion above and beyond the handle time for the general queue) costs the company nearly $1M annually.”

The project charter template required that I identify several other pieces of information that help define the project. These included the business case (which I incorporated into the problem statement–the estimated potential savings), scope of the project (to ensure that I didn’t end up trying to “boil the ocean”), the benefits to external customers (to ensure that I focus on improving a process that benefits customers), and a project timeline (another way to ensure that the scope was set appropriately).

Lessons learned in creating my first project charter:
– Choose your champion wisely–you don’t want to risk your project shutting down due to lack of support/buy-in from others
– Spend the time up front to clearly define the problem, the team, the roles people will play on the team. A little time invested up front could save you a lot of heartache or even failure down the road

Black Belt Project: Part I–Choosing the Project

The first challenge that Six Sigma students encounter is selection of a black belt project. This usually occurs either right before training begins (many programs encourage you to identify a “problem” process to work before your first day) or some time during the first week of training.

Because there were several of us in our division that attended the same class as well as a small team of Black Belts in our division, we arranged a meeting with the students and Black Belts. The students were asked to present at least one, but ideally two or more, project ideas. The Black Belts then asked each of us a series of questions to help us narrow the scope of our problem statements. By the end of the meeting they also provided advice for each of us on how to conduct some simple analysis that would help us ensure that our problem statements had merit–i.e., that what we identified as a problem really was a problem.

During this meeting I learned several important things that have helped me since. First, one of the Black Belts encouraged us to choose a project that fell within the domain of our department. This would increase our chances of success because we would be less likely to find our projects squashed by higher level managers from other departments that did not understand the potential monetary savings or increased revenue. While this sounds like a rather cold, harsh view of the business world, this advice has proven itself both timely and worthy.

The other worthwhile advice I picked up at this meeting was the idea that a project should have a relatively narrow, very defined scope. This is where I first heard someone use the phrase, “You should not try to boil the ocean.” Most people experience the temptation to make a really big difference on their first shot at Six Sigma process improvement. Those that insisted on conducting really, really big projects later had to reduce the scope or stalled and even abandoned their projects in some cases.

The way this struggle worked in my case was this: I wanted to do something out of the ordinary. I did not want to get caught in another seemingly futile attempt at squeezing more productivity out of our under-trained, under-equipped technical support agents (please excuse me, that was my sometimes pessimistic internal voice speaking.) On the other hand, I understood the risks associated with attempting to refine a process that is controlled by several departments. So, realizing that my primary goal here was to learn how to use the Six Sigma process and obtain certification, I settled for the former–attack the problem of long transactions on technical support calls.

Another reason for selection of this project was that our division’s director had requested that we reduce our transaction length. While this may seem rather intuitive for most I should provide some context that casts that request in a slightly different light. The team of advanced technical support agents is a specialized group at the company that handles tier three issues in addition to standard issues. Usually a tiered support strategy employs a third tier that does not have stringent transaction length goals. Part of my reasoning for choosing this project was that I wanted to see whether reducing their transaction length really made sense from perspectives other than direct monetary support costs. For example, what would happen to customer satisfaction scores when we reduced the amount of time on each call?

Another reason that we knew this would likely be a worthwhile project is that employee costs make up the largest part of our company’s SG&A (operating costs–Selling, General, and Administrative). The reasoning was that if we can reduce transaction time, we will not need to hire as many agents which will reduce administrative costs.

My final problem statement was, “The advanced technical support team’s average call handle time is twenty-two minutes–approximately four minutes higher than budgeted which results in cost overruns of approximately $210,000 annually.” And with this, the adventure began…