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[n1] — 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.
Related¶
- 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
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Work In Progress Cap is defined in the frozen evidence as: Caps how many commitments may be active at once, forcing one to finish before the next can start. Its operative deployed or enacted form is therefore Rule, Policy & Commitment.
Nearest alternative: Control, Automation & Runtime — Control, Automation & Runtime can support this mechanism, but the evidence centers the concrete operation described above rather than the alternative family's defining operation.
Review outcome: Adjudicated after independent review; medium confidence.
Origin Attribution¶
Primary origin: Operations Research
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Work in progress cap is rooted in operations research's queueing, allocation, scheduling, and optimization tradition; historically that field developed the defining operation described here: caps how many commitments may be active at once, forcing one to finish before the next can start.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice has a distinct contributing or parallel lineage for the mechanism's defining operation: caps how many commitments may be active at once, forcing one to finish before the next can start.
- Organizational & Management Science — Organizational management's workflow, staffing, review, and coordination tradition supplies an independent formative lineage for the mechanism's work in progress cap logic.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics has a distinct contributing or parallel lineage for the mechanism's defining operation: caps how many commitments may be active at once, forcing one to finish before the next can start.
Review resolution: The blind reviewers agree that operations_research is the primary origin and differ only on alternate origin disagreement, origin mode disagreement, encyclopedia synthesis disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain cross_disciplinary_synthesis because the combined evidence shows material contributions from several lineages. The broader reach of multi_domain records portability separately from historical provenance; encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
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.
[n1] 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. ↩