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.
Here are some examples of organizations that have achieved significant successes in IT using Six Sigma:
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.
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.