Six Sigma Methodology

Chapter 4
Define Phase: Project Framing

Post Graduate Program in Total Quality Management
Six Sigma Methodology   •   Post Graduate

Define Phase: Project Framing

Introduction

The Define phase is the first phase of the Six Sigma DMAIC methodology: Define, Measure, Analyze, Improve, and Control. Its purpose is not to solve the process problem prematurely, but to establish a disciplined agreement about which problem matters, why it matters, what success means, who is affected, and where the project begins and ends.

Poorly framed projects create predictable consequences. Teams may measure the wrong process, optimize a symptom rather than a cause, disagree about the project’s boundaries, or declare success without demonstrating customer or business benefit. A high-quality Define phase therefore functions as a governance mechanism as much as a planning activity.

At postgraduate level, project framing should be understood as a socio-technical activity. It combines strategic alignment, process thinking, stakeholder negotiation, customer-value analysis, risk management, and evidence-based decision-making. The principal deliverable is a coherent project charter, supported by a business case, problem and goal statements, scope definition, stakeholder analysis, communication plan, and high-level process map.

Learning Objectives

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

  1. Construct a defensible business case for a Six Sigma project.
  2. Distinguish a problem statement from a goal statement and a solution statement.
  3. Develop and critically evaluate a project charter.
  4. Define project scope using SIPOC, process boundaries, and explicit exclusions.
  5. Analyze stakeholders, their interests, influence, and likely resistance.
  6. Design a communication plan appropriate to different stakeholder groups.
  7. Create a high-level process map that supports project framing.
  8. Incorporate operational, ethical, regulatory, and implementation risks into the project definition.
  9. Judge whether a proposed project is sufficiently mature to enter the Measure phase.

1. The Strategic Purpose of Define

Six Sigma projects should be selected because they address a meaningful performance gap connected to organizational priorities, customer requirements, compliance obligations, or material risk. Define converts a vague concern—such as “claims processing is slow”—into a bounded improvement opportunity.

The Define phase answers five questions:

  • What is the opportunity or problem?
  • Who experiences its consequences?
  • What process or system is involved?
  • What measurable result is expected, and by when?
  • What authority, resources, and boundaries govern the work?

A project is not adequately defined merely because it has a title and a team. It is defined when different stakeholders hold a sufficiently consistent interpretation of the project’s purpose, outcome, boundaries, decision rights, and evidence requirements.

Project selection and strategic alignment

A portfolio may contain many improvement opportunities. Selection should consider more than financial return. A useful screening model evaluates strategic alignment, customer impact, regulatory significance, feasibility, urgency, and risk. For example, an organization may score each criterion from 1 to 5 and calculate a weighted score:

S = ∑(wᵢrᵢ), where ∑wᵢ = 1

Here, S is the project’s weighted screening score, wᵢ is the weight assigned to criterion i, and rᵢ is the project’s rating on that criterion. The weights are dimensionless and should sum to 1. This model is a prioritization aid, not a substitute for managerial judgment. Ratings should be documented, and sensitivity analysis is advisable when two projects have similar scores.

A high score does not automatically justify a project. A strategically important project may still be unsuitable for DMAIC if the problem is not measurable, the process owner cannot support the work, or the apparent cause is already known and requires a straightforward implementation rather than structured investigation.

2. Building the Business Case

The business case explains why the organization should invest time, people, and money in the project. It connects process performance to consequences such as cost, revenue, capacity, customer loyalty, employee workload, safety, risk, or regulatory exposure.

A strong business case contains four elements:

  1. Current condition: What is happening, where, and with what evidence?
  2. Business or customer consequence: Why does the condition matter?
  3. Opportunity: What value could be created if performance improved?
  4. Investment and governance: What resources and decisions are required?

The business case should distinguish verified benefits from hypotheses. For example, “late deliveries are believed to cause customer dissatisfaction” is not equivalent to evidence showing a relationship between delivery performance and complaint rates.

Benefit categories

Benefits may be classified as follows:

Benefit categoryTypical indicatorCaution
FinancialCost avoided, revenue protected, working capital releasedAvoid counting theoretical savings as realized cash
CustomerDefects, complaints, retention, service-level attainmentDefine the customer segment and measurement period
OperationalCycle time, throughput, capacity, reworkCapacity is not a saving unless demand or staffing changes
Risk and complianceIncidents, audit findings, control failuresLegal and safety benefits may not be reducible to money
PeopleWorkload, ergonomic exposure, engagement, turnoverDo not treat employee impact as a secondary concern

Financial reasoning must be transparent. If annual benefit is estimated from reduced defects, a simple estimate may be written as:

Annual gross benefit = ΔD × Cᴅ × N

Here, ΔD is the reduction in defects per transaction, Cᴅ is the validated cost per defect, and N is the annual number of transactions. The units must be consistent: for example, defects per transaction × currency per defect × transactions per year gives currency per year. The estimate assumes that the defect cost is appropriately measured and that the reduction applies to the stated transaction volume. It does not automatically represent cash released; fixed costs, demand, and accounting treatment must be examined.

Where investment is known, a simple benefit-to-cost ratio can support comparison:

Benefit–cost ratio = Present value of benefits ÷ Present value of costs

This ratio is not a complete investment appraisal. Projects with different durations, risk profiles, or strategic importance may require discounted cash-flow analysis, scenario analysis, or non-financial evaluation.

Voice of the Customer and Critical-to-Quality requirements

The Voice of the Customer (VOC) includes explicit complaints, interviews, surveys, service agreements, usage data, and observed customer behavior. VOC should be translated into measurable Critical-to-Quality (CTQ) requirements. A statement such as “customers want fast service” is incomplete. A CTQ may specify response time, completeness, accuracy, availability, or reliability, together with an operational definition.

For example:

  • VOC: “I need my reimbursement processed quickly.”
  • CTQ: “Percentage of complete reimbursement claims paid within five business days.”

The CTQ must identify the unit, inclusion and exclusion rules, start and stop points, and acceptable performance. This prevents later disagreement over what counts as a defect.

3. Problem, Goal, and Scope Statements

The problem statement

A problem statement describes the gap between current and expected performance without asserting an unverified cause or solution. It should be specific enough to guide measurement and neutral enough to permit investigation.

A useful structure is:

Between [time period], [process or population] produced [observable performance], compared with [requirement or reference], resulting in [consequence].

For example:

Between January and June, 18.4% of complete outpatient reimbursement claims exceeded the five-business-day service requirement, creating customer complaints and additional status enquiries.

This statement identifies time, population, metric, requirement, and consequence. It does not say that staff training, software, or workload is the cause.

A weak statement is “The claims system is inefficient.” It is vague, potentially biased toward a cause, and difficult to measure.

The goal statement

The goal statement expresses the intended improvement, population, metric, and deadline. It should be ambitious but credible and should not prescribe the method of improvement.

By 30 November, reduce the proportion of complete outpatient reimbursement claims exceeding five business days from the validated baseline to 5% or less, without increasing payment errors or compliance exceptions.

The goal includes a primary outcome and guardrails. Guardrails are important because local improvement can create undesirable effects elsewhere—for example, faster processing accompanied by more incorrect payments.

A goal should not be written as “implement an automated workflow.” Automation is a solution, not an outcome. The team may ultimately recommend automation, but that decision should follow analysis.

Scope and boundaries

Scope answers where the project applies and where it does not. Typical scope dimensions include product or service, customer segment, geography, process stages, systems, time period, and performance metric.

A practical scope statement identifies:

  • In scope: processes, products, locations, transactions, and performance measures included.
  • Out of scope: related activities deliberately excluded.
  • Interfaces: handoffs to suppliers, customers, or adjacent processes.
  • Constraints: legal, technical, contractual, staffing, or time limitations.
  • Assumptions: conditions accepted provisionally and subject to validation.

Overly broad scope produces a “boil the ocean” project. Overly narrow scope may optimize one step while shifting defects to a customer or downstream process. Scope must therefore be reviewed at system boundaries, not only within departmental boundaries.

4. The Project Charter

The charter is the formal agreement that authorizes the project. It is a living governance document, but changes should be controlled and visible. A typical charter contains:

Charter elementPurpose
Project title and sponsorEstablish identity and executive ownership
Business caseExplain strategic and operational importance
Problem statementDefine the verified performance gap
Goal statementSpecify measurable intended improvement
CTQs and primary metricRepresent customer and business requirements
Scope and exclusionsPrevent uncontrolled expansion
Timeline and milestonesEstablish cadence and decision points
Team and rolesClarify expertise, availability, and accountability
Risks, assumptions, constraintsExpose conditions that could invalidate the plan
Expected benefitsDescribe value and benefit-validation method
Governance and escalationDefine authority and decision rights

Roles and accountability

The sponsor provides authority, removes organizational barriers, and validates strategic alignment. The process owner is accountable for the process after the project and must be involved in defining practical outcomes. The project leader or Black Belt manages the method, evidence, facilitation, and progress. Green Belts and subject-matter experts contribute process knowledge and analysis. A Master Black Belt or quality leader may provide methodological coaching and governance.

Responsibility should not be confused with authority. A team may be responsible for analysis but lack authority to change a policy, budget, or information system. Such dependencies must appear in the charter.

Readiness review

Before entering Measure, the sponsor and process owner should confirm that:

  • the problem is factual and not merely a preferred solution;
  • the customer and business consequences are understood;
  • the primary outcome metric has an operational definition;
  • scope and exclusions are explicit;
  • the process owner and team have been identified;
  • access to data and people is feasible;
  • ethical, safety, privacy, and regulatory obligations are recognized; and
  • the goal does not encourage harmful workarounds or data manipulation.

5. SIPOC and the High-Level Process Map

A high-level process map provides a shared view of the process without prematurely documenting every decision or task. SIPOC stands for Suppliers, Inputs, Process, Outputs, and Customers. It is especially useful at the beginning of Define because it reveals the process boundary and major interfaces.

SIPOC elementGuiding questionExample: reimbursement claims
SuppliersWho provides required inputs?Patient, clinic, insurer, payment system
InputsWhat enters the process?Claim form, receipts, eligibility data
ProcessWhat are the major stages?Receive, validate, adjudicate, pay, notify
OutputsWhat does the process produce?Payment decision, payment, notification
CustomersWho receives or depends on outputs?Patient, provider, finance, regulator

A high-level process map should show major activities, decision points, handoffs, feedback loops, and relevant systems. It should not pretend that the process is linear if rework or parallel work exists.

For the reimbursement example, the high-level sequence may be:

  1. Claim submitted.
  2. Claim received and registered.
  3. Completeness and eligibility checked.
  4. Claim adjudicated.
  5. Decision approved, queried, or rejected.
  6. Payment released.
  7. Customer notified.
  8. Exceptions and appeals routed for further handling.

The map should identify where the project begins and ends. If the project concerns complete claims only, claim submission and incomplete-claim correspondence may be outside the primary analysis but should remain visible as an interface.

A process map is a hypothesis about process behavior, not proof of actual performance. It must later be validated through observation, records, interviews, and data.

6. Stakeholder Analysis and Communication Planning

Stakeholders include anyone who can affect the project, is affected by its results, controls necessary resources, or has a legitimate interest in the decision. Stakeholder analysis is not a political exercise to be completed once; it is an ongoing assessment of power, interests, knowledge, impact, and willingness to participate.

A practical influence–impact matrix can classify stakeholders:

CategoryTypical approach
High influence, high impactEngage closely; involve in decisions and risk reviews
High influence, low direct impactKeep satisfied; provide concise governance information
Low influence, high impactConsult respectfully; protect their interests and voice
Low influence, low impactMonitor and inform proportionately

Analysis should also identify hidden stakeholders. Frontline employees, patients, temporary workers, data-protection officers, suppliers, and downstream recipients may have limited formal authority but substantial operational or ethical significance.

Communication plan

A communication plan specifies what information is needed, by whom, when, through which medium, and with what expected action. It should distinguish communication from consultation. Sending a dashboard is communication; asking frontline staff to validate a process assumption is consultation.

AudienceInformationPurposeFrequency and owner
SponsorMilestones, risks, decisions requiredGovernance and escalationFortnightly; project leader
Process ownerFindings, operational impacts, dependenciesOwnership and implementationWeekly; project leader
Frontline staffScope, participation, emerging learningTrust and accurate process knowledgeWeekly or at key events; team lead
Compliance officerData use, control risks, regulatory impactsAssuranceAt charter and decision gates
Customers or representativesRelevant service expectations and changesVOC and legitimacyAt discovery and validation stages

Communication should avoid overstating results. Early observations must be labeled as preliminary, and confidential or personal data must be handled according to organizational policy and applicable law.

7. Risk-Informed Project Definition

Risk-informed framing asks what could prevent the project from producing a valid and beneficial result. Risks may arise from the process, project design, data, stakeholders, technology, or external environment.

A simple qualitative risk-prioritization model may use:

R = L × I

Here, R is a risk score, L is likelihood, and I is impact, each defined on an agreed ordinal scale such as 1 to 5. Because these scores are ordinal rather than measured physical quantities, multiplication creates a prioritization convention, not a probability or monetary expectation. Teams should document scale definitions and avoid treating a score of 12 as literally twice as risky as a score of 6.

Typical Define-phase risks include:

  • unclear ownership of the end-to-end process;
  • inaccessible, incomplete, or biased data;
  • a goal that conflicts with safety or compliance;
  • resistance caused by fear of blame or job loss;
  • scope expansion into unrelated performance issues;
  • benefits claimed without a validation owner;
  • supplier or system changes during the project;
  • privacy breaches through unnecessary access to personal data; and
  • pressure to select a favored solution before analysis.

Controls include early data-access agreements, anonymization, documented definitions, sponsor escalation, inclusion of frontline knowledge, explicit guardrail metrics, and staged decision gates.

Ethical and governance considerations

Six Sigma is not ethically neutral merely because it uses data. A project may affect workload, performance evaluation, access to services, or employment. Define should therefore establish:

  • whether personal, health, financial, or sensitive data will be used;
  • who may access data and for what purpose;
  • whether consent, legal authority, or institutional approval is required;
  • how confidentiality and retention will be managed;
  • whether the project could disadvantage a protected group;
  • whether employees can safely report process failures; and
  • how decisions will be reviewed and appealed.

A project that reduces average service time by systematically delaying a vulnerable customer group is not a quality success. Equity and harm indicators may need to be included as guardrails.

8. Technology and AI in Project Framing

Digital systems can accelerate VOC analysis, process discovery, document classification, and charter drafting. Process-mining tools may reconstruct event sequences from system logs, helping reveal rework, waiting, and variant paths. However, event logs represent recorded system activity, not necessarily the full work system. Manual work, informal escalation, and undocumented exceptions can be invisible.

Generative AI may assist with summarizing interviews, clustering complaints, or proposing stakeholder questions. It should not be treated as an authoritative source. Human review is required because AI systems may reproduce confidential information, infer unsupported causes, misclassify minority voices, or obscure uncertainty. Organizations should define data-governance rules before sensitive material is entered into such tools.

Technology selection belongs after problem framing unless technology itself is the documented subject of the project. Beginning with “we need AI” reverses the logic of DMAIC and risks automating waste.

9. Worked Application: Outpatient Reimbursement Claims

Background

An illustrative regional health insurer receives outpatient reimbursement claims through a portal, email, and postal channels. Customers have a service expectation that complete claims will be paid or formally decided within five business days.

Initial concern

Customer service reports increasing “where is my claim?” enquiries. Managers initially propose adding staff and introducing automated document recognition.

Define-phase analysis

The project team reviews complaint categories, service-level reports, and interviews with claims staff. It finds that the reported delay concerns complete claims, while incomplete claims follow a separate correspondence path. The team therefore limits the primary project to complete outpatient claims received through the portal and email channels. Postal claims are excluded because they require a different scanning process, though the interface is recorded as a future opportunity.

The resulting business case is that delayed decisions increase customer contact, create avoidable rework, and expose the insurer to service-level risk. The team does not yet claim that staffing or technology is the cause.

Problem statement: From January through June, 18.4% of complete outpatient portal and email claims exceeded five business days from recorded receipt to payment decision. The delay generated additional enquiries and increased backlog volatility.

Goal statement: By 30 November, reduce the proportion of complete outpatient portal and email claims exceeding five business days to 5% or less, while maintaining payment accuracy and compliance performance at or above current validated levels.

Primary CTQ: Timely decision for a complete claim.

Guardrails: Payment-error rate, compliance exceptions, customer complaints, and employee overtime.

High-level process boundary: From system receipt of a complete claim to payment decision notification. The project excludes policy redesign, postal scanning, and changes to benefit eligibility rules.

Stakeholder analysis

The sponsor is the claims director. The process owner is the head of claims operations. Claims assessors and customer-service agents are high-impact stakeholders because they understand exceptions and experience consequences. The information-security and privacy officers are consulted because claims may contain health and financial information. Finance and compliance are involved in benefit validation and control review.

Risk-informed framing

The principal early risks are inconsistent definitions of “complete,” missing timestamps for email claims, and employee concern that the project is a productivity audit. Mitigations include an operational-definition workshop, data-quality checks in Measure, and communication that the project evaluates process performance rather than individual blame.

Outcome of the Define phase

The charter authorizes measurement of the bounded process. It does not authorize automation or staff reductions. Those may become options only after the team establishes the baseline, identifies causes, and evaluates alternatives. This distinction protects the integrity of DMAIC and keeps decisions connected to evidence.

Learning points

  1. The customer requirement became measurable only after defining the population and time boundary.
  2. The initial solution proposal was deliberately separated from the problem definition.
  3. Scope exclusions reduced complexity without hiding important interfaces.
  4. Guardrails prevented speed from being pursued at the expense of accuracy or compliance.
  5. Employee participation was treated as a source of process knowledge, not merely as an implementation issue.

10. Common Failure Modes and Best Practices

Failure modes

Solution disguised as a problem. “Implement a chatbot” prevents unbiased investigation.

Vague outcome. “Improve service” lacks a metric, population, and deadline.

Unbounded scope. Including every related process makes ownership and measurement impossible.

Departmental framing. Optimizing one department may transfer waiting or rework to another.

Unvalidated financial benefit. Theoretical capacity or avoided cost is reported as cash savings.

Metric without operational definition. Different analysts count different transactions or start and stop the clock differently.

Token stakeholder engagement. Frontline staff are informed after decisions have already been made.

Premature technology commitment. A preferred tool becomes the project objective.

Ignoring adverse effects. Faster throughput is celebrated despite rising errors, inequity, or employee harm.

Best practices

  • Link the project to a strategic, customer, compliance, or risk priority.
  • Use evidence, while clearly labeling assumptions and hypotheses.
  • Define the unit of analysis and the start and stop points.
  • Include the process owner from the beginning.
  • Use SIPOC to establish shared boundaries before detailed mapping.
  • Make exclusions explicit and record adjacent opportunities.
  • Include guardrail measures in the goal and charter.
  • Treat the charter as controlled, revisable governance rather than paperwork.
  • Validate benefits with Finance or the responsible benefit owner.
  • Protect confidentiality and create psychologically safe channels for process information.
  • Conduct a readiness review before entering Measure.

Chapter Summary

The Define phase frames a Six Sigma project as a disciplined response to a meaningful performance gap. Its central outputs are the business case, problem statement, goal statement, CTQs, project charter, scope definition, SIPOC or high-level process map, stakeholder analysis, communication plan, and initial risk assessment. The business case establishes why action matters, while the problem statement describes the current gap without assuming a cause. The goal statement specifies a measurable future condition and should include guardrails against harmful optimization.

Effective scope definition identifies process boundaries, interfaces, exclusions, constraints, and assumptions. SIPOC and high-level mapping create a shared system view without pretending to provide detailed causal evidence. Stakeholder and communication planning recognize that process knowledge, authority, trust, and ethical legitimacy are essential to improvement. Risk-informed framing addresses data quality, privacy, compliance, equity, implementation, and governance risks before measurement begins.

A mature Define phase does not select a solution prematurely. It creates the conditions for valid measurement and analysis, aligns stakeholders around a consequential objective, and establishes how benefits and unintended effects will be judged.

Key Terms

Business case: Evidence-based justification for investing in a project.

Charter: Formal document authorizing and governing a Six Sigma project.

Critical-to-Quality (CTQ): Measurable requirement that represents customer or business value.

DMAIC: Define, Measure, Analyze, Improve, and Control improvement methodology.

Goal statement: Quantified intended performance outcome with a time frame.

Guardrail metric: Measure used to detect harmful or undesirable side effects.

High-level process map: Simplified representation of major process stages and interfaces.

Operational definition: Precise rule specifying how a measure, unit, or event is counted.

Out of scope: Activity, population, location, or issue deliberately excluded from a project.

Problem statement: Evidence-based description of a performance gap without an assumed solution.

Process owner: Person accountable for ongoing performance and management of the process.

Project sponsor: Senior leader who provides authority, resources, and escalation support.

Risk-informed framing: Defining a project while considering threats to validity, value, safety, and compliance.

SIPOC: Suppliers, Inputs, Process, Outputs, and Customers framework.

Stakeholder: Person or group able to affect, affected by, or legitimately interested in a project.

Voice of the Customer (VOC): Explicit and implicit customer needs, expectations, and experiences.

Weighted screening score: Priority score calculated by combining criterion weights and ratings.

Scope: Defined boundaries of the process, population, geography, time, and outcomes addressed.

Review Questions

Short Answer Questions

  1. What is the principal purpose of the Define phase in DMAIC?
  2. Distinguish a problem statement from a solution statement.
  3. What information should a goal statement contain?
  4. Explain the purpose of SIPOC in early project framing.
  5. Why are guardrail metrics included in a project goal?

Long Answer Questions

  1. Explain how a business case should connect process performance to customer, operational, financial, and risk consequences.
  2. Describe the major components of a project charter and explain how each supports governance.
  3. Critically evaluate the advantages and limitations of weighted project-selection scoring.
  4. Explain how stakeholder analysis and communication planning influence the validity and adoption of a Six Sigma project.
  5. Discuss ethical, privacy, compliance, and equity considerations that should be addressed during Define.

Analytical / Application Questions

  1. A manager proposes the project title “Automate invoice processing.” Reframe it as a problem statement, a measurable goal statement, and a preliminary scope statement without assuming automation is the solution.
  2. A service process reports a 20% reduction in average cycle time, but customer complaints and rework have increased. Design a revised goal with suitable guardrail metrics and explain your reasoning.
  3. Using a SIPOC perspective, define the likely suppliers, inputs, process stages, outputs, customers, stakeholders, and risks for a university student-admissions process. Identify two possible scope boundaries and justify one of them.

Multiple Choice Questions with Answers

Question 1

Which statement best describes an appropriate Six Sigma problem statement?

A. Implement an automated claims workflow immediately.

B. The claims system is inefficient and needs improvement.

C. Between January and June, 18.4% of complete claims exceeded the five-day requirement, generating additional enquiries.

D. Train all claims staff in advanced software skills.

Correct Answer: C. Between January and June, 18.4% of complete claims exceeded the five-day requirement, generating additional enquiries.

Question 2

What is the primary purpose of a goal statement?

A. To prescribe the technology that will be purchased

B. To specify the measurable intended improvement and its time frame

C. To identify the individual employee responsible for defects

D. To replace the need for a business case

Correct Answer: B. To specify the measurable intended improvement and its time frame

Question 3

In SIPOC, which element identifies the recipients or users of process outputs?

A. Suppliers

B. Inputs

C. Outputs

D. Customers

Correct Answer: D. Customers

Question 4

Which item is an example of a guardrail metric?

A. A target reduction in processing time accompanied by monitoring of payment errors

B. A preferred software vendor

C. The project team’s meeting schedule

D. A list of excluded geographic locations

Correct Answer: A. A target reduction in processing time accompanied by monitoring of payment errors

Question 5

If a weighted screening model uses weights that must sum to 1, which expression represents the score?

A. S = ∑(wᵢrᵢ)

B. S = ∑(wᵢ + rᵢ)

C. S = ∏(wᵢrᵢ)

D. S = ∑(rᵢ ÷ wᵢ)

Correct Answer: A. S = ∑(wᵢrᵢ)

Question 6

Which role is primarily accountable for the process after the project is completed?

A. Process owner

B. External customer only

C. Data analyst

D. Meeting facilitator

Correct Answer: A. Process owner

Question 7

Why should a high-level process map be treated as a hypothesis during Define?

A. It is never useful for identifying boundaries.

B. It represents an initial understanding that must be validated with observation and data.

C. It can only be created after statistical analysis.

D. It describes financial benefits rather than process activity.

Correct Answer: B. It represents an initial understanding that must be validated with observation and data.

Question 8

Which practice most directly reduces the risk of solution bias?

A. Naming the preferred technology in the problem statement

B. Defining the performance gap without asserting an unverified cause

C. Excluding frontline employees from project discussions

D. Using only financial measures

Correct Answer: B. Defining the performance gap without asserting an unverified cause

Question 9

A project estimates annual benefit as reduction in defects per transaction × cost per defect × annual transactions. What unit should the result have if the inputs are consistent?

A. Currency per year

B. Transactions per currency

C. Defects per transaction squared

D. Days per defect

Correct Answer: A. Currency per year

Question 10

Which stakeholder group generally requires close engagement in an influence–impact matrix?

A. Low influence and low impact

B. High influence and high impact

C. High influence and no legitimate interest

D. Stakeholders who are entirely outside the process

Correct Answer: B. High influence and high impact

Six Sigma Methodology
Chapter 4 of 15