5.9 SMART Goals and Project Performance Measurements

ASQ Certified Six Sigma Black Belt CSSBB

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & CSSBB Exam Strategy

1.1 CSSBB Exam Format, Scoring, and Testing Windows 1.2 Eligibility, Project Affidavits, Application, and Recertification 1.3 Open-Book Strategy, Reference Materials, and a 16-Week Study Plan

2 Chapter 2: Organization-Wide Planning and Deployment

2.1 Fundamentals of Six Sigma and Lean Methodologies 2.2 Selecting the Right Methodology: DMAIC, DFSS, and Lean 2.3 Business Systems, Processes, and Stakeholder Relationships 2.4 Strategic Planning and Deployment of Six Sigma Initiatives 2.5 Six Sigma Roles and Responsibilities 2.6 Organizational Barriers and Common Causes of Six Sigma Failure 2.7 Change Management: Stakeholder Analysis, Readiness, and Communication

3 Chapter 3: Organizational Process Management and Measures

3.1 Impact of Six Sigma Projects on Customers, Suppliers, and Stakeholders 3.2 Benchmarking Types and Performance Goal Setting 3.3 Performance Measures: Balanced Scorecard, KPIs, KBIs, OKRs, and Line of Sight 3.4 Leading and Lagging Indicators and Performance Dashboards 3.5 Financial Measures: Revenue Growth, Margin, NPV, ROI, and Cost-Benefit Analysis 3.6 Cost of Poor Quality and Hard versus Soft Savings

4 Chapter 4: Team Management

4.1 Team Types and Constraints 4.2 Team Roles, Responsibilities, and Member Selection 4.3 Team Success Factors and Ground Rules 4.4 Motivational Techniques and Overcoming Demotivators 4.5 Stages of Team Development and Conflict Resolution 4.6 Team Communication Plans 4.7 Team Leadership Models: Direct, Coach, Support, and Delegate 4.8 Group Behaviors, Conflict Resolution, and Meeting Management 4.9 Facilitation Techniques and Team Decision-Making Methods 4.10 Team Training: Needs Assessment, Delivery, and Evaluation

5 Chapter 5: Define Phase

5.1 Customer Identification and Segmentation 5.2 Customer Data Collection: Methods, Validity, and Reliability 5.3 Customer Requirements: CTX, CTQ Trees, and Operational Definitions 5.4 The Kano Model and Quality Function Deployment 5.5 SIPOC and Process Mapping 5.6 Business Case Justification 5.7 The Project Charter and the Problem Statement 5.8 Project Scope and Boundaries 5.9 SMART Goals and Project Performance Measurements 5.10 Project Charter Reviews and Toll-Gate Governance 5.11 Project Management Tools: Gantt Charts, Toll-Gate Reviews, WBS, and RACI 5.12 Analytical Tools Used Throughout the DMAIC Cycle

6 Chapter 6: Measure Phase

6.1 Process Flow Metrics and the Hidden Factory 6.2 Process Analysis Tools and Value Stream Mapping 6.3 Types of Data and Measurement Scales 6.4 Sampling Concepts, Methods, and Sample Size for Estimation 6.5 Data Collection Plans and Common Pitfalls 6.6 Gage R&R for Variable Measurement Systems 6.7 Attribute Agreement Analysis and Audit MSA 6.8 Measurement Systems Across the Organization, and Metrology 6.9 Population Parameters, Sample Statistics, and Valid Statistical Conclusions 6.10 Descriptive Statistics: Central Tendency, Dispersion, and Shape 6.11 Graphical Methods for Exploratory Data Analysis 6.12 Probability Concepts, Common Distributions, and the Central Limit Theorem 6.13 Additional Distributions: Hypergeometric, Exponential, Lognormal, Weibull, and Bivariate 6.14 Process Capability and Performance Indices 6.15 Capability Studies, Attributes Capability, Yield Metrics, and Long-Term Capability

7 Chapter 7: Analyze Phase

7.1 The Correlation Coefficient, Its Confidence Interval, and Causation 7.2 Linear Regression and Residual Analysis 7.3 Multivariate Tools: Factor Analysis, Discriminant Analysis, and MANOVA 7.4 Hypothesis Testing Terminology, Errors, and Single-Sample Tests 7.5 Statistical Versus Practical Significance 7.6 Sample Size for Hypothesis Tests 7.7 Point Estimates, Confidence, Prediction, and Tolerance Intervals 7.8 Tests for Means, Variances, and Proportions 7.9 Analysis of Variance 7.10 Chi-Square Goodness-of-Fit and Tests of Independence 7.11 Types of Risk and Failure Mode and Effects Analysis 7.12 Gap Analysis and Root Cause Analysis 7.13 Waste Analysis: The Seven Classic Wastes and Resource Under-Utilization

8 Chapter 8: Improve Phase

8.1 Design of Experiments: Objectives, Terminology, and Effects 8.2 DOE Design Principles: Randomization, Blocking, Replication, and Resolution 8.3 Planning and Evaluating Designed Experiments 8.4 One-Factor Experiments: Completely Randomized, Randomized Block, and Latin Square Designs 8.5 Full Factorial Experiments and Design Selection 8.6 Two-Level Fractional Factorial Experiments and Confounding 8.7 Response Surface Methodology and Optimization 8.8 Waste Elimination: Pull Systems, Kanban, 5S, and Poka-Yoke 8.9 Cycle-Time Reduction: Continuous Flow, SMED, and Heijunka 8.10 Kaizen, Kaizen Blitz, Theory of Constraints, and OEE 8.11 Implementation Planning, Piloting, and Solution Selection

9 Chapter 9: Control Phase

9.1 SPC Objectives, Variable Selection, and Rational Subgrouping 9.2 Control Charts for Variables Data 9.3 Control Charts for Attributes Data 9.4 Short-Run SPC and Moving Average Charts 9.5 Control Chart Analysis: Common Cause, Special Cause, and Run Rules 9.6 Total Productive Maintenance and Visual Controls 9.7 Measurement System Reanalysis 9.8 Control Plan Development and Process Owner Handoff 9.9 Lessons Learned, Documentation, and Training for Sustainment 9.10 Ongoing Evaluation of the Improved Process

10 Chapter 10: Design for Six Sigma (DFSS)

10.1 DFSS Frameworks: DMADV, DMADOV, and Design Transfer 10.2 Design for X (DFX) 10.3 Robust Design, Parameter Design, and Verification 10.4 Tolerance Design and Statistical Tolerancing

5.9 SMART Goals and Project Performance Measurements

Key Takeaways Explain This Topic AI

SMART goals are specific, measurable, actionable, relevant, and time-bound, and each element removes a specific class of ambiguity.

A project needs one primary metric; multiple primary metrics mean the team has not decided what the project is about.

Consequential metrics guard against improving the primary metric by degrading something else.

The performance measurement categories named in the Body of Knowledge are cost, revenue, delivery, schedule, and customer satisfaction.

Every project metric needs an operational definition: what is measured, by whom, with what instrument, at what frequency, and what counts as a defect.

Last updated: August 2026

SMART, element by element

Element Test What it removes
Specific Does it name the process, the output, and the population? "Improve quality" ambiguity

Measurable Is there a metric with an operational definition and an existing data source? Untestable claims of success

Actionable Can this team, within its scope and authority, cause the change? Goals that depend on decisions the team cannot make

Relevant Does it connect to the business case and a strategic objective? Locally interesting, organizationally pointless work

Time-bound Is there a completion date and a measurement window? Projects that never finish

Note that ASQ's spelling of the acronym uses actionable rather than the more common "achievable".

The distinction is meaningful: actionable asks whether the team has the levers, which is a scope and

authority question, not an optimism question.

Applying the test to a real goal:

"Reduce the error rate on first-submission invoices for the North America commercial segment from
4.7% (baseline: 18,400 invoices, January to June) to 1.5% by 30 November 2026, measured on the same
extract and definition."
Specific: process (first-submission invoicing), population (North America commercial), output

(error rate).

Measurable: 4.7% to 1.5%, with a stated baseline and sample.

Actionable: invoicing is inside the project's scope and the process owner is on the team.

Relevant: linked to the days-sales-outstanding objective in the business case.

Time-bound: 30 November, measured on the same extract and definition.

The final clause -- same extract and definition -- is what prevents the most common closure dispute,

where the improvement turns out to be a change in how the metric was computed.

Deriving the goal from the problem statement

The goal is not a separate act of ambition; it is the problem statement plus a target and a date.

Problem statement element Goal element
What is wrong, and to whom Specific
How big, measured how Measurable, with the baseline
Where and when it occurs Population and boundary
(Not present) Target value
(Not present) Completion date

If a goal introduces a metric that the problem statement never measured, one of the two is wrong.

Setting the target value should be justified rather than asserted. Legitimate bases: an entitlement
calculation from best observed performance, a benchmark gap with a stated closure fraction, a customer
requirement or specification, or a strategic target cascaded from the operating plan. "A 50%

improvement" with no basis is a guess that will be renegotiated later.

The project metric set

Metric role Purpose How many
Primary The one measure that defines project success Exactly one
Secondary Supporting measures that explain or decompose the primary Two to four
Consequential Measures that must not degrade while the primary improves One to three
Financial The benefit translation, agreed with finance One
One primary metric
A project with three primary metrics has not decided what it is about, and it will trade them against
each other silently. Choose the one the customer or the business case actually cares about; the others

become secondary.

Consequential metrics are not optional
Every improvement can be faked by degrading something unmeasured. The consequential metric is the

guard.

Primary metric Plausible cheat Consequential metric
Reduce cycle time Skip verification steps Escaping defect rate
Reduce cost per unit Buy cheaper input material Scrap rate; warranty claims
Increase throughput Run marginal conditions without stopping First-pass yield
Reduce inventory Under-buy and stock out On-time in-full delivery
Reduce headcount in inspection Push detection to the customer Customer complaints
Performance measurement categories

The Body of Knowledge names five categories that connect critical process elements to key outputs.

Category Typical measures Data source
Cost Cost per unit, scrap and rework cost, cost of poor quality, overtime Cost accounting, ERP
Revenue Revenue per customer, share of wallet, revenue lost to stockouts Sales systems
Delivery On-time in-full, fill rate, lead time, delivery variability Transportation or order management system
Schedule Adherence to plan, changeover time, capacity utilization MES, planning system
Customer satisfaction NPS, complaint rate, return rate, escalations CRM, survey, warranty

Two rules for selecting from them:

Prefer a measure that already exists over one you must create, provided its operational

definition survives scrutiny. A new metric costs weeks and has no baseline.

Prefer a measure close to the process for the project's working metric, and translate to the
business measure for reporting. A team cannot steer on quarterly revenue, but it can steer on

mis-picks per thousand lines, which drives it.

Operational definitions

Every metric needs an operational definition before any data is collected. It answers:

What exactly is measured? Which field, which event, which characteristic.

What counts as a defect or an occurrence? Written decision rules for the borderline cases.

Who measures it? Named role.

With what instrument or query? Named gauge, or the exact system extract.

At what frequency and sample size?

How is it recorded, and where?

A metric without an operational definition produces disagreement disguised as data. The standard test:

two different people, working independently from the definition alone, must classify the same
transactions identically. If they do not, the definition is not finished -- and this is precisely what

attribute agreement analysis measures in the Measure phase.

Discrete versus continuous choice
Where a choice exists, prefer a continuous metric over a discrete one. Continuous data gives
far more information per observation, so it requires much smaller samples to detect a change, and it

shows how far off you are rather than merely whether you failed.

Discrete: "shipment was late (yes/no)" -- needs hundreds of observations to detect a modest shift.

Continuous: "hours early or late relative to promise" -- a few dozen observations reveal both the

centring and the spread, and the specification limit can be applied afterwards.

Converting a continuous measurement into a pass/fail count throws away information you already paid to

collect.