Defeating the defects means defeating the cost of poor quality (COPQ), as introduced in Chapter 2. Basically, COPQ is the cri- terion by which you judge all your potential projects. Projects must have defined cost savings attached to them; otherwise there’s no real point to taking them on. Sure, it might sound good and feel good to have improved something, but in Six Sigma the only mark of a successful project is the dollars you’ve saved and pushed to the bottom line. Since we know defects exist and that there’s a measurable cost attached to them, we need to filter out the activities that don’t cut costs and concentrate on finding that hidden revenue.
Scoping a Project
The scope of your project should be manageable, but not so narrow that the solution is already in front of you. If the solution is in front of you and you know it, then you should just do it and don’t waste your black belt’s time. Keeping your project focused keeps the objec- tive clear and puts all your Six Sigma resources to their best use. Bear in mind that there’s a balance.
You also need to further refine and pick projects for black belts that exemplify the Y = f(X) equation you learned about in Chapter 3. That equation asks the all-important question, “What is Y a function of?” As Y is the outcome of any given process, you can focus on the vital few factors, the X’s determining its quality. This keeps you focused on selecting projects for which you can truly get at the answer with quantifiable metrics.
Project selection should reflect the major issues confronting your business. Your leadership team also needs to know and support your project choices. Any business has three main ele- ments associated with it: sales, profits, and costs. Your projects are designed to attack and reduce or even eliminate costs.
Whether you’re working in sales, marketing, manufacturing, or other arenas, each and every one of your processes have con- nected costs. Your job is to root them out and establish a meas- urement to assess their effects.
First, you must identify and prioritize the suspected sources of issues affecting your critical-to-quality (CTQ) metrics. You then identify the “owners” of the suspected sources (which could include you!), who then become the project champions for those issues. Next, you can get into identifying the Six Sigma methods of improvement to deploy on a particular proj- ect. In essence, you make a list.
Now that you have this list, you need to ask these two essential questions:
• Has the project been undertaken before?
• If not, then will its business benefit outweigh the cost and effort required?
After you’ve asked and answered these two basic questions, you can then set a timeline boundary for your project—usually no more than six months. Is the data available to get started with the project? If not, you need to start collecting it to create a baseline.
Since in most cases, and especially for transaction-based proj- ects, there won’t be any data, you need to develop a data-collec- tion plan. But first, you must create a project problem statement.
Project Problem Statements
Creating a good project statement is one of the hardest things to do in Six Sigma. Your statement must be quantifiable and specific; otherwise, you won’t have a clue about what you’re actually going to work on. Your statement attacks the business process at its core and looks at the business metrics around it.
There are two purposes to having a problem statement:
• To focus the team on the process deficiency or the actu- al defect.
• To communicate your project’s purpose to “significant others.”
Who are these significant others? They are your company’s leaders, executive teams, or other high-level personnel to whom you have to ultimately report your findings.
Your problem statement is a boiled-down metric of your project. Through your statement, everyone understands what the problem is and what the benefit will be once your team has fixed it.
Project Objective Statement
You must also address your project’s objective. As a corollary to stating what the problem is, you need to indicate how it’s
Good vs. Bad Problem Statements
Developing a good problem statement is critical to commu- nicating and directing your project mission.
A good problem statement for a project reads something like this:
“Product returns are 5% of sales, resulting in a profit impact of $5 million and customer dissatisfaction rates in excess of 50%.”The statement is specific: it presents defined numbers illustrating the problem, and indi- cates the core cost and customer satisfaction issues.
In contrast, a poor problem statement would be:“Our product return levels are too high due to product A and will be reduced by analyzing first- and second-level Pareto charts.”Why is this problem statement poor?
First, because there are no numbers, so there’s no quantifying the scope or scale of the problem. Second, all it states is what you’re going to do, instead of precisely and accurately addressing the problem.
going to be solved. You do so by following up your problem statement with a strong objective statement that does the fol- lowing:
• It quantifies the expected performance.
• It indicates the improvement target for that perform- ance.
• It identifies the expected time frame for both the expected performance and the improvement target for that per- formance.
In your project objective statement, you state the following:
• Where you are.
• What you need to do to change the process.
• How long it will take.
• How much money you will save.
Once you’ve defined the project problem and its parame- ters, it’s time to drill down and identify the actionable items within. In what is now a familiar refrain to you, we do this through measuring and analyzing key factors of the project. At this point, we turn to Pareto charts to help us graph and quanti- fy the variables.
Good vs. Bad Objective Statements
An objective statement, like a problem statement, can be derailed by not keeping the focus on what, when, and how much you’re going to do to reach the goal.
A poor objective statement might go like this:“We will reduce ship- ping errors by implementing individual performance measures and objec- tives.”What’s wrong with this? There’s no quantification or time limita- tion on how or what is going to be accomplished.
A good objective statement, on the other hand, reads something like this:“We will reduce shipping errors from 5% to 2.5% of total shipments by this year’s end.”This is very specific: it indicates the scope, the goal, and the time it will take to complete the project and reach the objective.