Does Six Sigma apply to IT? This question is heard quite often. It echoes questions that have been asked many times since the first attempts to apply Six Sigma beyond manufacturing. Does Six Sigma apply to finance? Healthcare? Banking? Software? Insurance?

In each of those areas the answer turned out to be “yes,” as widely publicized Six Sigma successes have been achieved in all of these, and many others. The question itself is usually an indication of skepticism and resistance — the old “I’m different, this doesn’t apply to me” argument. Recapping some of the successes that have been achieved with Six Sigma in IT and describing some of the IT activities to which Six Sigma can be applied, should make it clear the answer to the IT question also is a resounding “yes!”

First, let’s define “IT” (Information Technology). In most organizations, IT includes a range of activities that may include acquisition, installation, operation and support of various hardware and software infrastructure components, including PCs, networks, office-support tools and communications facilities. Some IT organizations also develop and/or acquire and tailor application software systems. Most operate centralized or decentralized computing centers (data centers). Some operate help desks or call centers; some provide business process re-engineering services and internal consulting to facilitate business process improvement.

In a general sense, there is a distinction between IT groups focused on development versus those focused on operations. Here the focus is on the operational aspects of an IT organization.

Published Reports on Six Sigma in IT

Here are some examples of organizations that have achieved significant successes in IT using Six Sigma:

• Bank of America has cited [ISSSP Conference, June 2003] the following:
  o Reduction in DPMO (defect per million opportunities) in average weekly systems availability from around 4,500 to less than 1,000 in 12 months.
  o Reduced check sorter jams by 25 percent.
  o Improved cycle time for statement copies from 60 percent within service level agreement to 100 percent.
• Raytheon Aircraft’s IT department has used Six Sigma to improve claims processing and save the company $13 million. [CIO Magazine]
• The IT organization at Raytheon Aircraft saved $500,000 from a single project in 2002. [CIO Magazine]
• The nine CIOs at Textron saved a total of $5 million in six months. [CIO Magazine]
• One team of engineers at Fidelity Wide Processing expects to deliver $6 million to $8 million in cost reductions this year. [CIO Magazine]
• Seagate’s IT department booked direct savings from Six Sigma analyses of $3.7 million during the previous fiscal year. Since instituting Six Sigma two years ago, the IT department has saved $4.5 million overall. [CIO Magazine]
  o “We’re being a lot more rigorous with maintenance contracts. We got a team together, analyzed what was needed and defined what maintenance level we wanted. That saved $1.5 million right there.” [Mark Brewer, Seagate CIO]
  o “Data files were taking too long to transfer to another system for analysis. The delay resulted in further delays in detecting control problems, which would then delay corrective actions. When the project began, it was not clear at all that the transfer time was the reason for the control problem. By applying the Six Sigma methods to this problem, the root cause was found and appropriate tuning was done to the network and file server (lowering process time from 19 minutes to five). We saved $1 million right there.” [Mark Brewer, Seagate CIO]
• Enterprise Management Associates recently conducted research on the use of Six Sigma for managing IT service quality that indicated 65 percent of those surveyed acknowledge the relevance of Six Sigma for IT-based service management.

There are many other examples, but perhaps these are sufficient to make the point — Six Sigma does apply to IT, as evidenced by significant successes.

Making the Critical Business Connections

One of the issues faced by many IT organizations is the fact that management often views IT simply as a cost center — a necessary evil that they would really prefer to do without. Or maybe outsource as soon as possible. This is a short-sighted point of view. Six Sigma often leads to a more enlightened conversation about the value of IT.

One of the key Six Sigma concepts that can greatly facilitate a better, more fact-based conversation between IT and the business is the CTQ (Critical to Quality) flow-down tree. CTQ flow-down is a deceptively simple, yet powerful, idea that can help an organization understand the value IT may be able to deliver when it is viewed and managed in a Six Sigma context.

The basic idea of the flow-down tree is to start with high level business outcomes (“big Y’s” or dependent variables) that define business strategy objectives in a quantitative way. These goals are “owned” by top management — in theory, everything the organization does is in service of those goals. The high level Y’s flow down to lower level Y’s that can be allocated or assigned to progressively lower levels of responsibility within the organization, and can ultimately be decomposed to potentially controllable “x’s” or independent variables linked to root causes.

We can then begin to solve problems and issues by converting those practical problems to fact-based problems using the “Y=f(x1…xn)” equation that underlies all Six Sigma thinking. This equation acknowledges the fact that outcomes (Y’s) are not directly controllable, but are a result of lower level factors, the x’s, that are at least potentially controllable by actions the organization may take. In practice, some x’s are “noise variables” that are not actually controllable (factors such as season, day of the week, weather) and others that are controllable. Among the controllable x’s there are typically a “critical few” that are much more important than the “insignificant many.” This simple but powerful idea is at the heart of all Six Sigma improvements, and it works in every domain of business activity, including IT.

Let’s consider a simple example of CTQ flow-down and see how it might be used to generate a fact-based conversation between IT and the business sponsors who pay for the services IT provides.

Let’s suppose this example comes from an organization that does charge card processing. “Float” (uncollected funds) and bad debts are important business issues for an organization such as this. Suppose that top management has established a strategic goal to improve return on equity (ROE) as illustrated here — that is the “big Y” in this instance. Obviously IT can’t do much about that goal directly, and most likely no other part of the organization can either. But, we can break it down into smaller Y’s, such as optimizing the collections process, and management can assign responsibility for that to a specific department or unit.

The collections unit may choose to measure their contribution to that overall goal in terms of something like “days sales outstanding” (DSO). In order to drive DSO down without increasing collections costs, they will need to make the best possible use of available call center staff that calls delinquent customers. Larger financial institutions have hundreds of people in the call centers, and specific goals for number of customers contacted each hour of each day. When the contacts fall short, collections fall short as well. Collections, a lower level Y, are driven by the number of calls placed — perhaps an x (likely one of many potentially important x’s).

When we think about this a little more deeply, we realize that the number of calls is not actually an x, rather it is yet another lower level Y — it is in turn being driven by other lower level factors. These lower level factors might include the number of call center staff, the average time per call, and doubtless other factors.

At last, we get to the point where all of this flows down to IT. Clearly one of the important x’s that drive number of calls is the availability of the IT systems used by the call center staff. They can’t call if the phone network or the customer database is unavailable. Hence, collections effectiveness is driven in part by the service level provided by the IT organization.

Now that we’ve taken a quick tour of how a big Y might flow down to IT, let’s consider the opposite perspective — how IT performance “flows up” to higher-level financial outcome measures.The collections unit will know the average collection amount per call, which can be combined with an IT-derived measure of “unavailable user-minutes” (system element down x number users impacted x time unavailable). With these facts in hand, the business value of a reduction in user minutes unavailable can be calculated. Now we know not just what IT costs, but also what the services it provides are worth to the business, and how they are traceable to top-level business goals.

The thought process described above is applicable to every type of IT activity. It is always possible to quantify the contribution to business outcomes that can be achieved by improvements in IT cycle time, cost, availability, or quality level.

Note — Readers are invited to contribute examples of Six Sigma applications in IT, and are welcome to participate in the discussion forum by asking questions and offering comments.