8. DMAIC: Define and MeasureIntroduction and ContextDMAIC—Define, Measure, Analyze, Improve and Control—is the principal problem-solving framework associated with Six Sigma improvement. It provides a disciplined sequence for converting an imprecisely expressed organizational concern into a fact-based improvement project. This chapter focuses on the first two phases, Define and Measure. Although these phases appear at the beginning of DMAIC, they determine much of the eventual success or failure of the project. A poorly defined problem produces unfocused analysis; an unreliable measurement system produces unreliable conclusions. The Define phase establishes why the project matters, what it will address, who is affected, and how success will be judged. The Measure phase translates the problem into operational definitions, establishes the current level of performance, and determines whether the data-generation process is sufficiently dependable for analysis. Together, the phases create a common foundation for technical investigation and managerial decision-making. In Lean Six Sigma, improvement is not initiated merely because a process appears inefficient. It is initiated when a performance gap, customer requirement, strategic priority, risk, or cost condition justifies structured intervention. Define and Measure therefore connect organizational strategy with process-level evidence. Learning ObjectivesAfter studying this chapter, the learner should be able to: 1. Explain the purpose and logic of the Define and Measure phases of DMAIC. 2. Construct a business case, project charter, problem statement, goal statement, and project scope. 3. Identify stakeholders and translate the voice of the customer into critical-to-quality requirements. 4. Use CTQ trees, SIPOC diagrams, and process measures to frame an improvement opportunity. 5. Distinguish between leading and lagging measures, continuous and discrete data, and primary and secondary data. 6. Establish a credible baseline and select appropriate sampling and data-collection methods. 7. Evaluate measurement-system reliability and recognize sources of measurement error. 8. Use tollgates, governance, and professional judgment to manage DMAIC projects. The Logic of Define and MeasureDMAIC is a staged learning system rather than a rigid administrative sequence. Each phase answers a different question: - Define: What problem deserves attention, and what outcome is required?
- Measure: How is the current process performing, and can performance be measured reliably?
- Analyze: What factors explain the observed performance?
- Improve: What changes will address the verified causes?
- Control: How will the gains be sustained?
The first two questions are deliberately separated. Teams often move directly from a complaint to proposed solutions. For example, a manager may state that employees need more training because customer complaints have increased. Define and Measure require the team to investigate whether the problem is actually training, process design, information quality, staffing, or measurement bias. This discipline prevents solution-first thinking. A project should generally be considered suitable for DMAIC when a measurable performance problem exists, the process is sufficiently established to study, the causes are not already known with certainty, and improvement could produce meaningful customer or business value. DMAIC is less suitable when the organization is designing a completely new product or process; in such situations, Design for Six Sigma methods may be more appropriate. Define: Framing the Improvement OpportunityFrom Business Concern to Business CaseA business case explains why the project should be undertaken. It links the performance gap to consequences such as cost, revenue, customer experience, compliance, capacity, risk, employee effort, or strategic objectives. A strong business case does not simply state that a process is poor. It shows the significance of the gap and identifies the value of addressing it. For example, “invoice processing is inefficient” is weak because it lacks magnitude, consequence, and boundaries. A stronger formulation is: “In the regional service division, invoice approval takes longer than the contractual requirement, resulting in delayed supplier payment, avoidable escalation, and an estimated increase in administrative effort.” The second statement invites measurement and identifies organizational relevance without prematurely claiming a cause. The business case should distinguish verified facts from assumptions. Estimated financial impact should be labelled as an estimate until validated. Likewise, a customer complaint should not automatically be interpreted as evidence of a system-wide failure. Problem and Goal StatementsA problem statement describes the gap between current and expected performance. It should identify the process, location or population, time period, magnitude where known, and consequence. It should avoid blame and avoid embedding a solution or presumed cause. A useful problem statement has the following characteristics: - It is specific rather than general.
- It is observable and measurable.
- It identifies where and when the problem occurs.
- It avoids words such as “careless,” “unmotivated,” or “poor attitude.”
- It does not assume that a particular department or technology is the cause.
A goal statement describes the intended improvement in measurable terms, within a defined time frame. For example: “Reduce the median invoice approval lead time from the validated baseline to no more than two working days by the end of the third quarter, without increasing payment errors.” The goal should be challenging but credible. An arbitrary target can encourage gaming, concealment of defects, or inappropriate exclusion of difficult cases. The Project CharterThe project charter is the principal Define-phase document. It authorizes the work, aligns stakeholders, and establishes the initial boundaries of the project. A charter commonly contains: - business case;
- problem statement;
- goal statement;
- project scope and exclusions;
- high-level process description;
- expected benefits;
- project team and roles;
- sponsor, process owner, and champion;
- major milestones and tollgates;
- known constraints, assumptions, and risks;
- initial data sources.
The charter is not a contract that can never change. It is a controlled hypothesis about the project. As understanding improves, changes should be documented and approved rather than informally introduced. Scope control is especially important because teams may expand from one process step to an entire customer journey, making completion unlikely. Scope and BoundariesScope defines the operational territory of the project. A clear scope may use boundaries such as customer segment, product, geography, process start and end points, transaction type, or time period. For example, a project may begin when a complete purchase order is received and end when an approved invoice is released for payment. It may exclude supplier onboarding, disputed invoices, and international transactions. A useful scope statement balances relevance and manageability. If the scope is too narrow, the project may optimize one step while transferring problems elsewhere. If it is too broad, the team may lack authority, data, or time. The concept of the “end-to-end process” is valuable because it encourages the team to examine handoffs and downstream effects, even when the detailed project scope is limited. Stakeholder Analysis and GovernanceStakeholders include people who provide inputs, perform work, receive outputs, experience consequences, own the process, authorize resources, or may resist the change. Stakeholder analysis is not merely a communication exercise. It reveals conflicting definitions of value and identifies those whose cooperation is necessary for valid measurement and implementation. A stakeholder matrix can classify individuals according to influence and impact. High-influence stakeholders require active engagement; highly affected stakeholders require careful consultation even when they lack formal authority. The project sponsor removes organizational barriers, the process owner accepts responsibility for the process, the improvement leader facilitates the DMAIC method, and subject-matter experts contribute operational knowledge. These roles may vary by organization, but accountability should be explicit. Governance is commonly expressed through tollgates. At a Define tollgate, the sponsor evaluates whether the business case, problem, goal, scope, customer requirements, and team responsibilities are sufficiently clear. A Measure tollgate examines whether operational definitions, data plans, baseline performance, and measurement-system evidence are adequate. Tollgates are decision points, not ceremonial presentations. The project may proceed, be redirected, require additional evidence, or be stopped. Understanding the Customer and Translating RequirementsVoice of the CustomerThe voice of the customer (VOC) comprises explicit and implicit statements of customer needs, expectations, dissatisfaction, and desired outcomes. Customers may be external buyers, patients, citizens, regulators, internal departments, or colleagues receiving process outputs. VOC sources include interviews, complaints, surveys, service records, observation, social-media feedback, contract requirements, warranty information, and frontline experience. VOC data is often expressed in vague or emotional language: “The service is too slow,” “The report is confusing,” or “I need it right the first time.” The Define phase does not treat these statements as ready-made measures. It interprets them carefully, seeks clarification, and separates stated preferences from measurable requirements. CTQ TreesA critical-to-quality (CTQ) tree translates a broad customer need into measurable requirements. It normally progresses through three levels: 1. Need: the broad customer expectation, such as dependable service. 2. Driver: a factor that enables the need, such as timely and accurate completion. 3. Requirement or measure: an operational specification, such as completion within two business days and an accuracy rate above a defined threshold. A CTQ tree is useful because it prevents the team from measuring what is easy rather than what matters. It also supports the distinction between quality characteristics and process measures. For instance, “customer confidence” may be difficult to measure directly, while repeat-contact rate, error-free completion, or adherence to a promised response time may serve as measurable indicators. A CTQ should have an operational definition. “Fast response” is ambiguous; “time from receipt of a valid request to the first substantive response, measured in business hours and excluding customer-caused waiting time” is more useful. Operational definitions reduce disagreement among data collectors and support consistent analysis. Critical Customer and Business MeasuresA project often uses three related classes of measures. Customer measures reflect external or internal experience, such as delivery reliability or defect-free service. Process measures describe activities that influence outcomes, such as queue time, rework rate, or first-pass yield. Business measures reflect organizational consequences, such as cost per transaction, capacity, risk exposure, or revenue leakage. These measures should be connected through a plausible process logic. A shorter processing time is not an improvement if it increases errors and creates rework. Therefore, the goal should identify primary improvement measures and important guardrail measures. Guardrails prevent local optimization and unintended harm. SIPOC and High-Level Process UnderstandingSIPOC—Suppliers, Inputs, Process, Outputs, and Customers—is a high-level map used early in Define. It provides a common view of the process without attempting to document every task. The team identifies who supplies critical inputs, what those inputs are, the major process stages, the outputs produced, and who receives or depends on those outputs. A SIPOC is especially useful when team members hold different mental models of the process. It can reveal that a supposed “department problem” begins with incomplete inputs from another function or that an output is used by a customer not represented in the original discussion. SIPOC also supports scope definition: the project may start at a specified input condition and end at a defined output. SIPOC is not a substitute for a detailed process map. It does not normally show decision logic, cycle times, queues, rework loops, or individual responsibilities. Its value lies in establishing the system boundary and identifying relationships that require deeper investigation during Measure and Analyze. Measure: Establishing the Performance BaselineOperational Definitions and Data ArchitectureThe Measure phase begins by converting concepts into data specifications. For every important measure, the team should define what is counted, the unit of analysis, the inclusion and exclusion rules, the measurement point, the time basis, the data source, and the person or system responsible for collection. Suppose a hospital department wishes to measure waiting time. The definition must specify whether waiting begins at patient arrival, registration, or clinical triage; whether scheduled appointments are treated differently from walk-ins; and whether time is measured in minutes, elapsed hours, or business hours. Without such decisions, two apparently precise datasets may represent different phenomena. A data collection plan normally identifies: - measure name and purpose;
- operational definition;
- data type and unit;
- source and collection method;
- sampling frame and sample size rationale;
- frequency and duration of collection;
- stratification variables;
- responsible collector;
- treatment of missing, duplicate, or unusual observations;
- security and access requirements.
Types of Data and MeasuresContinuous data can take values on a scale, such as cycle time, temperature, weight, or cost. Discrete or attribute data records categories or counts, such as conforming/nonconforming, number of defects, or complaint type. Continuous data often provides more information, but discrete data may be more practical for operational decisions. A unit is the entity being studied: a transaction, patient, shipment, account, call, or batch. A defect is a failure to meet a requirement, while a defective unit is a unit containing one or more defects. Confusing these terms can distort performance estimates. For example, one shipment may contain several damaged items; counting damaged items and counting damaged shipments answer different questions. Common baseline measures include defect rate, defects per unit, first-pass yield, process cycle efficiency, lead time, on-time delivery, service-level attainment, and cost per unit. The measure must match the business question. An average may conceal a long tail of delays, so median, percentile, range, and variation should be considered where appropriate. Sampling and RepresentativenessA baseline should represent normal process performance rather than an unusually good or bad period selected for convenience. The team should consider seasonality, shifts, locations, product types, customer segments, and workload conditions. Stratification is valuable when different groups may perform differently. Random or systematic sampling can reduce selection bias, while a census may be appropriate when transaction volumes are small or data is readily available. The sample size should be justified in relation to the measure, expected variation, desired precision, and practical constraints. A large but biased sample is not automatically better than a smaller representative sample. Data collected after announcing the project may also differ from ordinary performance because employees change behaviour. This reactivity should be recognized rather than ignored. Baseline analysis should display both central tendency and variation. Run charts, time-series plots, histograms, box plots, Pareto charts, and stratified summaries can show patterns that a single average conceals. At this stage, the purpose is to describe the current state, not to claim root causes. Validating the Measurement SystemWhy Measurement-System Analysis MattersMeasurement-system analysis (MSA) examines whether observed data adequately represents the process condition being studied. Variation in the observed result may arise from the process itself or from the measurement system. A team that does not separate these sources may attempt to improve a stable process or fail to detect real deterioration. A measurement system includes the instrument, software, method, operating procedure, environment, data definitions, and people who record or interpret results. In service processes, the “instrument” may be a timestamping system, classification rule, audit checklist, or human judgment rather than a physical gauge. Important dimensions include: - validity or accuracy: closeness to the accepted reference value;
- repeatability: variation when the same appraiser or system measures the same item repeatedly;
- reproducibility: variation between appraisers or measurement conditions;
- stability: consistency over time;
- resolution or discrimination: ability to distinguish meaningful differences;
- completeness and integrity: whether records are missing, altered, duplicated, or inaccessible.
Selecting an MSA ApproachFor continuous measurements, a gauge repeatability and reproducibility study may be appropriate when a physical or numerical gauge is used. The study estimates variation associated with repeated measurements and different appraisers. The design should use representative parts or cases and a realistic measurement procedure; an artificial study can give false confidence. For attribute judgments, such as pass/fail inspection or complaint classification, attribute agreement analysis can assess consistency within and between appraisers and agreement with a known standard. If no unquestioned standard exists, the team should acknowledge that limitation and use adjudication, expert panels, or carefully documented reference cases. Administrative and digital data require a different form of validation. The team should check field definitions, system timestamps, extraction logic, duplicate records, missing values, status codes, manual overrides, and changes in software configuration. A data dictionary and reconciliation against source records are often more valuable than a traditional gauge study. Measurement improvement may involve calibration, revised definitions, training, automated capture, better system integration, or simplification of classification categories. It is important not to “clean” inconvenient observations merely because they conflict with expectations. Data corrections must be traceable and justified. An Illustrative Case: Reducing Order-Release DelayBackgroundThe following fictional case illustrates how Define and Measure can be applied in a medium-sized industrial distributor. Customers reported that confirmed orders were not being released to the warehouse quickly enough. Sales managers believed that the order-entry team needed additional training. Situation and ProblemAn initial review found that the elapsed time between receipt of a complete customer order and warehouse release varied considerably. The business case identified delayed deliveries, customer escalations, and additional expediting work. The project sponsor approved a DMAIC project limited to domestic standard orders. International orders, credit disputes, and product shortages were initially excluded because their workflows were materially different. The problem statement was: “For domestic standard orders received during the previous quarter, the time from acceptance of a complete order to warehouse release exceeded the internal service expectation for a substantial proportion of orders, with large variation across days and order types.” The team deliberately avoided stating that training was the cause. The goal statement was: “Reduce the proportion of eligible orders exceeding the internal release-time requirement while maintaining order accuracy and compliance with credit controls.” A specific numerical target was added after baseline data quality was confirmed. Define-Phase AnalysisThe team constructed a SIPOC. Sales channels and electronic customers supplied order information; the inputs included product, quantity, delivery address, and credit status. The major process stages were order receipt, validation, credit review, inventory confirmation, release decision, and warehouse notification. Outputs were released orders or exception requests. Customers included the warehouse, customer-service staff, sales representatives, and the external buyer. VOC interviews revealed that customers valued predictable delivery more than a uniformly minimal processing time. This led the team to include order accuracy and reliable promise dates as guardrail measures. A CTQ tree translated “quick and dependable order handling” into measurable requirements: release within the service expectation, no unauthorized credit release, and no increase in order-entry defects. Stakeholder analysis showed that the order-entry supervisor, credit manager, warehouse planner, sales representatives, information-systems analyst, and process owner all had relevant interests. The credit manager initially resisted the project because speed could threaten control. Including credit compliance as a guardrail helped align the project with risk requirements. Measure-Phase AnalysisThe team created an operational definition: elapsed release time was the difference between the system timestamp for acceptance of a complete eligible order and the timestamp for warehouse release. Orders with missing mandatory information, credit holds, product shortages, or system outage codes were recorded separately rather than silently removed. A data audit identified two problems. First, some staff manually changed the acceptance timestamp when correcting an order. Second, a system interface recorded warehouse release in batches, creating artificial peaks. The team reconciled a sample of electronic records with transaction histories and interviewed users about timestamp practices. The baseline was therefore divided into process time and known system-delay categories where possible. A time-series display showed that performance varied by shift and by order channel. The team did not conclude that a particular shift caused the gap. Instead, it identified these variables for later analysis and collected additional data under consistent definitions. Accuracy and credit-control compliance were tracked alongside release time. Outcome and LearningThe project had not yet reached Analyze, Improve, or Control, but Define and Measure produced an important result: the original training hypothesis was unsupported. The principal measurement risk was timestamp integrity and unclear exclusion rules, not a demonstrated lack of employee knowledge. The project was approved at the Measure tollgate only after the data dictionary, collection plan, and validation checks were documented. The case demonstrates that early DMAIC work can create value before a solution is implemented. It prevents the organization from investing in training without evidence, protects compliance requirements, and establishes a credible basis for identifying causes. Challenges, Risks, and Common MistakesThe most common Define-phase mistake is writing a solution into the problem statement. Statements such as “implement a new software system” or “train employees” close inquiry before causes are known. Another error is selecting a project because the data is convenient rather than because the problem matters. Scope creep is also frequent. Stakeholders may introduce related complaints that are important but outside the agreed process boundary. The correct response is to record them, assess their relationship, and decide whether to include, defer, or create a separate project. In Measure, teams often confuse data availability with data validity. A dashboard may display precise numbers generated from inconsistent definitions. Other risks include survivorship bias, under-reporting of defects, missing data, duplicate transactions, changes in coding practice, and inappropriate aggregation. Averages can disguise variation and inequity between customer groups, shifts, locations, or product categories. Conversely, excessive segmentation can produce unstable conclusions from very small samples. Measurement studies can also fail when appraisers are trained for the study but not for routine work, or when the selected test items are unusually easy to classify. Projects may be distorted by incentives. If employees believe that poor performance will lead to punishment, they may alter records or avoid registering defects. Ethical project leadership requires psychological safety, confidentiality where appropriate, transparent definitions, and separation of process learning from individual blame. Personal data should be collected only when necessary, protected through access controls, and reported at a level that supports improvement without unnecessary identification. Digital Tools, Analytics, and Emerging PracticeModern organizations increasingly use enterprise-resource-planning systems, customer-relationship platforms, workflow tools, process mining, and automated data pipelines during Measure. Process-mining software can reconstruct event sequences and reveal queues, rework loops, and variation between actual and designed workflows. Its results remain dependent on event-log completeness and correct case identifiers. Automated dashboards can provide near-real-time indicators, but speed does not eliminate the need for operational definitions or measurement validation. Artificial intelligence may assist with complaint classification, text extraction, anomaly detection, and prioritization of records for review. Human oversight is required because models can reproduce classification bias, misinterpret context, and change behaviour when users learn how outputs are generated. A contemporary measurement architecture should include data lineage, version-controlled definitions, audit trails, role-based access, and documented changes to algorithms or system fields. These controls are especially important when performance data informs employment decisions, customer eligibility, regulatory reporting, or financial commitments. Best Practices for Define and MeasureEffective projects typically follow several principles: 1. Begin with a verified business problem, not a preferred solution. 2. Write a measurable, neutral problem statement and a time-bound goal. 3. Establish explicit scope boundaries and identify exclusions. 4. Involve process owners, customers, frontline employees, and control functions. 5. Translate VOC into CTQs and operational definitions. 6. Use SIPOC to create a shared high-level view of the process. 7. Define primary measures and guardrail measures together. 8. Validate the measurement system before interpreting process variation. 9. Examine variation over time and across meaningful strata. 10. Maintain a decision log and use tollgates for evidence-based governance. 11. Protect data integrity, privacy, and the dignity of employees. 12. Treat the charter and data plan as controlled documents that may evolve with evidence. Chapter SummaryDefine and Measure establish the intellectual and evidential foundation of DMAIC. Define converts a business concern into a justified project through the business case, problem statement, goal statement, charter, scope, stakeholder analysis, VOC, CTQ tree, and SIPOC. Measure translates requirements into operational definitions, data plans, baselines, and descriptions of variation. It also tests whether the measurement system is accurate, consistent, stable, and fit for purpose. Tollgates provide governance by requiring evidence before the project advances. The central lesson is that improvement should not begin with an assumed cause or solution. It should begin with a meaningful problem, a clear customer and business requirement, and trustworthy data. Key TermsBusiness case: A rationale linking a performance problem to organizational consequences and potential value. Project charter: A controlled document defining the purpose, boundaries, governance, roles, and objectives of a DMAIC project. Problem statement: A factual description of the current performance gap, without assigning an unverified cause. Goal statement: A measurable and time-bound description of intended improvement. Scope: The defined process, population, product, location, and period included in a project. Stakeholder: A person or group that affects, is affected by, or has an interest in the project or process. Voice of the Customer: Information expressing customer needs, expectations, experiences, and dissatisfaction. CTQ: A critical-to-quality requirement that translates customer expectations into measurable characteristics. Operational definition: A precise specification of how a concept or measure is identified, counted, and recorded. SIPOC: A high-level map of Suppliers, Inputs, Process, Outputs, and Customers. Baseline: A documented representation of current process performance before improvement. Continuous data: Numerical data measured on a scale and capable of taking values within a range. Discrete data: Count or category data consisting of separate values or classifications. Defect: A failure to meet a specified requirement. Defective unit: A unit containing one or more defects. Measurement-system analysis: Evaluation of whether a measurement process produces dependable information. Repeatability: Variation when the same measurement system or appraiser measures the same item repeatedly. Reproducibility: Variation between appraisers, operators, or measurement conditions. Tollgate: A formal review point at which project evidence is assessed and a decision is made to proceed, revise, or stop. Guardrail measure: A measure monitored to ensure that improvement in one outcome does not create unacceptable harm elsewhere. Review QuestionsShort Answer Questions1. What distinguishes a problem statement from a goal statement? 2. Why is a SIPOC useful during the Define phase? 3. Define an operational definition and explain its purpose. 4. What is the difference between repeatability and reproducibility? 5. Why should guardrail measures be included in a DMAIC project? Long Answer Questions1. Explain how a business case, project charter, scope statement, and stakeholder analysis work together to launch a DMAIC project. 2. Discuss the process of converting VOC into CTQs, using an example of a service process. 3. Explain the major components of a Measure-phase data collection plan. 4. Discuss how an organization can validate a measurement system for both physical and administrative data. 5. Explain the role of tollgates in DMAIC governance and describe the evidence expected at the Define and Measure tollgates. Analytical / Application Questions1. A call centre claims that its service is “too slow,” but has no agreed definition of response time. Develop a problem statement, a CTQ tree, and an operational definition for a suitable measure. 2. A manufacturing team reports a lower defect rate after changing inspection staff. Propose a measurement-system investigation that would determine whether the apparent improvement is real. 3. A hospital project seeks to reduce patient waiting time but proposes excluding patients who leave before treatment. Evaluate this decision and recommend a baseline and guardrail-measure strategy. 22. Multiple Choice Questions with AnswersQuestion 1Which statement best represents an appropriate DMAIC problem statement? A. The order-entry team needs additional training. B. A new workflow system should be implemented immediately. C. Eligible orders have exceeded the internal release-time expectation during the defined period, with substantial variation across order types. D. Employees are not sufficiently committed to customer service. Correct Answer: C. Eligible orders have exceeded the internal release-time expectation during the defined period, with substantial variation across order types. Question 2The primary purpose of a project charter is to: A. Prove the root cause before data collection begins. B. Authorize and align the project by defining its rationale, boundaries, roles, and objectives. C. Document every detailed task in the process. D. Guarantee that the original scope can never change. Correct Answer: B. Authorize and align the project by defining its rationale, boundaries, roles, and objectives. Question 3Which sequence correctly represents a CTQ tree? A. Supplier, input, process B. Need, driver, measurable requirement C. Defect, cause, solution D. Goal, budget, schedule Correct Answer: B. Need, driver, measurable requirement Question 4A SIPOC is most useful for: A. Calculating measurement-system repeatability. B. Identifying verified root causes statistically. C. Creating a shared high-level view of suppliers, inputs, process, outputs, and customers. D. Replacing all detailed process maps. Correct Answer: C. Creating a shared high-level view of suppliers, inputs, process, outputs, and customers. Question 5Why should a measurement system be validated before baseline performance is interpreted? A. Because measurement variation may be mistaken for process variation. B. Because baseline data is never useful without financial data. C. Because only continuous data can be used in DMAIC. D. Because validation automatically identifies the root cause. Correct Answer: A. Because measurement variation may be mistaken for process variation. Question 6Which example is continuous data? A. Defect category B. Pass or fail status C. Number of complaints D. Invoice approval time in hours Correct Answer: D. Invoice approval time in hours Question 7In the illustrative order-release case, what was a major measurement risk? A. The team had too many verified root causes. B. Timestamp integrity and inconsistent exclusion rules affected the data. C. Customers preferred slower delivery. D. The project had no process owner. Correct Answer: B. Timestamp integrity and inconsistent exclusion rules affected the data. Question 8A guardrail measure is included primarily to: A. Replace the project goal with a financial target. B. Ensure that improvement in one outcome does not create unacceptable deterioration elsewhere. C. Increase the number of data points collected regardless of relevance. D. Identify which employee caused a defect. Correct Answer: B. Ensure that improvement in one outcome does not create unacceptable deterioration elsewhere. Question 9Which action best reflects sound Measure-phase practice? A. Remove unusual observations before examining them. B. Use the average alone because variation is secondary. C. Document inclusion rules, sampling conditions, data sources, and treatment of missing records. D. Collect data only from the best-performing shift. Correct Answer: C. Document inclusion rules, sampling conditions, data sources, and treatment of missing records. Question 10At a Measure tollgate, the most appropriate evidence is: A. A preferred solution and implementation schedule. B. A validated data plan, operational definitions, baseline evidence, and measurement-system assessment. C. A final control plan proving the gains are sustained. D. A list of employees who should be retrained. Correct Answer: B. A validated data plan, operational definitions, baseline evidence, and measurement-system assessment.
|
