Portolan Operations decision desk
Open Portolan
All playbooks
Playbook · Capacity & flow

Capacity, flow and scheduling

Congestion is usually a system property, not a motivation problem. This path finds the constraint, measures variability and utilisation honestly, then changes release and staffing before adding capacity.

Start a decision

6 steps · 7 cited sources · free during beta

The question this path answers

Where is work waiting, what is the real constraint, and how should we release and staff work?

The path, step by step

  1. Map the flow and find the constraint

    Walk the process end to end and measure work in process, wait time and throughput at each step. The constraint is the step that gates the whole flow, not the one that complains loudest.

    Why it worksConstraint logic and queueing theory agree that improving a non-constraint adds work in process rather than throughput. Local efficiency can make the system slower.

    EvidenceGoldratt & Cox (1984) · Hopp & Spearman (2001)

    CheckpointOne named constraint, supported by measured WIP, queue time and throughput at each step.

    Common failureImproving the busiest-looking team without checking whether it gates the flow.

  2. Quantify demand, capacity and variability

    Measure arrival rate, service rate, the variability of each, and utilisation at the constraint. Estimate the waiting implied by that combination before choosing a fix.

    Why it worksWaiting rises non-linearly as utilisation approaches one, and variability amplifies the delay. An average load of 85% can still produce unacceptable waits at the peak.

    EvidenceLittle (1961) · Kingman (1961)

    CheckpointUtilisation, variability and predicted wait at the constraint, with the assumptions written down.

    Common failurePlanning from monthly averages and concluding that capacity is adequate.

  3. Cap work in process and control release

    Set a WIP limit at the constraint and release new work only when capacity frees up. Start with a limit you can defend, then tighten it while watching throughput.

    Why it worksPull systems work by capping WIP, not by adopting kanban cards or make-to-order language. A lower cap shortens flow time and exposes the real capacity problem instead of hiding it in the backlog.

    EvidenceHopp & Spearman (2004) · Goldratt & Cox (1984)

    CheckpointWIP stays at or below the cap, and flow time falls without throughput falling.

    Common failureSetting the cap so high that it never binds, then declaring that pull did not work.

  4. Match capacity to the arrival pattern

    Plot demand and waiting by hour and day. Move shifts, breaks, cross-trained staff and batch work into the peak before adding headcount.

    Why it worksA field study in an emergency department reallocated existing provider hours around arrival patterns and cut patients leaving without being seen by more than a fifth. Staffing to the daily average had hidden the peak.

    EvidenceGreen et al. (2006) · Kc & Terwiesch (2009)

    CheckpointWait time by hour before and after the rota change, with hours held constant.

    Common failureAdding the same number of hours to every shift and expecting peak waits to fall.

  5. Schedule with variability and due dates

    Protect due dates with a buffer at the constraint, sequence work by due date and setup cost, and avoid schedules that assume perfect adherence.

    Why it worksQueueing models show that a schedule at full utilisation has no slack to absorb variability; the first delay propagates. Scheduling rules have to price changeover and due-date risk, not just machine time.

    EvidenceHopp & Spearman (2001) · Little (1961)

    CheckpointOverdue share and changeover time under the new sequence, with the buffer made explicit.

    Common failureBuilding a 100%-utilisation schedule and treating every deviation as a discipline problem.

  6. Recheck the system after the change

    Re-measure throughput, flow time, WIP and utilisation. Look for the constraint moving and for new queues forming downstream.

    Why it worksRelieving one constraint shifts the bottleneck. Without a follow-up measurement, the improvement is credited to the intervention while the delay reappears somewhere else.

    EvidenceKingman (1961) · Little (1961)

    CheckpointA before-and-after flow chart with the new constraint named, or evidence that none moved.

    Common failureDeclaring victory after one good week and stopping the measurement.

The evidence base

Each step above cites hand-selected research. These are the studies behind the path.

More from the library

Further reading from Portolan's research library, matched by subject. These papers are not proof that any step works; check each checkpoint against your own operation.

  • Graves et al. (1983) — Scheduling of re‐entrant flow shops
  • Cachon et al. (2017) — The Role of Surge Pricing on a Service Platform with Self-Scheduling Capacity
  • Yom-Tov & Mandelbaum (2014) — Erlang-R: A Time-Varying Queue with Reentrant Customers, in Support of Healthcare Staffing
  • Afèche (2013) — Incentive-Compatible Revenue Management in Queueing Systems: Optimal Strategic Delay
  • Samorani et al. (2022) — Overbooked and Overlooked: Machine Learning and Racial Bias in Medical Appointment Scheduling
  • Robinson & Chen (2010) — A Comparison of Traditional and Open-Access Policies for Appointment Scheduling
  • Gul et al. (2011) — Bi‐Criteria Scheduling of Surgical Services for an Outpatient Procedure Center
  • Liu (2016) — Optimal Choice for Appointment Scheduling Window under Patient No‐Show Behavior
  • Hall & Sriskandarajah (1996) — A Survey of Machine Scheduling Problems with Blocking and No-Wait in Process
  • Liu et al. (2010) — Dynamic Scheduling of Outpatient Appointments Under Patient No-Shows and Cancellations

Guides for this path

Other playbooks