✓ Free · MIT License IS/IS-NOT Scoping SMART

Problem Statement Builder

The most expensive mistake in continuous improvement is solving the wrong problem. This skill scopes the problem correctly before any analysis begins: IS/IS-NOT analysis, SMART output format, and a check against the four common traps.

⬇ Download Skill How it works ↓

The IS/IS-NOT Framework

What the problem IS, and what it is NOT

Every problem statement has two sides of equal weight. The IS column describes what you are observing. The IS-NOT column eliminates hypotheses and prevents scope creep. It tells you where to stop looking. A team that knows the problem only happens on the night shift, only at Station 4, and only started three weeks ago has already ruled out half the root-cause list before opening a fishbone diagram.

Dimension	IS: What we observe	IS NOT: What we can rule out
Object	Which product, part, patient, or process step is affected	Similar products, adjacent steps, or other product families where the problem does not appear
Location	Which line, machine, cell, unit, or geography shows the defect	Other lines, machines, or geographies running the same product without the problem
Time	When did it start? Which shift, day of week, or time of day does it appear?	Periods, shifts, or days where it is absent, and what changed around the start date
Magnitude	How many defects, how often, how large is the gap from expected performance?	What the problem is NOT doing: it has not spread to other shifts, it is not worsening week-over-week

A good problem statement has three parts

What is happening: a measurable deviation from a standard or expected condition
Where and when: location, process step, shift, time window
How big is the gap: actual performance versus expected, with units

Output Format

SMART: the output the skill produces

The skill formats the final problem statement against five criteria before handing it to any root-cause tool. A statement that fails one of these gets sent back for revision, not forwarded to a fishbone with a soft scope.

Specific

Names the exact object, location, and step. Not "quality is bad." It names which characteristic on which part at which station.

Measurable

States the gap in numbers with units: 8% out-of-spec vs. 1% expected. No numbers, no problem statement.

Actionable

Within the team's scope to investigate. If the root cause is entirely outside the team's control, escalate before analyzing.

Relevant

Ties to a customer, quality, cost, or safety impact that justifies the investigation. Scope creep starts when the "problem" isn't worth solving.

Time-bound

States when the problem started, or over what period the baseline was measured. "Started three weeks ago" is a clue; "always been this way" is a different problem.

Common Traps

Four ways teams write the wrong problem statement

Stating a solution as a problem

"We need more training" is a solution, not a problem. The problem is the gap: "Operator error rate at Station 4 is 6%, vs. 1% target." The solution may or may not be training. That's what root cause determines.

Stating a cause as a problem

"Operator error" is a cause, not a problem. Which operators, which errors, which product, how often, compared to what baseline? Naming a cause in the problem statement locks out every other hypothesis before the investigation begins.

Too broad to investigate

"Quality is bad" has no IS-NOT column. Nothing is ruled out. Every possible cause is still open. A team that starts root cause from this statement is doing brainstorming, not investigation.

One data point treated as a pattern

A single bad batch, a single complaint, or a single bad shift is not a problem statement. It's a trigger to go look. The skill flags n=1 and asks for trend data, run rate, and baseline before the statement is finalized.

How It Works

Describe what you saw. Get a scoped problem statement.

Describe what you observed

Plain language is fine. "We've been seeing more rejects on Line 3 since last month" is enough to start. The skill asks clarifying questions rather than guessing missing dimensions.

The skill builds the IS/IS-NOT table

Each of the four dimensions (Object, Location, Time, Magnitude) is filled from what you provided. Anything missing gets an explicit question before the table is finalized, not a placeholder.

Four-trap check runs automatically

The draft statement is checked: is it a solution? a cause? too broad? n=1? Any trap that fires sends the statement back with a specific correction rather than passing it through.

SMART format applied

The finalized statement is written in SMART format with source citations for every number. It is ready to paste into a kaizen charter, A3, or root-cause session without revision.

Hand off to root cause

The output includes a summary of what the IS-NOT column has already ruled out, so the root-cause tool starts with a shorter hypothesis list, not a blank fishbone.

Examples

Manufacturing and healthcare both supported

🏭 Manufacturing

🏥 Healthcare

A machined part out-of-spec rate scoped with IS/IS-NOT. The problem started three weeks ago, appears only on the day shift, only at Station 4, and only on the 12 mm bore diameter, not the 8 mm bore on the same part.

Finalized problem statement: machined bore OD

The out-of-spec rate for the 12 mm bore diameter at Station 4 (CNC Cell B) is 8% over the past three weeks, versus the 1% baseline from the prior six months. The defect has not appeared at Station 5 (identical operation, different machine) or on the 8 mm bore on the same part. It is present on both operators who run Station 4 but was not present on either operator before the three-week window. Data source: CMM inspection log, 312 inspections over three weeks.

Dimension	IS	IS NOT
Object	12 mm bore, Part #4471	8 mm bore (same part), Part #4470
Location	Station 4, CNC Cell B	Station 5 (identical operation)
Time	Started ~3 weeks ago; all shifts	Prior 6 months (1% baseline)
Magnitude	8% OOS rate (25/312 parts)	Not worsening week-over-week

A medication near-miss rate scoped to a specific unit, a specific time window, and a specific drug class. The IS-NOT column rules out the pharmacy, the night shift, and other drug classes, narrowing root cause before the team convenes.

Finalized problem statement: medication near-miss rate

Medication near-miss events involving high-alert oral medications on 4 West are occurring at 3.2 per 1,000 doses administered over the past six weeks, versus the 0.8 per 1,000 baseline from the prior quarter. Events are concentrated in the 6:00–10:00 AM administration window and involve two specific drug classes (anticoagulants and insulin). Events have not increased on other units using the same pharmacy and the same medications, and have not increased during the PM administration window on 4 West. Data source: incident reporting system, verified against eMAR.

What you get

A real run on the sample data

Unedited output. The sample message at the top went to Claude Sonnet 4.6 (an earlier-generation model, so a newer one may word things differently) with this skill pasted in, the same way the steps below show, on September 29, 2026. Scroll inside the frame to read the whole reply.

Open the full image

Installation

Paste it in, describe what you observed

Copy the skill. Open problem-statement.md, select all the text and copy it.

Paste it into Claude. In claude.ai, start a new chat and paste it as your first message, or paste it into a Project's instructions so it's there every time. The free plan works, and free accounts can keep up to five Projects.

Say what's in front of you, in your own words, with any data you have (leave out names). "We've been seeing more rejects on Line 3 since last month" is enough to start. Add "just draft it" to skip the questions and get the whole deliverable now.

See a finished example first (optional): the worked examples are in the download, in the resources/examples folder.

Related Skills

Problem scoping leads directly to root cause

A well-scoped problem statement is the input to root-cause analysis. The IS-NOT column gives root cause a shorter hypothesis list to start from.