In the first two articles of this Step 3 series, we explored why targets and goals matter and how to write them effectively.
- The Overview explained that every problem-solving effort needs both direction (a target) and measurement (a goal).
- The Tools and Methods article introduced practical frameworks such as George Doran’s original SMART concept, Toyota’s Target Condition Sheet, and capability-based metrics that help turn intent into measurable statements.
This third article builds on that foundation.
Here, we’ll look at what good targets and goals actually look like in practice—and, just as importantly, the common mistakes that even experienced problem solvers make.
If you’re joining mid-series, this piece stands alone as a guide to diagnosing and improving the quality of your goal statements. It highlights the patterns that separate meaningful targets from misleading ones, and explains how to align the right type of goal with the right type of problem.
Let’s look at the three traps I see most often and how to avoid them.
1) Action-as-Goal (the most common trap)
Symptom: The “goal” is written as an activity—install, implement, or train—rather than a measurable outcome.
Why it’s wrong: Activities are means; goals are ends. You can finish the activity without changing the underlying performance. That’s a countermeasure, not a goal.
Typical false goals
- “Implement standardized work.”
- “Install an Andon system.”
- “Train operators on torque procedure.”
Those actions may later appear under Countermeasures—and that’s exactly where they belong.
You might discover through root-cause analysis that productivity is low because the layout is awkward, the sequence unclear, or workload uneven. The resulting countermeasures could include moving a station, redesigning the sequence, and then updating standardized work and training.
But the goal is the performance outcome those actions should enable—improved productivity, reduced defects, shorter changeover time, etc.
Corrected examples (outcome-based)
- “Increase pieces per labor-hour on Line 2 from 18.5 to 21.0 by March 31 during Model A production (first shift, normal staffing).”
- “Increase first-pass yield at Station 4 from 96.2 % to 98.5 % by April 30, verified by daily FPY chart and weekly defect Pareto.”
- “Reduce changeover time on Press 3 from 28 minutes median to 18 minutes median by May 15 (10 consecutive changeovers under standard crew).”
Quick self-check for action vs. goal
- Can you complete it without improving a measurable result? → It’s an action.
- Does it name a performance metric, baseline, target, timeframe, scope, and method? → That’s a goal.
2) Process-as-Goal (meta-work disguised as progress)
Symptom: The “goal” describes the problem-solving process itself.
- “Solve the root cause of downtime.”
- “Complete an A3 on scrap.”
- “Do 5-Why and fishbone.”
Why it’s wrong: Those describe how you’ll think, not what success looks like. They may be useful steps, but they don’t define done.
Rewrite to outcomes
- “Reduce press downtime from 6 hours/week to ≤ 2 hours/week by May 31; OEE log will show cause-code D12 down from 14 to ≤ 4 per week.”
- “Lower scrap on Line B from 4 % to 2 % by June 30; verify by daily P-chart and monthly cost-of-poor-quality report.”
3) Wrong Target for the Situation (Type 2 vs. Type 3 mix-up)
Teams often present a polished “Current State → Target State” pair of maps. It looks professional—but context determines whether that logic even applies.
- Type 2 (Gap from Standard): The target state already exists—it’s the standard you drifted from. Don’t invent a new target; restore the original condition. The goal is metric restoration (yield back to 98 %, changeover back to 18 min).
- Type 3 (Target State): You are intentionally creating a new condition—something that doesn’t yet exist (level loading, pull flow, new cell design). Here a future observable target state is appropriate, and emphasis shifts from root-cause analysis to pathway design.
I go deeper on this distinction in 4 Types of Problems and will expand on it in upcoming articles. Confusing the two leads to the wrong kind of effort: overanalyzing when creativity is needed, or overdesigning when restoration would suffice.
What “Good” Looks Like
A strong target-and-goal pair has:
- Clear direction — plain-language aim anyone can repeat.
- Measurable outcome — metric with baseline, target, and timeframe.
- Process connection — reflects conditions observable at gemba.
- Feasible stretch — ambitious but reachable through experimentation.
- Alignment — tied to a higher-level purpose (customer, safety, cost, delivery).
Template
Improve [metric] on [process/scope] from [baseline] to [target] by [date], measured by [method/cadence] under [operating conditions].
Summary — Bad vs. Good
| Pattern | Bad (Reject) | Why It Fails | Good (Accept) |
|---|---|---|---|
| Action-as-Goal | “Implement standardized work.” | Means, not ends. | “Increase pieces/labor-hr Line 2 from 18.5 → 21.0 by Mar 31 (first shift, normal staffing).” |
| Process-as-Goal | “Complete an A3 on scrap.” | Meta-work, not outcome. | “Reduce scrap Line B 4 % → 2 % by Jun 30 (P-chart weekly, Pareto monthly).” |
| Wrong Target for Situation | “Design future-state map” for a Type 2 problem. | Confuses restore vs. create. | “Restore yield to 98 % on Cell C by May 10; confirm with daily yield chart.” |
Closing Reflection
The discipline is simple to state and hard to live: name the outcome, not the activity—and ensure it matches the problem type.
“Implement standardized work,” “install an Andon system,” or “train operators” may all appear under Countermeasures once analysis reveals the cause of a performance gap, but they are not goals.
The goal is the measurable improvement those countermeasures must produce—verified by data under normal conditions.
In the next article, we’ll turn to the coaching side: how to guide others to uncover these distinctions for themselves without giving them the answers.