The basic five-phase model that many Six Sigma companies have adopted can benefit information technology (IT) organizations, even without the detailed measurements that are part of statistical analysis. Following the basic tenets of Six Sigma processes will help ensure that IT fully understands the problem, chooses the right solution to the problem, and implements that solution on time, using a schedule that customers have approved. The result is reduced rework, which translates into lower costs and higher customer satisfaction — two primary goals of most IT
departments.
THE FIVE-PHASE MODEL
IT organizations are accustomed to projects being broken into phases, typically those defined by a system development lifecycle (SDLC) model. Six Sigma initiatives are frequently described as using a DMAIC model, where DMAIC is an acronym for the five phases of a process improvement model. The phases and their primary objectives are listed in Exhibit 1.
Exhibit 1. The Five-Phase DMAIC Model
Phase
Objectives
Define
Identify the problem and the customers; define and prioritize the customers’
requirements.
Measure
Confirm and quantify the problem; identify and measure the various steps in the current process; revise or clarify the problem statement, if necessary.
Analyze
Determine the root cause of the problem.
Improve
Develop and implement the solution.
Control
Measure the improvements and ensure that they continue.
While these may appear to be similar to a traditional SDLC, there are some important differences. The following example illustrates the use of the DMAIC model and Six Sigma processes in IT systems analysis.
THE PROBLEM
It was the beginning of March and the CIO of the XYZ Corporation was returning to his office after lunch when the Vice-President of Marketing happened to see him in the hallway and began berating him. “That payroll/HR system you put in a couple years ago stinks. When I moved, I changed banks. Although my assistant filled out all the paperwork, it has been months, and I still do not have my pay deposited in the right account or my deposit slips sent to the new address. What a mess!” The VP
of Marketing was clearly angry as she continued, “All I hear is that there are backlogs in keypunch and some quality problems. This can’
t continue! Why don’
t you
get one of those fancy imaging systems that I read about a while ago and eliminate all that keypunch effort? I’
ll bet that would reduce costs and improve quality.”
The CIO nodded at the irate executive, “
This sounds like an ideal process
improvement project. I’
ll charter a team. Will you serve as the executive sponsor?”
And so the project began.
The CIO had taken the first critical step to the project’
s success: obtaining a sponsor.
Whether called an executive sponsor or a champion, each project needs someone at a high enough level in the organization to obtain appropriate funding and other resources, and to break down barriers if problems should arise. Choosing a champion like the VP of Marketing, who has a vested interest in the project’
s outcome, helps
improve its chances of success.
THE DEFINITION PHASE
The objective of the first three phases of the DMAIC model (define, measure, and analyze) is to fully understand the problem and the underlying process, as well as the customers’
requirements, before beginning to implement a solution. Although this extensive analysis effort without even a prototype system as a deliverable may seem unnecessary to organizations more used to the “you start coding; I will find out
what they want” or the “ready, fire, aim” approaches to systems development, the success of Six Sigma companies attests to the value of careful planning and fact-based decisions.
The steps typically included in the definition phase are:
1. Define the problem.
2. Form a team.
3. Develop a project charter.
4. Develop a project plan.
5. Identify customers.
6. Identify and prioritize customer requirements.
Based on his conversation with the executive, the CIO drafted the following problem statement: “We need to implement an optical scanning front end to eliminate keypunch input to the payroll/HR system. The new system will reduce costs and improve quality.” The CIO then convened a team consisting of a project leader and systems analyst from his organization, the manager of the department that had already implemented an imaging system, the marketing VP’
s assistant, and the
manager of the keypunch effort.
When the team met for the first time, it began the process of developing a project charter. The purpose of this document is to ensure that everyone working on the project shares common expectations. Charters should include the following elements:
§ Problem statement
§ Goal statement, including measurable targets
§ Target completion date
§ List of team members and the percentage of time they are expected to devote to the project
§ Resource constraints (e.g., budget)
Problem and Goal Statements
As part of this process, the team reviewed the initial problem statement and found that, rather than being a problem statement, it was a goal statement. Unfortunately, it was not even a very good goal statement because it did not meet the SMART
criteria. That is, it was not Specific, Measurable, Attainable, Relevant, and Timebound. An example of the SMART criteria, which are also used to define customer requirements, is shown in Exhibit 2.
Exhibit 2. Using SMART Guidelines for Defining Requirements When defining customer requirements, the team should ensure that they are as detailed as possible. One way to determine whether requirements are sufficiently detailed is to apply the SMART criteria.
Specific
Requirements should be specific. For example, rather than saying
“Keypunch errors must be resolved,” a specific requirement would be “Keypunch errors must be resolved to the customer’
s satisfaction
within three hours of their being reported to the help desk.”
Measurable
The performance must be quantifiable. In the example shown above,
“to the customer’
s satisfaction” could be made more measurable by
stating “to the customer’
s satisfaction as measured by an average
score of no less than 4 on a scale of 5; such measurement to be taken during follow-up telephone interviews.”
Attainable
The requirement needs to be both realistic and attainable. If it greatly exceeds industry standards, it may not be attainable.
Relevant
The requirement should have relevance to the success of the
program. For example, a requirement to respond to problems is less relevant than one to resolve them because customer satisfaction is predicated on successful resolution, not simply by answering the phone.
Timebound
When quantified, requirements should be measured during a specific time period. To expand the first example, “98 percent of all
problems reported must be resolved within three hours of their being reported to the help desk; the remaining 2 percent must be resolved within eight hours. Reports will be produced no later than the fifth day of the month, showing daily, weekly, and monthly volumes and resolution percentages for the previous calendar
month.”
Further review showed that the initial problem/goal statement presented a solution before definitio n, measurement, and analysis had been performed. Rather than succumb to the “if the only tool one has is a hammer, all problems appear to be nails” syndrome, the team resolved to propose a solution only when it had completed the analysis phase. When the team explained its logic to the marketing VP, although she had proposed the imaging system as a solution, she admitted that her desire was to have the problem fixed. If there was a better or cheaper answer, she would be happy. She confirmed that the team was empowered to find the best solution.
The revised problem statement became: “15 percent of all requests for updates to the payroll/HR system are not processed the same day that they are received. An additional 5 percent of all updates have at least one error in keying and must be resubmitted, resulting in processing delays of at least two days, rework costs of $10,000 per year, and reimbursement of bounced check fees of $5000 per year.
Customer satisfaction has dropped from 4 to 2.5 on a scale of 1 to 5.” It is important to note that this statement quantifies the problem and its consequences.
The team then drafted the goal statement, outlining what it planned to accomplish.
“Ensure that 99 percent of all updates to the payroll/HR system are processed the
same day they are received, with an error rate not to exceed 2 percent; and improve customer satisfaction to 4 by the end of the calendar year.” Although the marketing VP wanted 100 percent completion and zero defects, and asked that the project be completed by the end of the second quarter, the team applied the “attainability”
criterion when it wrote its goals and refused to doom its project to failure by having unrealistic expectations.
By making both the problem and the goal statements extremely specific, the team and anyone reviewing the project will have a clear understanding of why the team was chartered and what it intended to accomplish. Clarity and common goals are key tenets of Six Sigma.