cathrynlavery Problem-Solving Skill
Structured frameworks for diagnosis and solution evaluation. Read the reference file for whichever framework you select.
Framework Selection
| Problem Signal | Framework | Reference |
|---|---|---|
| Unknown root cause, simple chain | Five Whys | references/five-whys.md |
| Conflicting requirements / trade-offs | TRIZ | references/triz.md |
| Slow throughput / capacity issue | Theory of Constraints | references/theory-of-constraints.md |
| Recurring / interconnected issues | Systems Thinking | references/systems-thinking.md |
| Multi-factor quality issue | Ishikawa / Fishbone | references/ishikawa.md |
| Critical incident, high stakes | Root Cause Analysis | references/root-cause-analysis.md |
| Comparing multiple solutions | Solution Evaluation Matrix | references/solution-matrix.md |
Escalation path: Start simple (Five Whys) → escalate to Ishikawa or full RCA if multiple factors emerge → finish with Solution Matrix when comparing options.
Workflow
- Describe symptoms — What, when, where, impact, what's NOT affected?
- Define boundaries — Scope, recent changes, constraints, stakeholders
- Diagnose — Pick framework from table above, read its reference, apply it
- Generate solutions — 3-5 distinct options addressing root causes
- Evaluate — Use Solution Matrix (read
references/solution-matrix.md) to score options - Plan implementation — Actions, owners, timeline, risks, success metrics
- Monitor — Track metrics, iterate if unresolved
Diagnostic Questions
- Symptom or root cause?
- What changed before the problem appeared?
- Can I reproduce it reliably?
- Are there multiple root causes?
- What feedback loops are at play?
- Where is the bottleneck?
- What's the technical contradiction?
Anti-Patterns
- Jumping to solutions before diagnosis
- Treating symptoms instead of root causes
- Choosing solutions by ease alone
- Ignoring feedback loops
- Not monitoring after implementation