When several projects stall at the same review or specialist, focus the recovery plan on that shared step. Theory of Constraints software supports this approach by connecting waiting work, affected commitments and follow-up actions. Choose it for the decisions you need to make, and check that its scope matches project work rather than factory scheduling.
What Theory of Constraints means for project work#
The practical idea is to identify the part of the work system currently limiting the result, improve how it is used, change surrounding work to support it and add capacity when needed. Repeat the review after the limiting point changes, and reconsider rules built around the old bottleneck. TOCICO describes this method as the five focusing steps.
In cross-functional projects, the limiting step might be technical review, legal approval or a scarce specialist. It can also involve a rule that admits too much work. Treat the initial diagnosis as a hypothesis. A large queue alone cannot tell you whether demand, input quality, priorities or staffing caused it.
Apply the five steps to a delayed product launch#
- Identify: follow the launch dependencies and locate the ready work waiting longest at a shared step.
- Exploit: protect that step from interruptions and give it complete, high-priority inputs.
- Subordinate: change upstream starts and downstream plans to match what the step can handle.
- Elevate: consider training, additional capacity or a process redesign when the earlier changes are insufficient.
- Repeat: check whether launch work moves and whether waiting has shifted elsewhere.
The technical names are useful shorthand after the team agrees on the actual work. In a leadership meeting, describe the proposed change directly: reserve review time, stop lower-priority starts or qualify another reviewer.
Distinguish TOC analysis from other software categories#
| Need | What to evaluate |
|---|---|
| Track owners and due dates | Project and task management |
| Investigate a shared delay across projects | Bottleneck evidence, dependencies and action tracking |
| Study elapsed time and growing queues | Cycle time, lead time and status history |
| Schedule machines or production orders | A production planning product with verified manufacturing functions |
| Build a resource-leveled Critical Chain schedule | A scheduler that demonstrates the exact planning and buffer behavior required |
A product using TOC language does not automatically support every TOC application. Write down the scheduling, resource and reporting requirements before comparing tools.
Worked example: a shared design approval queue#
Suppose three projects need a design approval before construction of their next deliverable. In this hypothetical example, the reviewer can complete four ready reviews each week, while six arrive. Two of the six commonly return for missing requirements.
First separate incomplete requests from ready reviews. Improve the request checklist and agree a project order. Protect review sessions for the highest-priority ready work. The next review should compare accepted outputs, queue age and incoming ready demand, not just the number of meetings held.
If ready demand still exceeds completed reviews across a representative period, added capacity deserves consideration. If output improves but downstream work now accumulates in testing, repeat the diagnosis there. Do not keep funding the old bottleneck after the evidence changes.
Data needed for a defensible analysis#
At minimum, collect owners, current states, dates, dependencies and links to the result. Record when work is blocked and why. Estimates can help distinguish a queue of small requests from a few complex jobs. Historical charts need recorded status transitions.
Audit a sample of records with the people doing the work. A task left active while waiting for approval will distort the interpretation. Imported current state also does not guarantee a complete history of earlier transitions. State the observation period and missing records in the review.
Software selection checklist#
- Can leaders open the work behind the suspected bottleneck?
- Does the product distinguish workload from impact on the chosen result?
- Are the evidence, uncertainty and data period visible?
- Can you track a response and its owner?
- Can you compare the same delivery measure after the change?
- Does data transfer preserve the fields and history your analysis needs?
- Can a manager run the review without rebuilding a report?
Run this checklist against one delayed project. Document what failed and the work needed to repair it before committing to a wider rollout.
How Commandix applies the method#
Commandix connects goals, projects and tasks with teams and sales work. The Constraints page shows a possible limiting point, supporting evidence, affected work and confidence. Actions use the labels Exploit, Subordinate and Elevate. The Flow Analytics page supports follow-up with task movement measures.
This suits leaders deciding how to unblock cross-team work. It does not make an automatically proven root-cause claim, and it should not be selected as a manufacturing or full Critical Chain scheduler without demonstrating those specific requirements.
Related guide: How to find engineering bottlenecks with TOC.
Frequently asked questions#
Is Theory of Constraints only for manufacturing?#
The focusing method can be applied to project and service work. Software capabilities vary, so verify the intended workflow rather than assuming a manufacturing tool and a project tool are interchangeable.
Is the busiest employee always the constraint?#
No. Visible workload and impact on the chosen result are different questions. Review dependencies, ready queues and business commitments before interpreting a person-level signal.
How long should a pilot run?#
Choose a period long enough to observe the relevant work passing through the step. Define the baseline, action and follow-up measure before starting. Sparse history may require a data-collection phase.