5.8 Project Scope and Boundaries

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.8 Project Scope and Boundaries

Key Takeaways Explain This Topic AI

Scope has four dimensions: process boundaries, organizational boundaries, output or product boundaries, and time boundaries.

The in-frame / out-of-frame tool records what is explicitly excluded, which is what makes scope enforceable.

A project scoped too widely stalls in Measure; a project scoped too narrowly cannot reach the root cause because it lies upstream.

Scope changes are legitimate but must be approved by the sponsor as a formal change with a revised timeline and benefit.

A useful heuristic is that a DMAIC project should be deliverable within four to six months by one Black Belt.

Last updated: August 2026

Four dimensions of scope

Dimension Question Artifact

Process Which step starts the project's process, and which step ends it? SIPOC with explicit start and stop events

Organizational Which departments, sites, shifts, and lines are included? Named list in the charter
Output Which products, services, SKUs, or customer segments? Named list with volumes

Time Which period of historical data, and over what horizon will improvement be measured? Baseline period and measurement window

Every one of the four must be written down. A charter that names the process but not the sites will

grow to include the other sites by the fourth week.

Start and stop events
The single most useful discipline is defining the process boundary as observable events , not

department names.

Weak: "the order process".

Strong: "starts when a customer purchase order is received in the order management system; ends when
the shipment confirmation is transmitted to the customer."
Observable events do three things: they define exactly which transactions belong in the data set, they
determine what the cycle-time clock measures, and they settle arguments about whether a defect belongs

to this project.

In-frame and out-of-frame
Scope is only enforceable if the exclusions are written down. The in-frame / out-of-frame tool

(sometimes drawn as a rectangle with items inside and outside) forces the team to state both.

In frame Out of frame
Plant 2 moulding lines 3 and 4 Plant 1 and plant 3
Black and grey resin grades Custom colour grades (under 2% of volume)
Defects detected at end-of-line inspection Field returns
First and second shift Weekend shift (starting after the project window)
Process changes within existing equipment New capital equipment above $75,000
Notice that the out-of-frame column carries reasons. "Custom colour grades, under 2% of volume" is a

decision; "custom colour grades" alone is an omission somebody will challenge.

The two failure modes
Scoped too wide
Symptoms: the Measure phase runs for months, the data set has too many strata to analyze, the team
cannot name a single process owner, and the toll gate keeps slipping. Cause: the team scoped the
problem statement rather than the project -- "reduce customer complaints" instead of "reduce

mis-shipment complaints on the West distribution centre's pick-and-pack process".

Remedy: decompose with a Pareto , then take one slice. A Pareto of complaint categories, a Pareto by

site, or a project tree that breaks a business-level goal into process-level projects will all work.

Charter the largest slice and keep the rest as a documented follow-on portfolio, which also protects

the team from the accusation that they ignored the remainder.

Scoped too narrow
Symptoms: the team confirms a root cause but cannot act on it because the cause lies outside the
boundary; the improvement moves the problem to the adjacent step; the benefit is too small to justify a

Black Belt.

Remedy: extend the boundary upstream to include the process that creates the condition, and get the
sponsor changed if that crosses into another function. This is the case where a scope change is clearly

correct.

Testing that scope has customer value
The Body of Knowledge specifically asks that boundaries be reviewed to ensure the project has value

to the customer . Three tests:

Does the scoped process produce something a customer receives or depends on? A project scoped
entirely inside an internal reporting activity may improve efficiency without improving anything the

customer experiences.

Is the primary metric a customer-facing characteristic or a proxy? Reducing internal

inspection hours is a cost measure; reducing escaping defects is a customer measure.

Would the customer notice the target improvement? Moving a lead time from 11.0 to 10.6 days is

inside the customer's noise band; moving 11 days to 4 days changes their behaviour.

Managing scope change

Scope changes are not failures; unmanaged scope changes are. Treat any change as a formal request:

Field Content
What changes Add weekend shift to the organizational boundary
Why Stratified data shows weekend defect rate is 3.4 times weekday
Impact on timeline Measure phase extends by 3 weeks
Impact on benefit Estimated benefit increases from $180k to $240k
Impact on resources Requires 20 additional SME hours
Approved by Sponsor, date
The reason to formalize it is that the sponsor approved a specific commitment. Silent expansion means

the project is later judged against a promise the team never actually made and cannot meet.

Sizing heuristics
One Black Belt, four to six months , is the standard target size. A project that cannot plausibly

finish in that window should be decomposed.

The scoped process should have one identifiable process owner who can implement the change.

The baseline should contain enough events to analyze : as a rule of thumb, at least 30 defect
occurrences or 100 continuous observations in the baseline period, otherwise the Measure phase must

be extended or the boundary widened.

The estimated benefit should exceed the deployment's threshold with the scope as written, not with

optimistic extrapolation to sites outside the frame.