The Six Sigma Handbook, Third Edition

1. 1Build complaint capture before anything else. Give unhappy customers every route to reach you: toll-free hotline, email, comment cards. Up to 96% of unhappy customers never tell the company, so each route you add reduces silent defection.
2. 2Make seeking complaints an employee duty. Seeking complaints runs against human nature, so create a system that motivates staff to actively look for customer complaints, ideas and suggestions (to 'feel their pain'), not just receive them.
3. 3Log every complaint and suggestion in one shared database that sales, technical support and development can all see. Enter each item as an Improvement Opportunity (IO) and circulate it up to the vice-president level so every internal stakeholder sees it immediately.
4. 4Triage on entry. Investigate and schedule for deployment at once any high-priority issue: an error that significantly impacts customers, or a potential significant sale tied to a critical customer need.
5. 5Resolve each complaint to the customer's satisfaction and treat it as a moment of truth. Resolution drives repurchase intent: Fig. 2.2 shows the share planning to repurchase depends heavily on whether the complaint was handled to satisfaction (completely satisfied, satisfied, not resolved).
6. 6Hold the back-and-forth conversations needed to understand the customer's real need, sometimes at a senior level in your organization. Use Solution Selling logic: identify the customer's pain (critical issue, challenge, source of dissatisfaction) and position your product or service as the solution to it.
7. 7Run trend analysis on the logged issues, using statistical process control tools on issue counts and resolution times, so recurring causes become improvement projects.
8. 8Back the census data with statistically valid sample surveys. Complaint and suggestion systems suffer selection bias and are not statistically valid, but they supply high-face-validity anecdotes and improvement ideas. Use those responses to write survey items and focus-group questions.

A software company has run a Quality Management System database for 15 years. Sales and technical support share one database holding every suggestion or complaint a customer voices. Each entry becomes an Improvement Opportunity (IO) and circulates through technical support, sales and development up to the vice-president level, giving all internal stakeholders immediate visibility. The database is integrated with statistical process control tools that trend issues and resolution times. When an IO is a high-priority issue, such as an error that significantly impacts customers or a potential significant sale based on a critical need, it is immediately investigated and scheduled for deployment. This requires several discussions with the customer, sometimes at a fairly high organizational level, which costs resources and time. The company accepts that cost because it serves the long-term vision of building relationships with its customer base. A relatively flat structure gives customers access to nearly all aspects of the organization.

• If a complaint arrives, then treat it as both a retention risk and a loyalty opportunity: resolve it to the customer's satisfaction, because repurchase intent depends on how it was handled.
• If an issue significantly impacts customers or signals a significant sale tied to a critical need, then investigate and schedule deployment immediately rather than queuing it.
• If you want statistical conclusions about customer attitudes, then use sample surveys; use complaint and suggestion systems for individual recovery and improvement ideas, since selection bias makes them statistically invalid.
• If complaint volume looks low, then assume under-reporting rather than satisfaction (up to 96% never tell you) and add contact channels and employee incentives to seek feedback.
• If resolving a need takes substantial time and senior involvement, then accept the cost when the aim is long-term relationship building.

• Passively waiting for complaints. The tell: a low complaint count read as good news, while up to 96% of unhappy customers stay silent.
• Collecting feedback in silos. The tell: support knows an issue but sales and development learn of it late, because items are not circulated to all stakeholders up to VP level.
• Closing complaints without confirming satisfaction. The tell: tickets marked closed while customers report problems 'not resolved', which Fig. 2.2 links to the lowest repurchase intent.
• Treating complaint data as statistically valid. The tell: percentages from the complaint log are quoted as customer-base attitudes, ignoring selection bias.
• Logging issues without trend analysis or prioritization. The tell: no resolution-time data, and high-impact issues wait in line with minor ones.

• ▸IO ID and date entered: unique reference and the date the complaint or suggestion was logged.
• ▸Channel received: hotline, email, comment card, employee-sought, or sales/support conversation.
• ▸Customer pain statement: the customer's critical issue, challenge or source of dissatisfaction, in their words.
• ▸Priority (high/normal): mark high if it significantly impacts customers or involves a significant sale tied to a critical need.
• ▸Circulated to: functions notified (support, sales, development, VP) and date.
• ▸Customer discussions held: dates and level of contacts needed to understand the need.
• ▸Resolution and date: action taken and time elapsed since entry.
• ▸Customer satisfaction with resolution: completely satisfied / satisfied / not resolved.
• ▸Trend category and survey follow-up: recurring issue type for SPC trending, and any survey item or focus-group question it suggests.

1. 1Write the profit hypothesis into the charter before the project starts. The DMAIC task template puts 'Estimate savings' (Black Belt) and 'Identify sponsor' ahead of 'Draft Project Charter' (Black Belt, sponsor). The sponsor reviews the project weekly, so the savings estimate is something the sponsor can audit.
2. 2Tie the project to a business performance objective with a measurable financial result. Six Sigma projects exist to achieve objectives 'linked to measurable financial results.' If you cannot name the objective the project serves, do not charter it.
3. 3Baseline in defect terms, then convert to money. Record DPMO (or yield) for the process. For a multi-step process, multiply the step yields, because overall yield is the product of the step yields and is always below the worst step. Price each lost unit (scrap, rework, lost claim, wrong invoice) using your own cost data.
4. 4Split the benefit into two ledgers. Cost ledger: cost to manufacture, cost of delivery, defects and rework. Revenue ledger: capacity and productivity gains, reduced time to market, market share held or gained. Enhanced profitability needs both, so do not report only one.
5. 5Use the customer's requirements to find the revenue side. Build the QFD requirement matrix (customer requirements as rows, product or service features as columns). Add the column-to-column correlations to make it a house of quality. Build it carefully, since it becomes the basis of the entire QFD process. Then deploy the high-importance requirements into the improvement targets.
6. 6Set the improvement trajectory and check it against the plan. The typical goal is a 10× reduction in DPMO every two years, for example 3.0 sigma (about 67,000 DPMO) to about 4.0 sigma (about 6,700 DPMO). From 3 sigma, Six Sigma performance arrives in about five years, or about seven from program initiation. Results should begin to appear within a year. Project the financial benefit on that curve, not on a single project.
7. 7Protect the result structurally. Deployment must be top-down, with top management actively leading it. Centralized Black Belt reporting is the experience of most successful enterprises. Decentralized Black Belts get pulled back into routine work and firefighting, and the savings stall.
8. 8Report both horizons. Track bottom-line results, and also long-term profitability, market share, and total productivity. The customer-driven organization measures all of these; the traditional one watches only short-term bottom-line financials and quick return on investment.

The source's own yield arithmetic shows how profit hides in a process. Take a two-step process where step 1 yields 80% and step 2 yields 90%. Overall yield is 0.8 × 0.9 = 72%, so 28% of units are defective or reworked, and the overall figure is below even the weakest step. Raising step 1 from 80% to 90% (the arithmetic is mine, the method is the source's) gives 0.9 × 0.9 = 81%. The cost ledger improves because fewer units are lost, and the revenue ledger improves because the same line ships more good units. The source scales the point: a 10-step process with 99.73% yield per step (three sigma) still ends with 26,674 defects per million. The source states no dollar figures for this example, so you supply your own cost per defective unit and margin per extra good unit. Multiply them by the volume to get the net-income effect, then record it as the estimated savings in the charter.

• If a proposed project has no estimated savings and no named sponsor, then do not charter it. Estimating savings is a charter-stage task.
• If the process has several steps, then compute rolled (multiplied) yield, not the average. Target the lowest-yield step first, because it caps the whole chain.
• If the benefit case rests only on cost savings, then add a revenue-side check covering capacity, time to market, and customer requirements from the house of quality. Profitability has two drivers.
• If Black Belts report to local managers and projects keep slipping, then move toward centralized reporting. The cause is people being pulled into routine work and firefighting.
• If the dashboard shows only quick ROI and quarterly bottom line, then add long-term profitability and market share. Short-term-only measurement is the traditional pattern the source contrasts with the customer-driven one.

• Claiming savings no one audits. The tell: savings appear in the charter but the sponsor's weekly review never revisits them.
• Counting only the cost ledger. The tell: the report shows scrap and rework reductions but nothing on capacity, time to market, or share.
• Judging a step in isolation. The tell: a step reaches an impressive yield while end-to-end yield barely moves, because yields multiply.
• Running isolated departmental efforts. The tell: results depend on a few 'local heroes' and fade when they leave. The source compares this to flower gardens in a desert.
• Expecting a full payoff too early. The tell: leadership drops the program at year one, although the plan puts Six Sigma-level performance about five years out from a 3-sigma start. Results do show within a year, so judge early progress against the curve, not against the end state.

• ▸Business objective served: name the performance objective and its measurable financial result.
• ▸Sponsor and review cadence: name the sponsor and confirm weekly review.
• ▸Baseline defect rate: record DPMO or yield for the process, with step-by-step yields if multi-step.
• ▸Rolled yield: multiply the step yields; mark the lowest-yield step.
• ▸Cost ledger: list defect, rework, cost-to-manufacture, and cost-of-delivery items, each priced with your own data.
• ▸Revenue ledger: list capacity, productivity, time-to-market, and market-share effects, each tied to a customer requirement from the house of quality.
• ▸Target and timeline: state the target DPMO and date (10× per two years as the reference pace).
• ▸Estimated net-income effect: sum both ledgers and state the basis for each figure.
• ▸Long-term measures: list profitability, market share, and total productivity indicators to track after close.

1. 1Write the leadership vision for Six Sigma success and communicate it clearly. The source names this as leadership's primary role, so treat it as the first deliverable, not a kickoff speech. Test it by asking whether a manager two levels down can restate it.
2. 2Create full- and part-time change agent positions and back them with a supporting infrastructure. The source says the infrastructure integrates change into the routine. The passages name Champions, Master Black Belts, Black Belts and Green Belts but do not fully specify their duties, so write each role's duties, time allocation and reporting line yourself and record them.
3. 3Build an enterprise-wide tracking system for Six Sigma costs and benefits that can 'slice and dice' the data many ways. Its test is that an executive can say at any moment whether Six Sigma is pulling its weight. TQM programs lacked this, lost interest and were shelved when times got tough.
4. 4Cascade strategy through the Strategy Deployment Matrix: strategy to differentiators, differentiators to operations plans, operations plans to Six Sigma projects. Projects are where top-down goals meet bottom-up problems and opportunities.
5. 5Make the linkage visible. Each project names the enterprise objective it affects. Aim for a team member who can answer 'which objective does this move?' without notes, and a senior leader who can measure Six Sigma's impact in clear, meaningful terms.
6. 6Sequence the change work in the source's order: change thinking, then norms, then systems and processes. Sustained process change does not hold until individual behavior and organizational norms shift. The target norm is data-driven decision making that delivers maximum value to key stakeholders.
7. 7Make 'How do you know?' a standing question in reviews. Ask for the data behind claims, such as customer-importance evidence and a long run chart, and use statistical methods to separate signal from noise so people stop tampering with the process.
8. 8Set a recurring review in which change agents report progress against goals, so they act as the 'conscience' of leadership. Day-to-day urgency otherwise lets the transformation slip.

The source gives a review exchange that shows the norm in action. An employee, Joan, presents a report on on-time deliveries. The leader answers, 'Nice report... but show me why you think this is important to the customer. If it is, I want to see a chart covering the last 52 w[eeks].' The reply does three things. It forces the metric to connect to a customer requirement, which is the strategy linkage. It demands a time series rather than a snapshot, which is the signal-versus-noise discipline. It makes 'How do you know?' a routine question, which is the norm shift. Repeated across reviews, this is how the source says an organization approaches 'critical mass', where seat-of-the-pants management stops fitting the culture. The contrast case is the TQM programs of the past, where nobody could point to specific bottom-line benefits and the programs faded.

• If a project cannot name the enterprise objective it affects, then do not charter it. The source's standard is that project members can state that linkage.
• If leaders are asking whether Six Sigma is paying off and nobody can answer quickly, then fix the tracking system before adding more projects.
• If people are told to use new tools but decisions are still made by opinion, then work on thinking and norms first. Process changes will not be sustained until behavior and norms move.
• If progress against deployment goals slips and nobody raises it, then have change agents challenge leadership directly. Operations urgency will otherwise crowd out the transformation.
• If a metric or claim appears in a review, then ask 'How do you know?' and ask for the customer link and a long enough trend to separate signal from noise.

• Treating deployment as training only. The tell is that Belts are certified but no full- or part-time change agent positions or supporting infrastructure exist, and work reverts to business as usual.
• No measured payback. The tell is that nobody can state Six Sigma's bottom-line benefit, which is the pattern that led TQM programs to be shelved when times got tough.
• Projects chosen only from the bottom up, as local annoyances. The tell is that team members cannot say which enterprise objective their project affects, and leaders cannot tie results to strategy.
• Leadership goes quiet after launch. The tell is a vision that is not communicated consistently and goals that are missed without anyone raising them, because current problems feel more urgent than a future goal.
• Changing processes before thinking and norms. The tell is initial gains that decay while decisions still rest on opinion and unexamined reports.

• ▸Leadership vision statement: write it in one or two sentences and name who communicates it, how and how often.
• ▸Change agent roles: list Champion, Master Black Belt, Black Belt and Green Belt positions, each with full- or part-time status, duties and reporting line.
• ▸Supporting infrastructure: list the systems, time allocations and budget that make the roles part of routine work.
• ▸Tracking system: state what costs and benefits are tracked, how the data can be sliced and who can see it.
• ▸Strategy cascade: record the strategy, differentiator, operations plan and project chain for each active project.
• ▸Project-to-objective link: for each project, write the one enterprise objective it affects and the measure of impact.
• ▸Norm indicators: note where 'How do you know?' is asked and what data is required in reviews.
• ▸Progress review: give the date, the attendees and who plays the conscience role against goals.
• ▸Gaps and owners: list each gap found above with an owner and a due date.

1. 1Screen the project before opening it. Score the value of the Six Sigma approach: 9 = DMAIC essential and Black Belt/Green Belt skills required, 3 = helpful but not essential, 0 = usefulness not apparent. Run DMAIC only on 9s, and on 3s when the skill set can be applied. A 0 goes through another channel.
2. 2Define: write the goal of the improvement activity as a charter. Decompose the project (work breakdown structure, Pareto analysis). State deliverables as Critical-to-Quality, Critical-to-Schedule and Critical-to-Cost metrics. Draw a top-level process map, then assemble the team. Finish by confirming the goal ties to the organization's strategy.
3. 3Measure: define the existing system before measuring it. Build a flowchart and a SIPOC. Define each metric and its measurement scale. Record current performance in the same units as the goal, such as problems per million opportunities, so the baseline can be compared directly.
4. 4Analyze: state the gap between current performance and the desired goal, because the phase exists to find ways to eliminate that gap. Use Pareto analysis to focus on the few processes causing most problems. Look for hidden 'pain signals': workarounds such as sorting good from bad out of a large inventory mask the real defect and carry large cost.
5. 5Analyze at the process level, not the symptom level. If you can only name a symptom (schedule slips, complaints), keep asking which process produces it until you reach a process you can change.
6. 6Improve: change the system, using only the changes the Analyze phase tied to the gap. Keep the same workforce, technology and designs in view as the baseline. The Quasar case shows that process management alone can cut defects dramatically.
7. 7Control: put the new system under control so the gain holds. Track project results, validate the financial results, evaluate and recognize the team, and capture lessons learned so they can be replicated elsewhere.
8. 8Run a communication plan throughout. Provide upward and lateral channels as well as downward ones, because Six Sigma is a cultural change and silence breeds rumor and lower morale.

The source's clearest real case is the Quasar television plant, read here through the five phases. A Japanese firm took over a Motorola factory in the 1970s and soon produced sets with 1/20th as many defects. It used the same workforce, technology and designs, and it lowered costs. Define: the goal is fewer defects at lower cost. Measure: defects per set under Motorola management is the baseline. Analyze: with people, technology and designs held constant, the cause must sit in how the plant was managed, and the source concludes exactly that. Improve and Control: the new management practices cut defects to 1/20th and held there. The source does not give the specific practices, so do not invent them. Use the same scale check on your own baseline. Traditional 3-4 sigma processes produce 6,200 to 67,000 problems per million opportunities against the 3.4 standard, which is roughly 1,800 to 19,700 times worse. Your baseline tells you how large the gap is.

• If the project scores 0 on value of the Six Sigma approach, then do not open a DMAIC project. If it scores 3, run it only when Black Belt/Green Belt skills can be applied. If it scores 9, charter it.
• If the team can only name a symptom (schedule disruption, complaints) and not a process, then return to Analyze and trace the symptom to a process before proposing any fix.
• If a proposed fix keeps the defect and adds a screen, such as a large inventory to sort good from bad, then treat it as a hidden pain signal. Check what it costs and whether the underlying cause is still untouched.
• If the baseline and the goal are not in the same metric and measurement scale, then stop Measure and redefine the metric before Analyze.
• If someone proposes the Improve step before the gap is quantified, then hold Improve until Measure and Analyze give the baseline and gap.

• Treating symptoms instead of causes. The tell: the schedule is met and complaints stop, but inventory and cost balloon.
• Skipping process definition in Measure. The tell: the team argues about the data because no flowchart or SIPOC shows what is being measured.
• Running DMAIC on a project that does not need it. The tell: the value-of-approach score is 0 or 3 and the team cannot name a Black Belt/Green Belt skill the project uses.
• Weak Control, with no financial validation or lessons-learned capture. The tell: the gain fades and no other team can replicate it.
• Ignoring organizational resistance and communication. The tell: rumors, low morale, and employees who cannot state the vision or plan.

• ▸Value-of-approach score (9/3/0): enter the score and the Black Belt/Green Belt skill the project needs.
• ▸Define - goal and metrics: state the improvement goal and its CTQ, schedule and cost metrics.
• ▸Define - process map and team: attach the top-level process map and list the team members.
• ▸Measure - baseline: state the metric, its measurement scale and the current performance value.
• ▸Analyze - gap and root cause: state goal minus baseline and the process-level cause, noting any hidden pain signal found.
• ▸Improve - change made: describe the system change tied to the root cause.
• ▸Improve - result: record the new measured performance in the same metric as the baseline.
• ▸Control - hold mechanism: describe how the new system is kept under control and who tracks it.
• ▸Financial validation: record the validated financial result and who validated it.
• ▸Lessons learned: record what to replicate or avoid, and where it is stored.

1. 1Write the specification from the customer, not from the process. Trace each customer requirement to a measurable characteristic through the QFD requirement matrix or house of quality, and record its target value and limits. A limit with no customer requirement behind it makes the capability number meaningless.
2. 2Validate the measurement system before collecting capability data. The Measure-phase task list includes 'validate measurement system' (Black Belt, process operator), and GE's curriculum teaches Gage R&R ahead of process capability. If the gage adds variation, you are measuring the gage.
3. 3Define the sampling plan using rational subgroups, and choose the chart that matches the data: X-bar/R or X-bar/sigma for variables data, individuals (X) charts for single measurements, p/np/u/c charts for attributes. Collect enough data to see the process's normal behavior.
4. 4Check stability first. Plot the control chart and interpret it for special causes. The GE curriculum includes 'impact of process instability on capability analysis' for a reason: a capability figure from an unstable process describes no future state. Find and remove special causes, then re-collect.
5. 5Only after the process is stable, compare spread to tolerance. Estimate the process standard deviation and test it against total allowable spread. The traditional standard is sigma ≤ 1/6 of the spread (±3 sigma inside tolerance, 99.73% yield under normality). The Six Sigma standard is sigma ≤ 1/12 of the spread.
6. 6Check location separately from spread. Measure how many sigmas the mean sits from the NEAREST engineering requirement. The refinement of the traditional standard required at least four sigma. Six Sigma requires at least six sigma. A narrow process sitting off target fails here.
7. 7Express the result in parts per million, not percent. Report the nonconformance rate in PPM, state the distribution assumption (normality), and note the discrepancy in the literature: the official 3.4 PPM for Six Sigma versus 0.002 PPM from a normal table.
8. 8If the process falls short, improve it (DOE, with FMEA to prioritize risk), then lock the gain with a control plan and control charts. Re-run the stability check and capability estimate on post-improvement data to confirm the process is predictable at the new level.

The source gives the arithmetic for judging capability. Suppose a customer-defined characteristic has a total allowable spread of 12 units (an illustrative figure, not from the text). Under the traditional rule a process is 'capable' when sigma is at most one-sixth of that spread, here 2 units. Its natural spread, ±3 sigma, then just fills the tolerance, and under normality about 99.73% of output conforms. The Six Sigma rule requires sigma of at most one-twelfth of the spread, here 1 unit. Specification limits then sit six sigma either side of the mean. The later traditional refinement judged location as well, requiring the mean to be at least four sigma from the nearest requirement. The Six Sigma version of that test is six sigma. Measured the same way, a process that passes the old test at sigma = 2 fails the Six Sigma test by a factor of two in spread. The 99.73% yield also hides about 0.27% nonconformance, which is why Motorola moved the discussion from percent to PPM. None of this applies until the control chart shows the process is stable and the gage has been validated.

• If the control chart shows special causes (out-of-control points or patterns), then fix stability first and do not report a capability index. Instability invalidates the estimate.
• If the Gage R&R result is poor, then improve the measurement system before judging the process, because measurement variation inflates apparent process variation.
• If sigma is within one-sixth of the tolerance but the mean is closer than your required sigma distance to one limit, then center the process before reducing spread further. Location is a separate test.
• If the target is Six Sigma, then require sigma ≤ 1/12 of total allowable spread and the nearest limit at least six sigma from the mean. Passing the three-sigma test is not enough.
• If you quote a PPM figure, then state the normality assumption and whether it comes from the official 3.4 PPM convention or a normal-table value (0.002 PPM). Do not mix the two.

• Computing capability on unstable data. The tell: the control chart shows points beyond limits or non-random patterns, yet an index is still reported.
• Using limits that come from habit or engineering preference rather than the customer requirement. The tell: nobody can trace the limit to a row of the requirement matrix or a CTQ.
• Judging spread alone and ignoring where the mean sits. The tell: the process looks narrow but defects cluster near one specification limit.
• Trusting an unvalidated gage. The tell: repeated measurements of the same part disagree noticeably, and no Gage R&R was run.
• Treating 99.73% as high quality. The tell: results are reported in percent instead of PPM, so a rate that is poor by modern standards looks acceptable.

• ▸Characteristic and customer requirement: name the CTQ and the QFD row or customer need it traces to.
• ▸Target value and specification limits (LSL/USL): record the customer-defined target and limits; compute total allowable spread.
• ▸Measurement system status: record the Gage R&R result and whether it was accepted.
• ▸Data and subgroup plan: state sample size, subgroup logic, and chart type chosen.
• ▸Stability verdict: state stable or unstable, listing special causes found and removed.
• ▸Process mean and standard deviation: record the estimates from stable data only.
• ▸Spread test: compare sigma to one-sixth and one-twelfth of total allowable spread, and record pass or fail for each.
• ▸Location test: record the distance in sigmas from the mean to the nearest limit, and compare to four and six.
• ▸Expected nonconformance (PPM) and assumptions: record the PPM figure, the distribution assumed, and its source.
• ▸Action and control plan: record the improvement actions, the owner, and the control chart that will monitor the process.

1. 1Define quality as value added per unit of input. Potential quality is the known maximum value added per unit of input; actual quality is the current value added. The gap between them is waste, so name that gap as the efficiency target before touching the process.
2. 2Identify stakeholder values first, then classify every activity in the process as value-added (creates the final value the customer wants) or non-value-added. Evaluate the process on both effectiveness (delivers what the customer requires) and efficiency (effective with a minimum of resources).
3. 3Set the process boundary on the value stream, not on a functional department. Customers rarely care how the enterprise creates value internally, and a functional focus can hurt the enterprise as a whole.
4. 4Capture the customer's pain by talking to informed stakeholders. Treat each admitted pain point as a candidate improvement. Log every suggestion or complaint in one shared database so sales, support, and development see the same data.
5. 5Make issues visible at once. Circulate each logged item to every affected area up to vice-president level, and investigate and schedule high-priority items immediately (visibility is a lean concept in the passages). Budget for the back-and-forth with the customer that this requires.
6. 6Convert customer requirements into process priorities with a requirement matrix: requirements as rows, features as columns, and the correlation in each cell. Build it with an interdepartmental team so functional barriers do not distort it.
7. 7Run improvement through the QFD phases: organization (pick the process and team), descriptive (define the process from several angles, including cost), breakthrough (select improvement areas and monitor the bottleneck process), and implementation (define the new design).
8. 8Track trends and resolution times with statistical process control on the issue data. Check cycle time and cost savings, and count only the removal of costs that give customers no value. Do not count blanket cost-cutting, which also reduces value.
9. 9Before launch, diagnose buy-in resistance: unclear goals, no personal benefit, predetermined solutions, no accountability, too many priorities, insufficient resources, midstream scope changes. Resolve each, and run two-way communication, or the redesigned process will not be adopted.

A software organization in the passages kept one Quality Management System database that holds every customer suggestion or complaint, which it calls an Improvement Opportunity (IO). The database is integrated with statistical process control tools to trend issues and resolution times, and it has been refined over 15 years. When an IO is entered, it circulates to technical support, sales, and development, up to the vice-president level, so every internal stakeholder sees it immediately. High-priority IOs, meaning errors that significantly affect customers or a large potential sale tied to a critical customer need, are investigated and scheduled for deployment right away. Resolving them takes repeated discussions with the customer, sometimes at a senior level, which costs resources and time. The company accepts that cost because it builds long-term customer relationships, and its flat structure gives customers access to nearly all parts of the organization. The passages give no savings figures for this case, so treat resolution-time trend data as the efficiency evidence you would collect.

• If an activity does not contribute to the final value the customer wants, classify it as non-value-added and make it a waste-removal candidate.
• If a proposed saving reduces value or quality along with cost, reject it. Only costs that give customers no value count as waste costs.
• If an improvement item is high-priority (significant customer impact or a significant sale), investigate and schedule it immediately instead of queuing it.
• If the team is handed a solution without analyzing alternatives, expect skepticism. Reopen the analysis before rollout.
• If scope or direction changes midproject, communicate it to all stakeholder groups at once to protect buy-in.

• Optimizing a function instead of the value stream. The tell: a department's metrics improve while end-to-end delivery to the customer does not.
• Treating efficiency as cost-cutting. The tell: costs fall but customer value or quality falls with them.
• Improving the process without securing buy-in. The tell: unclear goals, rumors, no named sponsor, and resistance to the new process.
• Issues logged but not made visible. The tell: complaints sit in one area, with no cross-functional circulation and no trend or resolution-time data.
• Defining the customer inconsistently across functions. The tell: turf wars and conflicting priorities within the project.

• ▸Process and customer: name the process and the customer whose value it creates.
• ▸Customer pain or requirement: state the pain or need in the customer's terms.
• ▸Potential vs. actual value per unit of input: record the known maximum and the current level; the gap is the waste.
• ▸Activity list: list each step in sequence.
• ▸Value classification: mark each step value-added or non-value-added.
• ▸Waste candidates and owner: name the non-value-added steps to remove and one accountable owner for each.
• ▸Visibility channel: state where issues are logged and who sees them, up to vice-president level.
• ▸Metrics: record the trended issue counts and resolution times, and cycle time before and after.
• ▸Buy-in risks: tick the applicable resistance causes (unclear goals, no personal benefit, predetermined solution, insufficient resources, scope change) and the resolution for each.

1. 1Define the COPQ baseline before any improvement starts. In the Measure phase the process baseline is the quantified performance before improvement, and it is the only reference against which a COPQ reduction can be claimed. Record it as dollars of failure cost (scrap, rework, warranty claims) and as a share of revenue.
2. 2Convert the baseline to a share of revenue and place it against the source benchmarks. Companies at three or four sigma typically spend 25-40% of revenue fixing problems. Companies at Six Sigma typically spend under 5%. Treat the low end of that range as a conservative comparison, since the passages say Fig. 1.1 shows the lower end of reported results.
3. 3Pair each failure-cost line with an error-rate metric (DPMO and sigma level). Cost tracks error rate because it costs money to correct errors, and error rates fall exponentially as sigma rises. Without the pairing you cannot tell whether a cost drop came from fewer defects or from relabeling.
4. 4Validate each metric for validity and accuracy before baselining it. If the customer's key characteristic is an endpoint measurement set by internal process settings, measure the internal metric or the project deliverable instead. A cost number built on a bad measurement system produces a false baseline.
5. 5Decompose with Pareto analysis in the Define phase and charter the project on the largest failure-cost categories. Attach the target as a Critical to Cost metric, and name a Project Sponsor, stakeholders and team members so someone is accountable for the dollars.
6. 6Set the reduction target using the source pace: 10x fewer errors every two years. A 3.0-sigma process moves from about 67,000 DPMO to about 6,700 (roughly 4.0 sigma) in two years. Roughly five years of deployment takes a typical 3-sigma company to Six Sigma, and about seven years from program initiation.
7. 7Track the result on a run chart or control chart and read it as an analytic study. Do not attach a probability to future results. Use the chart to state a degree of belief that the reduction will hold, not a calculated confidence.
8. 8Report COPQ in the financial perspective of the balanced scorecard, next to the internal process metrics that cause it. Report program benefits against program costs. GE's published data show savings covered the costs in the first year.

The source gives a company at three or four sigma spending 25-40% of revenue on fixing problems, and a Six Sigma company spending under 5%. Take $100 of revenue as an illustrative base. The failure cost is $25-$40 per $100 at the starting level and under $5 per $100 at Six Sigma, so the gap is at least $20 per $100 of revenue. Now set the pace. A process at 3.0 sigma runs about 67,000 errors per million opportunities. Applying the 10x-every-two-years rule takes it to about 6,700, roughly 4.0 sigma, in two years. The typical-company reference for four sigma is about 6,210 errors per million. At that pace Six Sigma arrives about five years after deployment, or about seven years from program initiation. The scale at stake is shown by General Electric, which estimated the gap between three or four sigma and Six Sigma cost it $8-$12 billion per year. GE's published data also show savings covering Six Sigma costs within the first year. The lesson for your own case is to baseline the failure-cost percentage first, tie each cost line to a DPMO figure, and then track both down together.

• If a failure-cost figure has no paired error-rate (DPMO or sigma) metric, then do not report it as a COPQ reduction. Cost falls with error rate, so an unpaired drop may be reclassification or noise.
• If the customer's key characteristic is an endpoint measure set by internal process settings, then baseline the internal metric or the project deliverable instead, after checking validity and accuracy.
• If a project is not on the Pareto-ranked failure-cost categories, then re-scope it. Cost-cutting that also removes value is not the goal. Target waste costs, meaning those that provide no value to customers.
• If the organization-wide DPMO looks like five or Six Sigma but customers still complain, then drill into individual processes. Aggregate DPMO hides processes at poor sigma levels, and customers judge by their own experience.
• If someone asks for a confidence level on future savings, then give a degree of belief based on run or control charts, not a probability. The future cannot be predicted with a known level of confidence.

• Claiming reduction with no baseline. The tell: the starting COPQ figure appears for the first time in the results report, or was never measured before improvement began.
• Cutting costs that carry customer value and calling it COPQ reduction. The tell: cost falls while customer complaints or error rates stay flat or rise.
• Trusting an aggregate sigma level. The tell: the enterprise DPMO looks good while specific processes and customers still show high failure costs.
• Overstating certainty about future savings, such as quoting a Type I error probability for acting on a control-chart point. The tell: a probability is stated for a dynamic process, though the source calls such statements false.
• Losing scope or sponsorship midstream. The tell: no named Project Sponsor, a changed scope that was not communicated, or insufficient resources, so the buy-in behind the cost target erodes.

• ▸Process / project name: name the process and its Project Sponsor so someone owns the number.
• ▸Revenue base and period: state the revenue and time window the percentages are measured against.
• ▸Failure-cost lines (scrap, rework, warranty, other): list each category with its dollar amount for the baseline period.
• ▸Total COPQ as % of revenue: divide the sum of failure costs by revenue. Compare to the 25-40% (three to four sigma) and under-5% (Six Sigma) benchmarks.
• ▸Paired error-rate metric: record the DPMO and sigma level for the same process and period.
• ▸Metric validity check: note how validity and accuracy of the measurement were confirmed, and whether an internal metric replaced a customer endpoint.
• ▸Pareto rank of each cost line: rank categories by dollars to choose the project target.
• ▸Target and date: apply the 10x-per-two-years pace (e.g., 67,000 to about 6,700 DPMO) and set the COPQ % goal.
• ▸Tracking method and review cadence: record the run or control chart used, and report results as a degree of belief, not a probability.
• ▸Benefits versus project cost: log the savings against program cost for each period.