| name | theory-of-constraints |
| description | Applies Theory of Constraints methodology to identify bottlenecks and optimize systems. Use when analyzing performance problems, workflow inefficiencies, project bottlenecks, or when user mentions constraints, throughput, bottlenecks, or system optimization. |
Theory of Constraints (ToC) Analysis
Apply constraint-first thinking to identify and address the limiting factor in any system.
The Five Focusing Steps
When analyzing a problem using ToC, follow these steps sequentially:
1. Identify the Constraint
Find the single most limiting factor in the system.
Key questions:
- What is preventing higher throughput/output?
- Where do queues or backlogs accumulate?
- Which resource is utilized at 100% capacity?
- What do people complain about waiting for?
- Where do work items pile up?
Common constraint types:
- Resource constraint: Limited capacity (people, machines, tools)
- Policy constraint: Rules or procedures that limit flow
- Market constraint: Demand is less than capacity
- Material constraint: Dependencies or inputs are limiting
- Knowledge constraint: Lack of expertise or information
2. Exploit the Constraint
Get maximum value from the constraint before considering changes.
Exploitation strategies:
- Eliminate idle time on the constraint
- Ensure the constraint only works on valuable items
- Remove waste from constraint activities
- Protect the constraint from disruptions
- Optimize quality at the constraint (defects waste constraint time)
Questions to ask:
- Is the constraint working on the highest priority items?
- Are there any breaks, delays, or interruptions?
- Is the constraint doing work that could be done elsewhere?
- How can we reduce setup or changeover time?
3. Subordinate Everything Else
Align all other activities to support the constraint.
Subordination principles:
- Non-constraints should never produce more than the constraint can handle
- Schedule the entire system based on the constraint's pace
- Build buffers before the constraint to prevent starvation
- Accept that non-constraints may have idle time
- Route work to maximize constraint utilization
Key insight: Optimizing non-constraints doesn't improve overall system performance.
4. Elevate the Constraint
If the constraint still limits the system, increase its capacity.
Elevation options:
- Add more of the constrained resource
- Outsource constraint work
- Invest in better tools or automation
- Redesign the process to bypass the constraint
- Offload work to non-constraints
Before elevating, verify:
- Steps 1-3 have been thoroughly implemented
- The constraint is still the constraint
- The investment is justified by the system gain
5. Repeat the Process
Once a constraint is broken, a new constraint emerges.
Important: Don't let inertia become the constraint. When the constraint moves, update all policies and procedures.
Applying ToC: Workflow
Use this workflow when analyzing a system or problem:
Analysis Checklist:
- [ ] Step 1: Map the system and identify the constraint
- [ ] Step 2: Analyze current constraint utilization
- [ ] Step 3: Propose exploitation improvements
- [ ] Step 4: Check subordination (are non-constraints aligned?)
- [ ] Step 5: Assess if elevation is needed
- [ ] Step 6: Identify what will be the next constraint
Step-by-Step Process
-
Understand the system:
- What is the goal (throughput, delivery time, quality)?
- What are the key processes or resources?
- How does work flow through the system?
-
Gather evidence:
- Where are the bottlenecks?
- What metrics indicate constraint location?
- Where is utilization highest?
-
Identify the constraint:
- State clearly what the constraint is
- Explain why this is the limiting factor
- Quantify its impact on the system
-
Propose improvements:
- Start with exploitation (no/low cost)
- Then subordination (align the system)
- Finally elevation (if justified)
-
Predict outcomes:
- What improvement is expected?
- What will become the next constraint?
- What are the implementation risks?
Common Patterns
Software Development Constraints
Typical constraints:
- Code review capacity
- Testing/QA bandwidth
- Deployment frequency
- Knowledge silos (only one person knows X)
- Build/CI pipeline capacity
Example analysis:
Constraint: Code reviews taking 2-3 days
Exploit: Reviewers focus on review before new coding
Subordinate: Developers write smaller PRs, include context
Elevate: Add more reviewers, automated checks
Project/Workflow Constraints
Typical constraints:
- Decision-making bottlenecks
- Information handoffs
- Approval processes
- Specialized skills or roles
- Dependencies on external teams
Personal Productivity Constraints
Typical constraints:
- Available time/attention
- Energy levels
- Decision fatigue
- Context switching costs
- Tool limitations
Key Principles
Drum-Buffer-Rope:
- Drum: The constraint sets the pace for the entire system
- Buffer: Protect the constraint with time/inventory buffers
- Rope: Limit work release to match constraint capacity
Throughput Accounting:
- Focus on system throughput, not local efficiency
- Idle time on non-constraints is acceptable
- Optimize for flow, not utilization
Continuous Improvement:
- Constraint identification is ongoing
- Each improvement shifts the constraint
- Keep iterating through the five steps
Red Flags (Common Mistakes)
- Optimizing non-constraints: Improving something that isn't the bottleneck
- Local optimization: Making one part efficient at the expense of the whole
- Ignoring policy constraints: Only looking for physical/resource constraints
- Premature elevation: Adding capacity before exploiting the current constraint
- Inertia: Not updating processes when the constraint moves
When NOT to Use ToC
ToC is powerful but not always the right framework:
- Unpredictable systems: High variability may require different approaches
- Multiple equal constraints: When several factors are equally limiting
- Exploration/research: When the goal is discovery, not throughput
- Quality/innovation focus: When the goal isn't optimizing existing flow
For these situations, consider other frameworks (design thinking, agile, lean, systems thinking).
Example Application
Scenario: Development team shipping features slowly
1. Identify: Code reviews are the constraint (avg 3-day wait)
2. Exploit:
- Reviewers prioritize reviews over new code
- Review checklist reduces back-and-forth
- Pair programming on critical code reduces review time
3. Subordinate:
- Developers write smaller, focused PRs
- PRs include context, test cases, screenshots
- Team schedules "review time" blocks
4. Elevate (if needed):
- Cross-train more team members to review
- Invest in automated review tools
- Hire additional senior developer
5. Next constraint: After solving reviews, testing becomes the bottleneck. Repeat the process.
Quick Reference
When analyzing any problem, ask:
- What's the constraint? (The one thing holding everything back)
- Are we exploiting it? (Getting maximum value from it now)
- Is everything subordinated? (Is the system aligned to support it)
- Should we elevate it? (Does it need more capacity)
- What's next? (What becomes the constraint after this is solved)
Remember: A chain is only as strong as its weakest link. Strengthening other links doesn't help until you strengthen the weakest one.
