Theory of Constraints in project management

Most project methods try to optimize everywhere at once — every task on time, every resource fully utilized. TOC argues this is counterproductive. Because output is governed by the single binding constraint, effort spent improving non-constraints is wasted, and pushing non-constraint resources to 100% utilization just builds up work-in-progress and hides the real bottleneck.

The shift is from local efficiency to global throughput. You accept that some resources will sit partially idle so that the constraint never starves and never waits — because every hour lost at the constraint is an hour lost to the entire project.

TOC's improvement cycle is a repeatable, five-step loop. It is deliberately simple, and the order matters: you exploit and subordinate before you spend money to add capacity.

In Drum-Buffer-Rope, the constraint is called the drum because it beats the rhythm the whole project marches to. On a schedule, the drum is the critical chain — the longest sequence of dependent tasks once you account for limited resources, not just dependencies. A single overloaded scientist, a shared instrument, or a sole-source vendor can be the drum even when the dependency network alone would suggest a different path.

Identifying the drum correctly is the highest-leverage decision in the plan. Manage the wrong chain and you protect the wrong work; the real constraint slips quietly while everyone reports green on the tasks that did not actually matter.

TOC protects the drum with time buffers rather than padding every task. The project buffer sits at the end of the drum and absorbs variation along it, protecting the committed finish date. Feeding buffers sit where a non-drum chain merges into the drum, so a late feeder does not stall the constraint. A resource buffer is an early alert that a constraint resource will be needed soon, so it is ready when the drum reaches it.

The rope is the release mechanism: it ties the start of new work to the drum's pace so material and tasks enter the system only as fast as the constraint can consume them. The rope prevents the upstream pile-up of work-in-progress that masks the real bottleneck and inflates lead times.

Critical Chain Project Management is TOC's five focusing steps and Drum-Buffer-Rope applied to a single schedule. The constraint becomes the critical chain (the drum); exploitation means stripping inflated per-task estimates down to an aggressive median; subordination means starting feeding chains so they finish just in time; and the pooled safety you removed is re-invested as project and feeding buffers — the buffer half of DBR.

Execution is then managed by buffer consumption, typically on a fever chart, rather than by tracking dozens of individual task dates. CCPM is the project-scheduling face of TOC; TOC is the broader management philosophy from which it descends.

The Critical Path Method finds the longest chain of dependent tasks while assuming unlimited resources — every resource is available the moment a task is ready. That is rarely true on a real R&D program, where specialized people, instruments, and vendors are scarce. TOC starts from the opposite assumption: resources are finite, so the binding constraint, not the dependency network alone, sets the schedule.

CPM tells you the longest path; TOC tells you the binding constraint and how to run the whole system around it. They are complementary — CPM builds the network and computes float, and TOC/DBR layers resource reality, buffers, and a pacing discipline on top so the plan reflects what a finite team can actually deliver.

CritPath AI builds the CPM network first (four dependency types, lag, float, near-critical), then identifies the critical chain from that network to locate the drum. It sizes project and feeding buffers — including from a Monte Carlo distribution so the buffer reflects your real P50-to-P80 spread — and renders Drum-Buffer-Rope and a live fever chart so you manage by buffer consumption, not by a wall of task dates. Resource leveling is available as a separate resource-feasible view if you want to compare the CPM-based chain against a resource-constrained one. A Claude + Gemini AI copilot, grounded in your actual dependency graph, explains which task is eating the buffer and what a schedule change does downstream.

It is $10 per user per month for every standard feature, with AI usage billed separately by metered usage — TOC, CCPM, CPM, Monte Carlo, and decision gates in one modern web app, not a 2000s desktop tool that costs many thousands per seat.