Gary A. Gack and
David L. Hallowell February 26, 20102
Having identified and verified ways that support cost is driven by staffing ratios, process factors like transfers and callbacks, and the proportion of phone and web traffic, the Six Sigma project team of the IT services business began identifying and selecting among solutions. It had entered the Improve phase. The DMAIC roadmap called for work in these areas during the Improve phase:
I1. Identify Solution Alternatives to Address Critical x’s: Consider solution alternatives from the possibilities identified earlier and decide which ones are worth pursuing further.
I2. Verify the Relationships Between x’s and Y(s): What are the dynamics connecting the process x’s (inputs, KPIVs) with the critical outputs (CTQs. KPOVs)?
I3. Select and Tune the Solution: Using predicted performance and net value, decide what is the best solution alternative.
I4. Pilot / Implement Solution: If possible, pilot the solution to demonstrate results and to verify no unintended side effects.
Work done during the Analyze phase identified several areas of prospective improvements that could deliver project results. The solution alternatives were:
| Driving Xs (from Analyze phase) | Solution Alternatives |
| Staffing | + Add staff Mondays and Fridays, reduce staff on Sundays + Develop staffing model + Create on-call list to fill-in for absentees |
| Web Service Percentage | + Focus on services that can be done best on the Web + Define and communicate the value prop to customers + Evaluate incentives to move traffic to the Web |
| Transfers and Callbacks | + Improve call center processes to reduce transfers and callbacks without impacting customer satisfaction |
The team began to think through how each of these alternatives would work – how it would compare/contrast with the current state, and what the costs, benefits and risks are regarding each CTQ for each of the following stakeholders?
Business: Net value = ($$Benefit – $$Cost) and other benefits and risks.
Customers: Functionality and value.
Employees (as appropriate): Working conditions, interesting work and growth opportunities.
To understand and compare each solution alternative, the team realized it would need to describe and characterize each of them with respect to the key requirements. The characterization work is the core of step I2, and the population and work-through of the selection matrix is the main activity in I3. A solution selection matrix (Figure 1), empty of evaluations during I1, formed the basis of the team’s planning for the characterization work. (The matrix is an extract or simplified view of the “real thing.”)
| Figure 1: Solution Selection Matrix Drives the Characterization Work in I2 |
![]() |
For each solution alternative, a sub-team worked through a series of comparisons and characterizations in order to check and quantify the key x-Y relationships that could be exploited for that alternative. Each group began by determining the magnitude of the potential business benefit. To do that, it was necessary to know the x-Y relationship, known as the “transfer function.” If the potential benefit appeared to be significant, then the group had to evaluate how the improvement might be implemented, and what it would cost. Obviously the alternative passed if benefits meaningfully exceeded the likely cost of the improvement. If not, it was eliminated.
The staffing option is an illustration of the process used. To examine the other options, the team followed similar thought processes, but perhaps applied a somewhat different combination of tools. To evaluate the staffing option, the team asked this series of questions:
1. Which variables will be impacted, and by how much? Wait time, support cost, volume/staff (v/s) ratio.
2. How will the benefit be measured? Value of account growth minus the cost of additional staff.
3. What chain of analysis will be used to show the connection between additional staff and account growth? By definition, staffing drives v/s ratio. Does v/s ratio drive wait time? Does wait time drive account growth? How many staff might be added? How would that impact wait time? How much benefit would that staffing level produce? What would it cost?
Using regression analysis with the data collected, the team saw that the variation in wait time seemed in part to be related to the v/s ratio. (Figure 2) While this did not prove causality and there clearly were other influentialing factors, the team suspected a meaningful connection (subject to stronger proof later) and decided to pursue this clue further.
| Figure 2: Wait Time vs. V/S Ratio |
![]() |
Next, the team wanted to know if wait time was driving account growth – and, if so, by how much. The team again applied regression analysis. (Figure 3) It appeared that 61 percent of the variation in account growth could be attributed to wait time. Again, this was not conclusive proof, but wait time was a worthy suspect.
| Figure 3: New Accounts vs Wait Time |
![]() |
To understand the number of staff that might be added or reduced, the team considered each day separately. The team decided to see what would happen, on paper, if the volume/staff ratio for each day was adjusted to the overall average – i.e., increase staff on Mondays and Fridays to get to the average v/s ratio, decrease staff to get to the average v/s ratio on Sundays. The team found that meant adding 14 people to the call center staff on Mondays. Combining what it had learned about the wait time-v/s ratio connection (Figure 2), the team forecast a 1.18-minute reduction in wait time on Mondays. The team used the following calculations:
As Is = .63 + (.215 x 23) = 5.57 Minutes
To Be = .63 + (.215 x 17.5) = 4.39 Minutes
5.57 – 4.39 = 1.18-Minute Wait Time Reduction
The team then evaluated the likely impact of wait time on new account growth using information from Figure 3.
As Is = 1.06 – (.0315 x 5.575) = 0.884%
To Be = 1.06 – (.0315 x 4.3925) = 0.921%
.921 – .884 = 0.037% New Account Growth
The accounting department was asked to provide some of the facts needed to find out the incremental value of the projected new account growth. They reported that there were 1,484,000 accounts and the average annual profit per account was $630. With this information and what the team already knew, it could calculate the financial impact.
0.037% New Account Growth x 1,484,000 Existing Accounts = 549 New Accounts
549 Accounts x $680 Average Profit Per Account = $345,870 Incremental Annual Profit
Next the team calculated the additional staffing cost and the net benefit to the business.
Staff Cost = 14 People x 8 Hours x $30 Per Hour = $4,480 x 50 Weeks = $168,000
$345,870 Incremental Profit – $168,000 Staff Cost = $177,870 Project Net Benefit to Business
The team completed a similar quantitative analysis of each of the options. Included among them were one on web service and one on transfers and callbacks. An improvement summary was written for each.
Web Service Implementation Summary
Benefit: $280,080 (savings of $1,167 x 240 days per year).
Approach: Increase client awareness about web service and help clients see how easy it is to use. (Figure 4)
Risks: Verify that the web system can handle increased volume. Verify that customer satisfaction does not slip.
Method: Insert in upcoming mailings describing web services and interface. Announcement on the phone router switch that answers all calls.
| Figure 4: Why Clients Do Not Use Web-Help Service |
![]() |
Transfer and Callback Implementation Summary
Benefit: $143,293 (annual savings of $104,233 + additional profit of $39,060).
Approach: In a focus group session with current staff, it was learned that almost half had not be trained on policy and system changes implemented nine months before. The data was stratified by those trained and those not. A t-test was used to compare transfer and callback percentages. The comparison showed that the untrained were more than three times as likely to have high percentages (p=.004). The conclusion was provide training.
Risks: No way to calculate how quickly the training will drive the percentage down. There may be a learning curve effect in addition to the training. Also making staff available for training is an issue because training is only done on the first Monday of each month.
Method: Considering risks, the decision was made to train 50 percent of those in need of training and evaluate the impact in a three-month pilot program. If that worked, the second half would be trained in the following quarter.
Costs: One day of training for approximately 15 people in the pilot program = cost of training ($750 per student x 15) + cost of payroll (8 hours x $50 x 15) = $14,850. If fully effective immediately, this penciled out to about half of the potential benefit. Discounting for risk, the team projected a first quarter gross (before costs) benefit of approximately $50,000.
When the team had completed a similar quantitative analysis of each of the options, it prepared a summary comparison and was ready to make recommendations for the next steps.
The team did not pursue tuning the solution in the context of this project, although it recognized there might be opportunities to further optimize performance of the web component.
Based on everything the team had learned, it recommended:
Before moving into the pilot phase, the team decided to meet with one of the Master Black Belts to get a sanity check on its work to that point.
The Master Black Belt reviewed the team’s work through I3 and raised strong concerns about the forecasts it had made for the increased staffing option. He pointed out that weaknesses in the measurement system feeding values into their regression analysis, together with the wide prediction interval around the team’s estimates (which had been treated as precise point values) put considerable risk around the expectation that projected benefits would be realized.
Although the Master Black Belt’s feedback was a bit sobering, the team still felt it wanted to go ahead with the pilot program. But it decided to do an interim review with the Champion first, including briefing him on the MBB’s perspective. Here’s a snippet of the Champion’s reactions to the review:
“First let me say I think this team has done a fine job so far – you’ve found potentially substantial savings, you’ve got good supporting factual information, and you’ve pointed out the risks and uncertainties brought out by your MBB.
“While I don’t at all dispute the issues brought out by the MBB, my perspective is a little different than his. The CEO has told me in no uncertain terms that he wants our account growth to match the competition, and soon. He made it clear this is a strategic imperative. Customers have lots of choices, and we could lose out big time if we don’t turn this around right away. It has been let slide for too long as it is. So, in spite of the issues raised by the MBB, I’m prepared to spend some money to pilot this because if it works, we will get quick results. It is evident that adding staff will help us more quickly than any of the other options. We can always cut back staff later as these other improvements take hold. Turnover in this area is high anyway, so reducing staff will be painless when the time comes.”
The team developed a plan for the pilot program in staff training that addressed the practical considerations for success.
Details of the plan for the Monday staffing pilot program included the following elements:
The team then conducted the pilot program and evaluated the results. The objective was to do before/after analysis (hypothesis tests to evaluate significance of outcomes), ask what was learned, refine the improvement if indicated and confirm or revise the business case.
A number of significant questions needed to be answered in the results of the pilot program. Among the most important questions and answers were:
1. Did the additional staffing, and the resulting change in v/s ratio, impact wait time as expected? The team looked at the results month by month to see if there was a learning curve effect with the new staff. There was an effect, but the new staff nearly caught up by the end of the third month. During the first month, “new staff” calls took seven minutes longer than “old staff” calls. During the second month, the difference was down to 2.5 minutes. And by the third month, the difference was about one minute. (Figures 5, 6 and 7)
| Figure 5: Two-Sample T-Test for Call Length – Month 1 New & Old |
![]() |
| Figure 6: Two-Sample T-Test for Call Length – Month 2 New & Old |
![]() |
| Figure 7: Two-Sample T-Test for Call Length – Month 3 New & Old |
![]() |
2. Did wait time decrease as expected? Wait time was lower by 10 percent – just what was expected when the staff was increased by 10 percent.
| Figure 8: Two-Sample T-Test for Wait Time & New Wait Time |
![]() |
3. Did the new staff have any impact on transfers? New staff had slightly more transfers, but the number was not statistically significant.
| Figure 9: Two-Sample T-Test for Transfers – Month 1 New & Old |
![]() |
4. Did the new staff have any impact on callbacks? New staff had 1.5 times more callbacks. This was a concern. The team needed to determine if this was a learning curve issue, and if not, how the additional callbacks can be controlled.
| Figure 10: Two-Sample T-Test for Callbacks & New Callbacks |
![]() |
5. What happened to customer satisfaction? New data on customer satisfaction after the pilot program confirmed the team’s expectation of improvement. The company moved from less than 73 percent to about 74.5 percent.
| Figure 11: New Boxplot for Customer Satisfaction |
![]() |
After the pilot program on staffing was complete, the team was ready for the Improve tollgate review with the project Champion. Here is what the team reported on the staffing issue during the review:
The Six Sigma project team reached the final step in making significant improvements to the operation and profitability of the call center of the IT services business. After the company’s senior leadership did the pre-project work, the team followed the first four steps of the Define-Measure-Analyze-Improve-Control methodology and entered the final phase. The DMAIC roadmap called for work in these areas during the Control phase:
C1. Develop Control Plan: Include both management control dashboards that focus on Y(s) and operational control indicators that monitor the most significant process variables, focusing on the x’s.
C2. Determine Improved Process Capability: Use the same measures from Define and Measure in order to provide comparability and monitor impact in a consistent way.
C3. Implement Process Control: Create, modify and use data collection systems and output reports or dashboards consistent with the control plan.
C4. Close Project: Prepare the implementation plan, transfer control to operations, conduct project post-mortem, and archive project results.
The Control plans addressed two views – one concerned with management control and the other with operational control. Management control includes a focus on the Y(s) or outcomes of the process and often some of the x’s as well. The level of detail was decided upon based on the interests of the specific managers concerned – some want a lot of detail, some much less. Hence, the management control plan needed to consider individual preferences so as to deliver enough – but not too much – information.
The operational control plan was more concerned with the x’s that are predictive of outcome Y(s). Operational control information included both controllable and “noise” variables. Operational control information was provided more frequently than management control information.
Both types of control information pertinent to this case study are illustrated in step C3.
The team linked the capability of the improved process to the baselines and targets identified during Define and Measure. It was important to use the same measures. (If it was necessary to change the measures, then baselines and targets would have had to been restated in those terms to enable comparison.) Many different statements of capability were considered, including mean/median, variance, Cp, Cpk, DPMO, sigma level, percentile rank, etc. The team knew that to a great extent these alternate characterizations are equivalent and the choice is largely one of preference. However, the team made its choices so that all concerned could have a common understanding of the meaning of the measure. The table below is the way the team chose to present the following data.
| Measure | Baseline | Target | Current |
| Business Growth | 1 percent | 3 percent | Requires More Time to Measure |
| Customer Satisfaction | 90th Percentile = 75 percent Satisfaction | 90th Percentile = 85 Satisfaction | Need More Data |
| Support Cost Per Call | 90th Percentile = ~ $40 | 90th Percentile = $32 | ~ $35 |
| Days to Close | 95th Percentile = 4 Days | 95th Percentile = 3 Days or Less | 3 Days |
| Wait Time | 90th Percentile = 5.8 Minutes | 90th Percentile = 4 Minutes or Less | 4.4 Minutes |
| Transfers | 90th Percentile = 3.1 | 90th Percentile = 2 or Less | 1.9 |
| Service Time | Mean: 10.5 Minutes StDev: 3.3 Minutes | Mean: StDev: | Mean: ~ 8.8 Minutes StDev: ~ 0.9 Minutes |
The first current performance values were prepared from the pilot program results with plans for updating monthly or quarterly thereafter. To determine the initial values, the team considered the following:
Customer Satisfaction Percentile – The pilot data indicated an improved customer satisfaction at about 77.5 versus a baseline estimated to have been 70 to 80 percent. The team recognized this was a very small sample, so it decided not to make a claim on this until more time elapsed.
Support Cost – Using the analysis below, the team determined that the 95 percent confidence interval for support cost per call in the improved process was $33.50 to $33.90 versus about $37.00 for the baseline. The p-value indicated this change is significant. The team used Minitab to calculate the 90th percentile value as $34.94.
| Support Cost | Support Cost |
| $37.50 | $33.40 |
| $36.00 | $34.00 |
| $38.40 | $33.50 |
| $40.00 | $33.90 |
| $39.90 | $33.50 |

Support Cost Per Call Improved Process Percents Calculated By Minitab Percentiles Macro | 75 Percent | $34.60 $34.76 $34.90 $34.94 $35.14 |
Days to Close – Using the macro illustrated above, the team determined the 95th percentile value for the improved process days to close during the pilot was 3 days.
Wait Time – Although the data to determine the baseline value was not initially available, it was determined based on additional data collected and analyzed during the Measure and Analyze phases. The baseline was 90th percentile = 5.8 minutes, and the improved capability 90th percentile was 4.4 minutes.
Transfers – The team determined the 90th percentile baseline to have been 3.1 or less and the improved process value was 1.9 transfers.
Service Time – Baseline mean service time was 10 minutes with a 95 percent confidence interval of 9.7 to 10.4 minutes, while the improved mean was 8.8 minutes with a 95 percent confidence interval of 8.6 to 8.9 minutes.
| Figure 1: Summary for Service Time Baseline |
![]() |
| Figure 2: Summary for Service Time Improved Process |
![]() |
The team began by planning the data collection process to be used, including preparing operational definitions for each data element and automated tools whenever possible to minimize expense and effort. Heeding W. Edward Deming’s message to “drive out fear,” the team was careful to prepare a well-thought-out communication plan to ensure the staff knew how the data was to be used and to address any concerns about punitive uses of the data. The team recognized that if members of the staff thought the data would be misused, they might be tempted to distort the data.
The team also verified that the process was under procedural control – i.e., standards and documentation were up-to-date and the staff understood and followed the intended process. In preparation for implementing control charts on some of the process variables, the team recognized the segmented some of the data, such as “issue type.” Significant variations were expected across, but not within, issue types (e.g., “problem” versus “question”).
The team selected the appropriate form of control chart to suit each situation to be monitored. (Figure 3)
| Figure 3: A Control Chart Chart |
![]() |
One of the control charts the team implemented (Figure 4), monitored days to close for issue type = Problems. Similar charts were prepared for other issue types and for support cost.
| Figure 4: Days to Close – Problems |
![]() |
Implementing process control means more than preparing control charts. The team also defined a process for analyzing the output in order to help the operations group determine the right course of action when an out of control situation is encountered. One of the tools they used was the Minitab “data brush.” This tool isolates potential “special cause” data.
The team deployed a full set of control charts that monitored all of the variables of interest, but it also recognized a need for an overview to give a broader perspective without all of the detail. To satisfy that need, the team designed two “dashboards” for use by executive management and the call center. These dashboards overlap somewhat.
The team knew that new account growth and customer satisfaction were important to the senior vice president who runs the business unit served by this call center. The team recommended changes that were expected to impact these outcomes, so the vice president wanted to monitor what actually happened. He also wanted to see how these changes were impacting the cost structure.
The dashboards, one for the vice president and one for the call center manager, reflected both x’s (leading indicators) and Y(s) (trailing indicators).
The team’s final effort was aimed at wrapping up the project and transferring control to the call center group. This last step included:
-Developing and executing a plan to implement the improved process, including any necessary training.
-Developing and executing a communication plan that informed all those affected by the change.
-Conducting a transition review with key managers and staff, making adjustments and improvements they suggested.
-Establishing the timeline and responsibilities for the transfer, and executing the transition process.
-After an agreed interval, validating the financial benefits in conjunction with a representative of the finance department.
-Conducting a project post-mortem from multiple perspectives – the team, the Champion/sponsor, and the financial results. (Emphasis on process improvement, not critiques of individual performance.)
-Archiving in an accessible repository what the project team learned so other teams can benefit from it. (Special emphasis on items that have potential for re-use, and a “road-show” or poster presentation to communicate project results.)
-Celebrating! along with well-deserved acknowledgment of team contributions (both the Six Sigma project team and the operations team).
Return to Define, Measure and Analyze Phases
|
|
© Copyright iSixSigma 2000-2012. User Agreement. Any reproduction or other use of content without the express written consent of iSixSigma is prohibited. More »
Comments
Too good superb…Thank You very much!!!
Very good indeed