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.


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."


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."


The requirement needs to be both realistic and attainable. If it greatly exceeds industry standards, it may not be attainable.


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.


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 definition, 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.

Developing the project plan, which is the next step in the definition phase, is frequently the easiest for IT staff because Six Sigma plans are no different from the project plans that IT professionals are used to creating. Like all project plans, the one the team developed included milestones, deliverables, and dependencies. To provide a clear linkage back to the process model, the team used the five phases of DMAIC as summary tasks, and broke down individual steps within them. This use of shared terminology helped non-IT staff understand the project plan.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment