How Capacity Comes Back
Capacity does not come back because people work harder. It comes back because less time and effort stay trapped in the workflow — not additional staffing.
Modelled capacity recovery
of current lead-time capacity appears recoverable — and it holds across very different security workflows.
The exact number is not the headline — the pattern is. Values are close across very different workflows, suggesting recoverable capacity is systemic, not isolated. The right takeaway is not “believe my number” — it is “run your workflow and replace the model with your data.” Modelled with the open csi.dewood.org toolkit; assumptions visible, adjustable, and open to challenge. Recovery rates: queue & handoff 15–35%, rework-loop elimination 35–65% (Hubbard 90% ranges).
PFV usually identifies one or more of three levers
Reduce Waiting
- Limit work in progress; finish before starting
- Keep an evidenced bottleneck busy (only once throughput-limited)
- Reduce handoffs and clarify ownership
- Decouple dependencies; parallelize independent work
- Right-size batch cadence
Reduce Rework
- Identify root causes
- Improve input quality
- Design out common errors
Eliminate Unnecessary Work
- Remove low-value activities
- Simplify approvals and handoffs
- Standardize repeatable work
Why is it waiting?
Finding the biggest wait tells you where to look. It does not tell you why the wait exists — and a long queue is not proof of a bottleneck. Before choosing a remedy, classify the delay mechanism, then confirm it against the timestamps your systems already record. The right fix depends entirely on which of these is true.
Capacity constraint
Demand persistently meets or exceeds what the step can complete.
Evidence: WIP piles up before the step, the resource stays highly utilized, the queue grows over time, downstream is starved.
Batching / schedule
Work is held for a meeting, review cycle, CAB, release train, or maintenance window.
Evidence: items wait even when capacity is free; completions cluster around the schedule; queue time tracks arrival timing in the cycle.
Dependency / blocking
Work can't proceed until another team, vendor, decision, access, or prerequisite arrives.
Evidence: blocked status, repeated follow-ups, external ownership of the next action; queue age tracks response time, not capacity.
WIP overload
Too many items active at once; multitasking and interruption age everything.
Evidence: high active-item count per person, many started & few finished, frequent expedites, aging WIP while new work keeps starting.
Rework loop
Work repeats because inputs were incomplete, defects surfaced, or approvals rejected it.
Evidence: items move backward, reopenings and resubmissions, duplicate effort, high rejection or clarification rate.
Policy / control
The wait is intentional: approval, separation of duties, risk acceptance, evidence retention.
Evidence: the control owner can name the risk purpose; removing the wait changes a control objective. Not automatically waste — ask if the objective can be met in less elapsed time.
Confidence has four levels. Observed — PFV found a large wait or queue. Hypothesized — the pattern suggests a likely mechanism. Verified — operational evidence confirms it. Improved — the intervention produces measurable operational gains. Never present a hypothesized mechanism as a verified cause; multiple mechanisms can also coexist in one wait. The first three levels are confidence in the cause; Improved is a different claim — evidence that the remedy worked. The interactive worksheet walks this diagnosis step by step and labels which level you are standing on.
How small should the batch be?
If cadence-driven queue time is exposure, the natural question is how often to run a scheduled process — and “continuously” is not always the answer. Running more often shrinks the wait but multiplies the fixed cost of each cycle: the regression testing, the maintenance window, the change-approval overhead, the outage risk per deployment. Batch less often and those costs amortize, but items wait longer.
This is the classic economic order quantity (EOQ) problem, first solved by Ford W. Harris in 1913. Mapped onto a security flow its variables read naturally — annual throughput stands in for demand, the cost of delay per item becomes the holding cost, and the per-cycle fixed cost becomes the setup cost. The optimum balances them: it tightens as throughput and exposure rise, and loosens as the per-cycle cost rises. In closed form, the interval scales with the square root of the setup cost, divided by the square root of throughput times exposure.
Two consequences make this useful rather than academic. It puts a floor under the recovery claim: because each cycle carries a fixed cost, total cost has a minimum — so the honest recoverable figure is everything above that economic floor, not everything above zero. And because the cost curve is flat near its optimum — being off by half still costs only a few percent — the right answer is a cadence range, never a false-precise “optimal interval = 19 days.” It is a principled reason not to over-optimize a soft number.
It also answers the batch-size-of-one question directly: continuous flow is the right target only when the cost of running a cycle is near zero. The way to earn a smaller batch is not to mandate it, but to drive down the setup cost — automated testing, CI/CD for patches and detections, a pre-approved standard-change catalog. Lower the cost of a cycle, and the optimal batch shrinks on its own.
Where the analogy stops: EOQ assumes steady, known demand and a holding cost that rises linearly with time; security arrivals are bursty, and the risk of an item held too long can climb faster than linearly once an exploit is public. It applies only to genuinely scheduled processes — patch deployment, change approval, recertification, scan cadence — not to event-driven work like incident response or alert triage, where the right batch is always one. And it optimizes cost, not constraints: a compliance-mandated cycle or a vendor’s fixed window overrides the arithmetic. PFV reflects cadence today as queue time on the scheduled step; an explicit batch-economics optimizer is planned, not yet built. Source: Harris, How Many Parts to Make at Once (1913).