Work-in-Progress Cap¶

Concurrency-limiting pull method — instantiates Overcommitment Prevention

Caps how many commitments may be active at once, forcing one to finish before the next can start.

Work-in-Progress Cap puts a hard limit on the number of items that may be in progress simultaneously: when the cap is reached, nothing new starts until something finishes — a pull system rather than a push. Its distinguishing lever is concurrency. It governs active work-in-flight, not the total promised or the total queued, and by capping how much can be started it forces the queue to hold demand rather than the workers. It is narrower than the archetype — the promise-level limit lives in Commitment Budget — but it is the sharpest tool for the overload that comes from starting too much at once.

Example¶

A surgical suite keeps "starting" cases — pre-opping the next patient before the last is out — so recovery bays clog, staff thrash, and turnovers slip. It imposes a WIP cap: at most four cases active across the suite at any time (open plus in-recovery). A fifth case cannot be pre-opped until a bay frees; the fifth patient waits, visibly, in the pre-op queue rather than in a half-started limbo. Counterintuitively, throughput rises — by Little's Law, for a given service rate, cutting work-in-progress cuts the time each case spends in the system^[1] — and the backlog of waiting cases becomes honest and visible instead of hidden inside overloaded bays.

How it works¶

The signature is pull, not push. Set a ceiling on concurrent active items; admission is then automatic and local — a new item starts only when an active one completes and frees a slot. Excess demand is held in a visible queue, not begun. The cap converts an organizational habit of "start everything" into "finish before you start," which is where most of its effect comes from.

Tuning parameters¶

Cap level — how many items may be active. Too high and thrash returns; too low and resources idle waiting for work — the sweet spot maximizes flow, not utilization.
Unit granularity — what counts as one "in-progress" item (a case, a ticket, a feature). Coarse units are simple; fine ones control flow tightly.
Per-lane versus global — one cap for the whole system versus per-stage or per-person caps. Per-lane finds local bottlenecks; global is simpler.
Pull discipline — how strictly "finish before start" is enforced. Strict pull maximizes flow but frustrates when a blocked item hogs a slot.
Expediting rule — whether an urgent item may preempt the cap, and at what cost. Escape hatches preserve responsiveness but erode the cap if overused.

When it helps, and when it misleads¶

Its strength is directly attacking the overload of too many things started at once, usually improving throughput and predictability by shortening cycle time — starting less finishes more. Its limit is that it governs only active work: a team under a strict WIP cap can still be massively over-promised, because the cap keeps the floor calm while the backlog of accepted commitments quietly balloons. That is the archetype's own warning — WIP caps are narrower than commitment prevention. The classic misuse is setting the cap by utilization ("everyone must always be busy") rather than by flow, which recreates the very thrash it was meant to remove. The discipline is to tune the cap to flow, not occupancy, and to pair it with a commitment-level limit so the queue behind it does not become an invisible pile of promises.

How it implements the components¶

Work-in-Progress Cap realizes the concurrency-limiting side of the archetype:

commitment_limit — the WIP cap itself: a hard ceiling on the number of concurrent active commitments.
admission_rule_for_commitments — the pull rule that admits a new active item only when a slot frees, deferring the rest.
backlog_and_queue_visibility — excess demand waits in a visible queue rather than hiding inside half-started work.

It caps active work, not promised load — the total-promise cap belongs to Commitment Budget, portfolio-level admission to Portfolio Intake Gate, and the capacity model to Calendar Capacity Audit.

Instantiates: Overcommitment Prevention — it caps concurrent active work so the delivery floor is never over-started.
Sibling mechanisms: Commitment Budget · Portfolio Intake Gate · Backlog Commitment Review · Commitment Burndown Review · Capacity Dashboard · Calendar Capacity Audit · Budget Encumbrance Control · Intake Capacity Checklist · Renegotiation Notice Protocol · Sales Capacity Alignment Review

Notes¶

A WIP cap is often mistaken for the whole of overcommitment prevention; it is not. It calms the active floor but leaves accepted-but-not-started promises entirely uncapped — a team can hit every WIP limit and still have promised far more than it can ever deliver. Pair it with Commitment Budget, which caps the promises, not just the work in flight.

References¶

[1] Little's Law states that the average number of items in a system equals the arrival rate times the average time each spends in it; holding throughput fixed, reducing work-in-progress proportionally reduces cycle time. It is the formal reason a lower WIP cap can raise, not lower, the completion rate. ↩