ExamFinch.com My Study

Study guide

4.1 Team Types and Constraints

Practice this exam

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

4.1 Team Types and Constraints

Key Takeaways Explain This Topic AI

The three team types named in the ASQ Body of Knowledge are virtual, cross-functional, and self-directed.

Cross-functional teams are the default for DMAIC because value streams cross departmental boundaries that no single manager controls.

Virtual teams need explicit decision rules and asynchronous documentation because informal corridor coordination is unavailable.

A time-zone spread beyond about six hours removes the shared working window and forces asynchronous working agreements.

Self-directed teams suit stable, well-understood processes with a mature workforce, not exploratory analytical projects.

Last updated: August 2026

Team types named in the Body of Knowledge

Type Definition Best suited to Principal risk

Cross-functional Members drawn from multiple functions, each contributing domain expertise, led by a project leader DMAIC projects spanning a value stream Competing functional priorities and split loyalty

Virtual Members distributed across sites, countries, or time zones, collaborating primarily through technology Multi-site processes, scarce specialist expertise Weak informal communication, slow decisions, low trust

Self-directed Team manages its own work, scheduling, and often quality decisions without a designated supervisor Stable, well-understood processes; sustaining improvement after handover Requires mature skills and clear boundaries; poor fit for exploratory work

A real Six Sigma team is often two of these at once. A defect-reduction project across three plants is

cross-functional and virtual, and it inherits the risks of both.

Choosing against constraints

The Body of Knowledge names four constraint classes explicitly. Work through them in order.

  • Geography
  • Co-located teams coordinate for free: the corridor conversation, the shared whiteboard, and the walk
  • to the gemba all happen without scheduling. Distribute the team and every one of those becomes a

calendar event.

Single site : co-located cross-functional team; daily 15-minute stand-up at the process.

Two to three sites, same region : cross-functional core at the lead site, with named site

representatives and a monthly in-person working session.

Global : virtual team with a documented working agreement, a single shared repository, and a

rotating meeting time so the same region is not always inconvenienced.

  • One rule holds regardless: the Measure phase needs someone physically at the process . Data
  • collected by a remote analyst from a system extract, without anyone watching the process run, is the

most reliable way to build an accurate model of a process that does not exist.

  • Technology availability
  • Team design must match the tools actually available to every member, not the tools available at
  • headquarters. Plant-floor members may have shared kiosks rather than personal computers; contract
  • manufacturers may be outside your network entirely; regulated environments may prohibit external file
  • sharing. If a member cannot reach the shared repository, they are not on the team no matter what the
  • charter says. Check before you design: video conferencing, shared document editing, statistical

software licences, access to the MES or ERP data, and permission to move data across borders.

  • Staff schedules
  • A three-shift process cannot be represented by a team that meets at 10 a.m. on weekdays. Practical

countermeasures:

Rotate the meeting time across shifts, or hold a short handover briefing at each shift change.

Recruit a shift representative from every shift rather than only the day shift, because

shift-to-shift differences are frequently the dominant source of variation.

Budget backfill. A team member cannot leave a running line unattended for a two-hour workshop.

Time zones

Overlap window is the binding constraint:

  • Spread Shared working window Working mode
  • 0-3 hours 5+ hours Treat as co-located; synchronous meetings work
  • 4-6 hours 2-3 hours Reserve the overlap for decisions only; do analysis asynchronously
  • 7+ hours Effectively none Fully asynchronous; decisions by documented proposal with a response deadline
  • For spreads beyond six hours, adopt a follow-the-sun handover : each region ends its day by posting

what changed, what is blocked, and what the next region should decide.

  • Working agreements for virtual teams
  • Virtual teams fail on ambiguity, not on distance. A short written working agreement removes most of

it:

Decision rule. Which decisions the team may take alone, which need the sponsor, and what

happens if a member does not respond within the deadline.

Response time expectation. For example, 24 working hours for a posted proposal.

Single source of truth. One repository for data, charter, and analysis; no decisions in chat.

Camera and language norms. Non-native speakers need agenda and materials in advance.

Meeting hygiene. Agenda circulated ahead, pre-work stated, notes and actions posted the same

day.

  • Self-directed teams and the handover
  • Self-directed teams matter most at the end of a project. A control plan handed to a supervised
  • team that has no authority to adjust the process will be followed until the first conflict with
  • output targets. A self-directed team with defined boundaries -- adjust within these limits, escalate
  • outside them -- sustains the gain because it can act. Self-direction requires three conditions: the
  • members have the technical skill, the boundaries are written down, and the reward system does not

punish stopping the line.

  • Worked example
  • A packaging defect project spans two plants seven time zones apart, involves quality, maintenance,

and a contract label supplier, and runs across three shifts.

  • The correct structure is a cross-functional virtual team with: a co-located core at the plant
  • carrying the majority of the defects; a named shift representative at each site; the supplier
  • included as a member rather than consulted as a vendor; a two-hour weekly overlap window reserved for
  • decisions; asynchronous data posting between sessions; and an explicit rule that Measure-phase

observation happens locally at each site rather than from system extracts alone.