Bottleneck Priority Rule¶
Prioritization policy — instantiates Bottleneck Identification and Relief
A prioritization policy that decides, when demand exceeds the constraint's capacity, which work the scarce stage takes first — aligned to the system objective, not to whoever shouts loudest.
When work arrives at the constraint faster than it can be served, something decides the order — and if no one decides it on purpose, it defaults to first-come or loudest-voice. Bottleneck Priority Rule makes that decision explicit: a policy that sequences the constraint's queue by value and urgency to the whole system, and keeps low-value or not-yet-ready work off the scarce stage entirely. Its defining job is to govern order and admission at the constraint — what it does first, and what it should never have to touch — rather than to supply it or enlarge it. Where a buffer makes sure the constraint always has something to do, the priority rule makes sure it is doing the right something: it extracts the most system value from a fixed amount of scarce capacity.
Example¶
A newsroom publishes only as fast as its single media lawyer can clear stories for defamation and privacy risk — legal review is the constraint before anything goes live. On a heavy news day, twenty stories queue for her at once. Left unmanaged, she works whoever emailed most insistently. The Bottleneck Priority Rule replaces that with an explicit policy: sequence by publish deadline weighted against legal risk and audience value, so a breaking investigation slotted for the 5pm bulletin jumps ahead of an evergreen explainer; a triage step routes low-risk listicles to a self-clearance checklist that never reaches her at all; and a defined escalation lets the editor-in-chief override the order for a genuine emergency.
The scarce legal hour now lands on the stories where it actually changes the outcome, and the constraint stops being clogged with work that never needed a lawyer. No capacity was added — the same lawyer, the same hours — but the system value pulled through the constraint rises, because its attention is aimed instead of scattered.
How it works¶
The rule is distinguished by allocating the constraint's attention:
- Score by system value. Rank incoming work by its contribution to the whole-system objective — deadline, value, risk, cost of delay — not by local urgency.
- Triage before the constraint. Sort arriving work so only items that genuinely need the scarce stage reach it; divert the rest to a cheaper path.
- Sequence the queue. Order what remains by the score, so the constraint always works the highest-value item next.
- Bound the exceptions. Provide a transparent, limited escalation path for genuine emergencies — visible, so it cannot quietly become the norm.
Tuning parameters¶
- Priority criteria — what the score weighs (deadline, value, risk, cost of delay). This is the dial that decides whose work waits; it must track the system objective or it will optimize the wrong thing perfectly.
- Triage threshold — how much work is diverted from the constraint entirely. Aggressive triage protects the scarce stage but risks sending real work to an inadequate substitute path.
- Escalation strictness — how easy it is to jump the queue. Loose escalation collapses into "everything is urgent"; rigid escalation can't absorb a true emergency.
- Transparency — whether the rule is published. A visible rule resists gaming and complaint; a hidden one invites lobbying and quiet exceptions.
- Preemption — whether a high-priority item may interrupt work already underway at the constraint or only jump the queue. Preemption serves urgency but wastes the constraint's partial work.
When it helps, and when it misleads¶
Its strength is that it wrings the most system value from a fixed constraint at zero added capacity, and keeps the scarce stage from being consumed by work that didn't need it — which matters most where the constraint rations something people care about, like access, care, rights, or safety.
Its failure modes are social. Priority inflation is the common one: everything gets flagged urgent until the rule means nothing. The run-backwards version is a rule written to justify who already gets served first — politics dressed as policy. And criteria pinned to local urgency instead of system value keep the constraint flawlessly busy on the wrong things. The discipline is to tie the criteria to the agreed system objective, keep the rule transparent and audited against inflation, and — where it rations something contested — make the basis defensible rather than merely convenient.[n1]
How it implements the components¶
Bottleneck Priority Rule realizes the attention-governance slice of protection — what the constraint works on, and what it is spared:
bottleneck_protection_rule— it is the rule that keeps the scarce stage from being consumed by low-value work and allocates its attention to the highest-value items.preprocessing_or_triage_stage— a triage step sorts arriving work, admitting only what genuinely needs the constraint and diverting the rest.escalation_path— a bounded, transparent override for genuine exceptions that would otherwise wait behind the ordinary order.
It does not keep the constraint supplied — that is the Bottleneck Buffer — nor cap total in-flight work (Work-in-Progress Limit), and it adds no capacity: enlarging the constraint is Capacity Expansion or Automation of Bottleneck Stage. The priority rule governs only order and admission.
Related¶
- Instantiates: Bottleneck Identification and Relief — it protects an identified constraint by governing what it works on.
- Consumes: Bottleneck Analysis Workshop supplies both the confirmed constraint and the system-throughput definition the priority criteria must track.
- Sibling mechanisms: Bottleneck Buffer · Work-in-Progress Limit · Input Quality Check · Capacity Expansion · Automation of Bottleneck Stage · Bottleneck Analysis Workshop · Queue Analysis · Theory of Constraints Cycle
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: A prioritization policy that decides, when demand exceeds the constraint's capacity, which work the scarce stage takes first — aligned to the system objective, not to whoever shouts loudest, making its operative form a standing constraint, permission, threshold, obligation, or conditional rule.
Independent corroboration: The frozen evidence defines Bottleneck Priority Rule as 'A prioritization policy that decides, when demand exceeds the constraint's capacity, which work the scarce stage takes first — aligned to the system objective, not to whoever shouts loudest', so its operative form is Rule, Policy & Commitment.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Operations Research
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Operations research sequences scarce-capacity queues by system value, urgency, and cost of delay while screening out work that need not consume the constraint.
Related originating lineages:
- Logistics & Supply Chain Management — Supply-chain practice contributes flow, inventory, queue, procurement, or tier-coordination principles used here.
- Organizational & Management Science — Management science contributes coordination, learning, workflow, governance, or change-management practice used here.
Review resolution: Scheduling and queueing theory establish priority rules for scarce capacity, while Theory-of-Constraints management aligns the rule to system throughput and logistics applies it to material flow. These are established practices, so the page does not require an Encyclopedia-synthesis flag.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The rule assumes a stable, known constraint: it rations attention at one named stage. When the constraint moves — after relief, or under a new demand pattern — the rule must be re-pointed at the new binding stage, or it will keep carefully prioritizing work at a place that no longer limits the system.
[n1] In Goldratt's five focusing steps, "exploit the constraint" (step two) means getting the maximum throughput from the binding resource as it is — never leaving it idle or spending it on work that doesn't require it — before any capacity is added. Sequencing the constraint's queue toward the highest-value work, and triaging lesser work away from it, is exactly this exploitation. ↩