DMAIC: Define and Measure

Introduction and Context

DMAIC—Define, Measure, Analyze, Improve and Control—is the principal structured method used in Six Sigma for improving an existing process. This chapter focuses on the first two phases: Define and Measure. These phases determine whether a project is correctly selected, clearly bounded, aligned with customer requirements and supported by trustworthy evidence.

A weak Define phase produces vague objectives, unclear ownership and uncontrolled scope. A weak Measure phase produces unreliable baselines and encourages teams to improve symptoms rather than causes. Conversely, a disciplined Define–Measure sequence converts a business concern into a measurable improvement opportunity.

DMAIC is appropriate when a process already exists but its performance is inadequate, inconsistent or costly. It is less suitable for designing an entirely new product or process; Design for Six Sigma methods are generally more appropriate in that situation.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Construct a project charter, business case, problem statement and goal statement.
2. Identify stakeholders and plan their engagement.
3. Translate the voice of the customer (VOC) into critical-to-quality (CTQ) requirements.
4. Build and interpret a SIPOC model.
5. Establish operational definitions, data-collection plans and validated baseline measures.
6. Define project boundaries, assumptions, risks and governance requirements.
7. Evaluate the quality and limitations of measurement evidence.

1. The Define Phase: Turning Concern into a Project

The Define phase answers five questions:

• What business or customer problem exists?
• Why does it matter now?
• Who is affected and who owns the process?
• What outcome is required?
• Where does the project begin and end?

Define is not merely administrative documentation. It is a process of disciplined inquiry. The team must distinguish a problem from a proposed solution. “Install automated inspection” is a solution; “12% of orders require rework because inspection results are inconsistent” is a problem statement.

1.1 Project Charter

A project charter is the governing agreement between the improvement team and its sponsor. A useful charter normally contains:

A charter should be concise enough to guide action but sufficiently precise to prevent conflicting interpretations. It is a living document: changes should be approved through agreed governance rather than made informally.

1.2 Business Case

The business case connects process performance with organizational consequences. It may include:

• direct cost of defects, scrap, rework, overtime or claims;
• lost capacity and delayed delivery;
• customer dissatisfaction and retention risk;
• safety, legal or regulatory exposure;
• strategic importance, such as a major contract or product launch.

A business case should avoid unsupported claims. If the financial effect is uncertain, it should be labelled as an estimate and its assumptions recorded. Benefits should be separated into hard savings—such as avoided expenditure—and soft or capacity benefits, such as time released for other work.

A simple annual cost-of-poor-quality estimate is:

Here, each term is an annual monetary cost in the organization’s currency. The expression is applicable when the cost categories are defined consistently and overlapping costs are excluded. It is not a universal accounting identity; organizations may classify prevention, appraisal and failure costs differently.

1.3 Problem and Goal Statements

A high-quality problem statement is:

• specific rather than general;
• evidence-based rather than anecdotal;
• neutral about causes and solutions;
• bounded by process, location, product or time;
• meaningful to customers or the organization.

A useful structure is:

Between [date or period], [process or population] experienced [measured performance], compared with [requirement or expectation], resulting in [impact].

A goal statement describes the desired future condition and deadline without prescribing the solution:

Improve [metric] from [baseline] to [target] by [date] within [defined scope].

A goal such as “make the process better” is not measurable. A goal such as “reduce order-entry defects from 8.0% to 3.0% by 30 September within the regional service centre” is testable, although the team must still confirm that the target is realistic and operationally defined.

1.4 Scope and Boundaries

Scope controls the project’s size. The team should explicitly identify:

• start point: the event that initiates the process;
• end point: the event that completes the process;
• products, services, locations and shifts included;
• customer segments and transaction types included;
• exclusions and interfaces with other projects;
• the period represented by the baseline.

Overly broad scope creates delay and weak accountability. Overly narrow scope may optimize one activity while worsening total customer performance. Scope decisions should therefore consider the end-to-end value stream and the authority of the team.

2. Stakeholder Analysis and Governance

Stakeholders are individuals or groups who affect the project, are affected by it, provide essential knowledge or control resources. Typical stakeholders include customers, operators, supervisors, process owners, finance, information technology, quality, regulatory bodies and suppliers.

A stakeholder register may include the stakeholder, interests, influence, current attitude, information needs, engagement method and owner. A power–interest matrix is a practical prioritization device:

Stakeholder analysis is not manipulation. It is a means of ensuring that affected people are heard and that legitimate concerns—especially safety, privacy, workload and fairness—are not overlooked. Front-line employees often possess essential process knowledge and should not be treated merely as recipients of change.

Common governance roles include:

• Sponsor: authorizes the project, removes barriers and approves major changes.
• Process owner: remains accountable for process performance and sustainability.
• Black Belt or project leader: facilitates the DMAIC method and evidence-based decisions.
• Subject-matter experts: provide technical and operational knowledge.
• Data owner or analyst: confirms data access, definitions and integrity.

3. Voice of the Customer and CTQ Translation

The voice of the customer (VOC) is information about customer needs, expectations, experiences and dissatisfaction. Sources include interviews, complaints, surveys, service records, observation, warranty data, market research and regulatory requirements. VOC should be collected from relevant customer segments rather than from the loudest individual only.

Customers commonly express needs in ambiguous language: “delivery should be fast,” “the report must be accurate,” or “the application should be easy to use.” Six Sigma converts these statements into measurable CTQs.

A CTQ tree normally moves through three levels:

1. Need: broad customer expectation.
2. Driver: characteristic that influences satisfaction.
3. Requirement or specification: measurable acceptance condition.

Example:

A CTQ should identify the measure, unit, direction of desirability, population and acceptance criterion. “Fast response” is incomplete; “90% of telephone calls answered within 30 seconds during staffed hours” is operationally useful.

The team should distinguish customer specifications from process metrics. A customer specification states what is acceptable to the customer. A process metric may measure an internal condition that predicts or explains customer performance. Both are useful, but they should not be confused.

4. SIPOC: A High-Level Process Model

SIPOC stands for Suppliers, Inputs, Process, Outputs and Customers. It provides a high-level view before detailed process mapping. It is especially valuable when team members hold different assumptions about where the process begins or ends.

A SIPOC should be developed collaboratively and validated with the process owner and representatives who perform the work. It is not intended to show every decision, delay or exception. Detailed flowcharts, value-stream maps or service blueprints may follow when required.

The SIPOC supports boundary definition. If the project concerns fulfilment accuracy, the team must decide whether order capture, supplier replenishment and transport are inside the project or merely upstream and downstream interfaces.

5. The Measure Phase: Establishing a Reliable Baseline

The Measure phase determines how the process currently performs. It answers:

• What exactly is being measured?
• From which population and time period?
• By what method and instrument?
• Are data complete, accurate and representative?
• What is the baseline level of performance and variation?

The baseline is a reference point against which improvement is judged. It must be established before changes are introduced, or the team may attribute natural fluctuation to the project.

5.1 Operational Definitions

An operational definition specifies exactly what a measure means and how it will be observed. It should include:

• the unit of analysis;
• inclusion and exclusion rules;
• numerator and denominator, where applicable;
• timing rules, such as start and stop events;
• treatment of duplicates, cancellations and missing values;
• responsible data collector and recording system.

For example, “late delivery” might mean: an order delivered after 23:59 on the confirmed delivery date, excluding customer-requested postponements and orders cancelled before dispatch. Without such rules, two analysts may report different performance from the same transactions.

5.2 Common Baseline Metrics

For a count of defective units, the observed defect proportion is:

where d is the number of defective units and n is the number of units inspected. The percentage defective is 100p%. This metric assumes each unit is classified consistently as defective or non-defective.

A defect is a failure to meet a requirement. A unit may contain more than one defect, so “defect rate” and “defective-unit rate” are not interchangeable. If D defects are found across N units, the defects per unit are:

For opportunities-based reporting, defects per million opportunities are:

Here, O is the number of defined defect opportunities per unit. DPMO is meaningful only when the opportunity definition is stable and defensible. It should not be used to create artificial precision or to compare processes with fundamentally different opportunity definitions without careful qualification.

For a continuous measure, the arithmetic mean is:

where x_i is observation i, n is the number of observations and x̄ has the same unit as the observations. The mean is sensitive to extreme values, so the median, range, standard deviation and graphical displays may also be necessary.

For a sample standard deviation, commonly used to describe dispersion, one estimator is:

The denominator n−1 is used when estimating population variation from a sample under standard statistical assumptions. The observations should be appropriately sampled and reasonably independent for ordinary interpretation. Standard deviation is not automatically a measure of process stability; time order and control-chart analysis are also important.

5.3 Worked Baseline Example

An order-processing team reviews 2,400 orders. It identifies 96 orders with at least one confirmed data-entry defect. The defective-order proportion is:

Therefore, the baseline defective-order rate is 4.0%. If the team defines three defect opportunities per order and finds 120 total defects, then:

The two figures answer different questions: 4.0% concerns orders with one or more defects, whereas 16,667 DPMO concerns all recorded defects relative to defined opportunities. The project charter must state which metric is primary.

5.4 Sampling and Representativeness

A baseline should represent normal operating conditions. Sampling must consider time, product mix, customer segment, shift, location, operator group and workload. A convenient sample collected only on a quiet weekday may be biased.

A simple random sample gives each eligible unit a known selection chance. A systematic sample selects every kth unit after a suitable starting point. Stratified sampling deliberately samples important subgroups, such as shifts or product families, and is useful when performance may differ among them.

The sample size depends on the decision, expected variation, required precision, risk and resources. A larger sample does not correct biased definitions or poor measurement. Statistical confidence should not be claimed unless the sampling and analysis support it.

5.5 Measurement-System Validation

Before interpreting process variation, the team should ask whether variation originates in the process or in the measurement system. For continuous data, this may involve calibration, resolution, repeatability and reproducibility studies. For attribute data, assess agreement among inspectors and consistency with a reference standard.

Important checks include:

• Is the instrument calibrated and suitable for the tolerance?
• Can the method detect practically important differences?
• Do different observers classify the same case similarly?
• Are timestamps generated consistently?
• Are database fields complete and protected from inappropriate alteration?

If measurement reliability is poor, the correct response is to improve the measurement system before drawing strong conclusions about the process.

6. Data-Collection Plan and Process Stability

A data-collection plan records the operational definition, metric, source, sampling method, frequency, owner, storage location and validation checks. It should also state how missing, anomalous or duplicate records will be handled. Data cleaning rules must be agreed before examining results where possible, because post hoc exclusions can create bias.

Plotting data in time order is essential. A single average can hide trends, shifts, cycles and special causes. Run charts and control charts help distinguish routine common-cause variation from unusual special-cause signals. Control limits are calculated from process data under an appropriate charting method; they are not the same as customer specification limits.

A process may be:

• stable but incapable: predictable variation is consistently outside customer requirements;
• unstable: special causes are present, so the average and variation are not reliable descriptions;
• apparently capable: performance meets requirements during the period observed, but the conclusion may be weak if data are biased or the measurement system is inadequate.

Capability indices such as C_p and C_pk may be introduced after stability and distributional assumptions are considered. They should not be calculated mechanically for an unstable or unsuitable process. The Define–Measure phases should establish whether such analysis is justified; detailed capability analysis is often developed in the Analyze phase.

7. Integrated Application: Illustrative Case

Background

A regional healthcare laboratory has received increasing complaints that routine test reports are not available by the promised time. The laboratory serves outpatient clinics and reports are required for treatment planning. The sponsor requests a DMAIC project.

Problem and Business Case

A preliminary review suggests that 18% of routine reports in the previous quarter were released after the promised time. Delays generate calls from clinics, interrupt scheduling and create overtime. The business case includes reduced service reliability, avoidable administrative work and potential patient-care risk. The team does not assume that staffing is the cause.

Define Approach

The charter defines the process from receipt of a complete specimen and valid request to release of the verified report. It excludes emergency tests, tests referred to external laboratories and delays caused by incomplete clinical information. The goal is to reduce late routine reports from 18% to 8% or less by the end of the next two quarters, while maintaining analytical quality and regulatory compliance.

Stakeholders include laboratory scientists, accessioning staff, clinicians, patients, the laboratory manager, information-technology support and the quality officer. Clinics are high-interest customers; the laboratory manager is a high-influence sponsor or process owner depending on governance arrangements.

VOC and CTQ

Clinics state that they need “reports when promised and confidence that results are correct.” The team translates this into two CTQs:

1. At least 92% of eligible routine reports released by the confirmed promised time.
2. No reduction in compliance with analytical quality-control requirements.

This prevents the project from improving timeliness by weakening quality controls.

SIPOC and Measure Plan

The SIPOC identifies clinics and accessioning as suppliers of requests and specimens; inputs include complete patient information, specimen and test order; high-level steps include accession, preparation, analysis, verification and release; outputs are verified reports; customers are clinicians and patients.

The operational definition of late is: report release after the system-generated promised timestamp for an eligible routine test, excluding documented clinic-requested holds. The team extracts three months of transaction data and validates timestamps against a sample of source records. It stratifies results by test family, weekday, shift and location.

Baseline and Interpretation

The initial 18% figure is confirmed only after removing excluded cases and correcting duplicate records. The validated baseline is 17.4% late reports across 8,620 eligible reports. The team finds that late performance is not uniform: one test family and an evening handover period account for a disproportionate share. These observations are not yet proof of root cause; they identify questions for Analyze.

Outcome and Learning Points

The project proceeds with a clear scope, defensible CTQs and a reproducible baseline. The team avoids prematurely purchasing equipment or blaming staffing. Its most important achievement in Define and Measure is not a solution but a shared, testable description of the problem.

8. Challenges, Ethics and Contemporary Practice

Common Failure Modes

1. Solution-first projects: a preferred technology is selected before the problem is understood.
2. Metric ambiguity: different teams use “defect,” “late” or “complete” differently.
3. Scope expansion: every related concern is added to the charter.
4. Convenience sampling: data are collected where access is easiest rather than where variation occurs.
5. Metric gaming: staff alter classifications to improve reported performance.
6. Ignoring qualitative evidence: numerical records are accepted despite known process changes or missing context.
7. Confusing correlation with cause: subgroup differences are treated as proof of a root cause.

Ethical and Regulatory Considerations

Data collection must respect privacy, confidentiality, informed organizational authorization and applicable data-protection law. Healthcare, financial, employment and customer data may require enhanced controls. Access should be limited to legitimate purposes, and reports should avoid unnecessary personal identifiers.

Improvement targets must not encourage unsafe work, conceal defects, discriminate against difficult customers or transfer burden to vulnerable groups. Regulatory requirements are constraints, not optional improvement targets. Any change affecting safety, clinical decisions, financial reporting or legal compliance requires appropriate review.

Digital Systems and AI

Enterprise systems, process mining and automated dashboards can accelerate SIPOC discovery and baseline measurement by using event logs. However, event logs may omit manual work, contain inconsistent timestamps or reflect system design rather than the real process. AI can assist with classifying complaints or identifying patterns, but outputs require validation, bias assessment, access control and human accountability. An algorithmic prediction is not automatically a CTQ, a causal explanation or a valid baseline.

Best-Practice Checklist

Before leaving Define and Measure, confirm that:

• the sponsor and process owner are identified;
• the problem is evidence-based and solution-neutral;
• the goal contains a metric, target, scope and deadline;
• customer needs have been translated into measurable CTQs;
• the SIPOC has been validated;
• scope boundaries and exclusions are explicit;
• operational definitions are documented;
• data sources and sampling are representative;
• the measurement system is fit for purpose;
• the baseline is reproducible and time-bounded;
• privacy, safety, regulatory and workforce impacts are addressed;
• the team is ready to investigate causes rather than assume them.

Chapter Summary

Define and Measure establish the intellectual and evidential foundation of DMAIC. Define converts a business or customer concern into a governed project through the business case, charter, problem statement, goal statement, stakeholder analysis, VOC-to-CTQ translation, SIPOC and scope boundaries. Measure establishes what the process currently does through operational definitions, sampling, data-collection plans, validated measurement systems and baseline metrics.

The distinction between defects, defective units, DPU and DPMO is essential. Numerical results are meaningful only when definitions, denominators, opportunities, units and sampling conditions are clear. Stability, representativeness and measurement reliability must be considered before strong conclusions are drawn. Ethical governance requires that improvement objectives protect customers, employees, privacy, safety and regulatory compliance. A disciplined Define–Measure sequence prevents premature solutions and prepares the project for evidence-based analysis.

Key Terms

Baseline: A validated description of current process performance.

Business case: Evidence-based explanation of why a project matters.

CTQ: Critical-to-quality characteristic derived from a customer or regulatory requirement.

Defect: A failure to meet a specified requirement.

Defective unit: A unit containing one or more defects.

DPMO: Defects per million defined opportunities.

DPU: Defects per unit.

Goal statement: A measurable description of desired future performance.

Operational definition: A precise rule for measuring or classifying a characteristic.

Process owner: Person accountable for ongoing process performance.

Problem statement: Evidence-based description of an adverse current condition.

Project charter: Agreement defining project purpose, authority, scope and governance.

SIPOC: High-level model of Suppliers, Inputs, Process, Outputs and Customers.

Scope: Explicit inclusion and exclusion boundaries of a project.

Special cause: An unusual source of process variation.

Stakeholder: Person or group affected by, influencing or contributing to a project.

VOC: Voice of the customer.

Common-cause variation: Routine variation generated by the process system.

Review Questions

Short Answer Questions

1. What is the purpose of a Six Sigma project charter?
2. Distinguish a defect from a defective unit.
3. What information should an operational definition contain?
4. What are the five elements of SIPOC?
5. Why should a measurement system be assessed before interpreting process variation?

Long Answer Questions

1. Explain how a business case, problem statement and goal statement should work together in a DMAIC project.
2. Describe a systematic method for translating VOC into CTQs, using an example.
3. Explain how stakeholder analysis influences project governance and implementation.
4. Compare DPU, defective-unit rate and DPMO, including the conditions under which each is useful.
5. Discuss why sampling, time order and measurement-system validation are necessary for a credible baseline.

Analytical / Application Questions

1. A service centre reports that 240 of 3,000 cases were defective. Each case has four defined opportunities, and 360 total defects were recorded. Calculate the defective-case rate and DPMO, then explain why the two results differ.
2. Develop a project charter outline for a manufacturing process with excessive rework. Include the business case, problem statement, goal, scope, stakeholders and at least two CTQs.
3. A team finds that late deliveries are highest on one shift, but timestamps are missing for 20% of that shift’s orders. Evaluate whether the team can conclude that the shift is the root cause and propose a Measure-phase response.

Multiple Choice Questions with Answers

Question 1

Which statement is the best example of a problem statement?

A. Install an automated inspection system.

B. Improve quality immediately.

C. During the last quarter, 12% of orders required rework, exceeding the 5% internal requirement and delaying shipment.

D. Train all employees in Six Sigma.

Correct Answer: C. During the last quarter, 12% of orders required rework, exceeding the 5% internal requirement and delaying shipment.

Question 2

What is the primary purpose of a SIPOC model?

A. To identify the statistical distribution of every process measure.

B. To provide a high-level view of suppliers, inputs, process, outputs and customers.

C. To calculate the financial return of a project.

D. To replace all detailed process maps.

Correct Answer: B. To provide a high-level view of suppliers, inputs, process, outputs and customers.

Question 3

A process inspects 2,000 units and finds 50 defective units. What is the defective-unit rate?

A. 0.25%

B. 2.5%

C. 4.0%

D. 25%

Correct Answer: B. 2.5%

Question 4

Which item is essential in an operational definition?

A. The preferred improvement technology

B. The project team’s personal opinions

C. Clear inclusion and exclusion rules for the measure

D. A guaranteed explanation of the root cause

Correct Answer: C. Clear inclusion and exclusion rules for the measure

Question 5

A process records 80 defects in 1,000 units, with five defined opportunities per unit. What is the DPMO?

A. 160

B. 800

C. 16,000

D. 80,000

Correct Answer: C. 16,000

Question 6

Which stakeholder normally has accountability for ongoing process performance?

A. Process owner

B. External auditor only

C. Random data collector

D. Customer survey respondent

Correct Answer: A. Process owner

Question 7

Why should a project goal normally avoid prescribing a solution?

A. Solutions are never required in improvement projects.

B. Avoiding a prescribed solution allows causes and alternatives to be evaluated objectively.

C. Goals cannot contain numerical targets.

D. Sponsors are not involved in solution decisions.

Correct Answer: B. Avoiding a prescribed solution allows causes and alternatives to be evaluated objectively.

Question 8

Which condition most threatens the validity of a baseline?

A. A documented sampling plan

B. A calibrated measurement instrument

C. A convenience sample collected only during unusually low demand

D. A clearly defined denominator

Correct Answer: C. A convenience sample collected only during unusually low demand

Question 9

What does VOC-to-CTQ translation accomplish?

A. It converts broad customer expectations into measurable requirements.

B. It removes customers from the improvement process.

C. It proves the root cause of a defect.

D. It calculates process capability automatically.

Correct Answer: A. It converts broad customer expectations into measurable requirements.

Question 10

Why must DPMO opportunity definitions be stable?

A. To ensure the metric is comparable and not artificially manipulated by changing the denominator.

B. Because every process has exactly one opportunity.

C. Because DPMO measures only customer satisfaction.

D. To eliminate the need for operational definitions.

Correct Answer: A. To ensure the metric is comparable and not artificially manipulated by changing the denominator.