theory-of-constraints

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

1. 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?

2. Gather evidence:

   • Where are the bottlenecks?
   • What metrics indicate constraint location?
   • Where is utilization highest?

3. Identify the constraint:

   • State clearly what the constraint is
   • Explain why this is the limiting factor
   • Quantify its impact on the system

4. Propose improvements:

   • Start with exploitation (no/low cost)
   • Then subordination (align the system)
   • Finally elevation (if justified)

5. 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:

1. What's the constraint? (The one thing holding everything back)
2. Are we exploiting it? (Getting maximum value from it now)
3. Is everything subordinated? (Is the system aligned to support it)
4. Should we elevate it? (Does it need more capacity)
5. 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.