5.5 The CSSC Define Toolset: Ground Rules, In/Out of the Box, Is–Is Not & Tollgate Checklists

5.5 The CSSC Define Toolset: Ground Rules, In/Out of the Box, Is–Is Not & Tollgate Checklists

Quick Summary: The CSSC manual treats "the Define toolset" as a named list, not a vague category. Beyond SIPOC, the 5 Whys, process maps, value stream maps, and run charts covered elsewhere, Chapter 12 adds three specific tools — Stakeholder Analysis, the In and Out of the Box Method, and the Is/Is Not Matrix — and prefaces them with project ground rules. Chapter 12 also closes with the Define tollgate checklist, the first of five gate lists that recur at the end of Chapters 12–16. Those checklists are the Council's operational definition of "phase complete," and they are highly quotable exam material.

---

Project Ground Rules

Before any work begins — even before defining a team charter — a Six Sigma team should establish basic rules and requirements for itself.

The documentation rule. Ground rules should be maintained in writing and approved by all team members, though they need not be part of the official charter document. CSSC gives one crisp reason: so that a single team member cannot later claim to be ignorant of the rules. That is the sentence to remember; exam items frequently ask why ground rules are documented, and "so no member can plead ignorance" is the published answer, not "because auditors require it."

Rule generation is deliberately not fully democratic. This is the part candidates get wrong. The split is:

Seeking team input on scheduling matters because it ensures members can actually commit to the time slots. For consistency it is best to hold meetings on the same day and time each week, though CSSC acknowledges that is hard to sustain across the full life of some projects. The Black Belt may delegate meeting functions such as time keeper and secretary while still owning the agenda rules.

---

Tool 1: Stakeholder Analysis

The stakeholder analysis is a quick way to identify how various people relate to a project and how the team should keep them informed. Draw a grid over x and y axes:

• Vertical axis = power the person holds in the organization.
• Horizontal axis = interest the person has in the team's project.

   High │  Keep Satisfied          │  KEY PLAYERS
 Power  │  (high power,            │  (high power, high interest)
        │   low interest)          │  Process key players and
        │                          │  executives who can assign
        │                          │  resources; these are the
        │                          │  people the team reports to
        │                          │  at tollgates
        ├──────────────────────────┼──────────────────────────────
   Low  │  Minimal Effort          │  Keep Informed
 Power  │  (low power,             │  (low power, high interest)
        │   low interest)          │  Frontline operators
        └──────────────────────────┴──────────────────────────────
              Low Interest                 High Interest

CSSC singles out the top-right quadrant: these are either key players regarding the process or executive leaders with the ability to assign resources. These are the individuals teams report to at various tollgates, and often the executives ultimately responsible for the success of the process or project.

---

Tool 2: The In and Out of the Box Method

A quick, physical scoping exercise. The procedure:

1. Draw a large box on a whiteboard or flip chart; provide markers and sticky notes.
2. Ask the team to write down elements of the process — resources, activities, and people — one item per sticky note.
3. Build as complete a list as possible, placing notes on a wall or table as you go. Make sure everyone understands there are no wrong answers and that this first phase requires no discussion. Brainstorming without debate captures more ideas and yields a more accurate picture of what is in and out of scope.
4. Once the list is comprehensive, assign each item to a position inside, on the line, or outside the box.
5. Review placements as a team and adjust.
6. Document the exercise by photographing the diagram or recreating it on a computer.

The documented diagram is not disposable — the team reflects back on it when controlling scope creep or deciding who to approach for help.

---

Tool 3: The Is/Is Not Matrix

Another quick brainstorming tool for defining scope, which also helps define information necessary to the problem statement. It works by asking specific questions about the process or project and producing both an is and an is not answer.

CSSC's worked example: a team is asked why the furnaces in a certain factory are not heating to proper temperatures.

Read the payoff: the matrix shows the project's scope covers only the south plant, only the steam furnaces, and that the problem was first noted in January 2015 — which hands the team a starting point for gathering data. That is a very simple matrix; teams may ask as many questions as they like to narrow scope or better understand the project through the Is/Is Not structure.

[!TIP] Distinguishing the two scoping tools on the exam. In/Out of the Box scopes by element (which resources, activities, and people are we touching?). Is/Is Not scopes by dimension (where, what, when — and the boundaries in each). If a stem emphasizes sticky notes, brainstorming without discussion, or items needing outside permission, it is In/Out of the Box. If it emphasizes paired contrasts or a starting date for data collection, it is Is/Is Not.

---

The Five DMAIC Tollgate Checklists

Each of Chapters 12–16 closes with a checklist. A tollgate is a formal gate review; the team presents to the key players from the top-right stakeholder quadrant and does not proceed until the deliverables exist.

Define Tollgate — a successful Define phase ends with all of:

• A comprehensive project statement
• A team charter
• An understanding of the process and a project diagram or map
• An understanding of the Voice of the Customer
• A definition of what success will look like, agreed on by the team members and any sponsors or executive leaders

Measure Tollgate — ready to move to Analyze when:

• Key measurements are agreed and a baseline measurement of process performance exists
• Measurement systems have been analyzed and any error-contributing issues identified
• Where possible, measurement systems have been corrected to remove error risks
• Process variation and sigma level have been calculated
• Appropriate sampling has been conducted to allow statistically valid conclusions in the next phase
• The sponsor or champion has reviewed and signed off on all elements of the Measure phase

Analyze Tollgate:

• Primary root causes have been identified
• The team has prioritized root causes
• The champion or sponsor agrees with the team's priorities moving into Improve
• Where possible, root cause assumptions are backed by statistical data
• Relationships between variables within the process are understood
• Where possible, variable relationships have been confirmed with statistical analysis

Improve Tollgate:

• Solutions were reviewed and prioritized
• One or two top solutions were selected for action
• Solutions were implemented on a limited basis
• Data from limited trials was analyzed and solutions appear to work as expected
• Cost-benefit analysis was performed
• Sponsor, champion, or executive steering committee signed off on implementing the solution completely
• All team members agree the solution should be implemented
• The solution is fully documented through SOPs and training materials
• Critical staff received training and are prepared to pass that training on to others

Control Tollgate:

• The team has calculated the performance and capability of the new process
• The team has written a control plan and communicated it to the process owner
• The team has created a monitor for the process — manual data collection procedures or automated control chart generation
• The process owner and business team have been given all tools and information required to maintain improvements
• The sponsor, champion, or executive leadership has been informed about the state of the improvements
• The team met to reflect on the project and generate a list of ideas for future improvements

---

Realistic Exam Scenario

A Green Belt leading a purchase-order accuracy project reaches the Analyze tollgate. The team has a ranked fishbone with three candidate root causes and a champion who agrees with the ranking, but only one cause has supporting data — the other two rest on operator interviews.

Is the gate passable? Read the checklist wording carefully. Two items are qualified by "where possible": root cause assumptions backed by statistical data, and variable relationships confirmed with statistical analysis. The other four are unqualified. So the gate turns on whether statistical backing was possible and skipped, or genuinely unavailable. If the data exists and the team simply did not run the analysis, the gate fails. If two causes are behavioural and no data can be collected without a new measurement system, the team can pass while documenting why — and the honest place to record that reasoning is the Root Cause Verification Matrix.

---

Common Exam Traps

• Trap 1: Making ground rules fully democratic. The team votes on meeting frequency and timing. The Black Belt sets confidentiality, attendance, punctuality, respect, and agenda rules.
• Trap 2: Putting ground rules inside the charter. They do not have to be part of the official charter document — but they must be written and approved.
• Trap 3: Reading "on the line" as out of scope. On the line means undecided pending permission or assistance from outside the team.
• Trap 4: Reversing the stakeholder axes. Vertical is power; horizontal is interest.
• Trap 5: Ignoring the "where possible" qualifiers. Only the Analyze tollgate's two statistical items carry that hedge. Every Measure tollgate item except the measurement-system correction is unconditional.
• Trap 6: Rolling out the full solution at the Improve tollgate. The Improve gate requires implementation on a limited basis with trial data analyzed, plus sign-off before full implementation.