Finite Capacity Planning

Queue Time: The Biggest Scheduling Lever You're Not Managing

User Solutions TeamUser Solutions Team
|
11 min read
Industrial factory interior with conveyor system showing production flow and work-in-process
Industrial factory interior with conveyor system showing production flow and work-in-process

Ask a production planner how long it takes to make a part and you'll get an answer in minutes — setup time plus run time. Ask how long it takes for that part to ship after the order drops and you'll get an answer in weeks. The gap between those two answers is almost entirely queue time: the time jobs spend sitting at work centers waiting their turn.

In most job shops, queue time is 80 to 90% of total manufacturing lead time. That means a job with 4 hours of actual processing time has 36 to 36 hours of waiting time baked into a standard 10-day lead time. Yet most scheduling systems, and most schedulers, spend their energy optimizing the 10% — the run times, setup sequences, and routing efficiency — while leaving the 90% completely unmanaged.

This post covers queue time as the primary scheduling lever: what it is, how it behaves mathematically, and how to use finite capacity scheduling to eliminate the invisible queue that's adding weeks to your lead times.

For a broader view of how finite capacity planning interacts with lead time, see our guide to finite capacity planning.

What Queue Time Is (and Isn't)

Manufacturing lead time breaks into four components:

Run time — actual machine processing time. Determined by feeds, speeds, and operation sequence. Optimized by process engineering.

Setup time — changeover from the previous job. Determined by tooling, fixturing, and operator skill. Reduced by SMED methodology.

Move time — physical transit between work centers. Usually small (minutes to hours) in a well-laid-out facility.

Queue time — the time a job sits at a work center waiting to be processed. Determined by how much WIP is ahead of it in the queue. Almost entirely within the control of your scheduling system.

In a typical job shop with 10-day lead times, the breakdown looks something like this:

ComponentHours% of Lead Time
Run time2.53%
Setup time1.52%
Move time2.02.5%
Queue time74.092.5%

If you're working a 30-day lead time reduction project and you're focused on cutting setup times, you're working on 2% of the problem. The 92% is sitting in front of machines waiting.

Little's Law: The Math Behind Queue Time

Little's Law is a queuing theory result with a simple statement and profound scheduling implications:

WIP = Throughput Rate × Lead Time

Or rearranged: Lead Time = WIP / Throughput Rate

This is not an approximation. It's a mathematical identity that holds in any stable system regardless of process variability, job mix, or routing complexity. Its scheduling implication is equally unambiguous: if you want to reduce lead time without increasing throughput, you must reduce WIP. There is no other mechanism.

A concrete example:

A job shop releases 50 jobs per week and carries an average WIP of 400 open work orders. Little's Law says the average lead time is 400 / 50 = 8 weeks. If the shop reduces WIP to 200 jobs — same throughput, same staffing, same machines — average lead time drops to 4 weeks. No capital investment. No new equipment. No new headcount. Just a decision about how much work to release.

The reason shops don't do this instinctively is that reducing WIP feels like slowing down. Machines look less busy. Operators look underloaded. Supervisors feel exposed when they can see the floor clearly. The psychological resistance to low WIP is a major barrier to lead time reduction in every shop we've worked with over 35 years.

The Utilization Hockey Stick: Why 95% Is Not "Almost Full"

The most dangerous number in production scheduling is 95% utilization. It sounds conservative — you're using 95% of your capacity, leaving 5% in reserve. In practice, 95% average utilization creates unpredictable and extremely long queue times.

Queuing theory (specifically the M/M/1 queue model) gives the relationship between utilization and average queue length:

Average Queue Length = Utilization² / (1 - Utilization)

At different utilization levels:

UtilizationAverage Queue (in jobs)
50%0.5
70%1.6
80%3.2
90%8.1
95%18.1
99%98.0

The curve is not linear — it's exponential. Moving from 80% to 90% utilization more than doubles the average queue. Moving from 90% to 95% more than doubles it again. The 5% you think you're holding in reserve at 95% utilization is generating a queue 18 times longer than you'd have at 50%.

This is why the lean principle of capacity buffers is not waste — it's the mathematical mechanism that keeps queue time short. A work center running at 75-80% average utilization with 20-25% reserve capacity is not underperforming. It is operating in the flat part of the utilization-queue curve, where queue time is predictable, short, and responsive to demand variation.

Infinite vs. Finite Capacity Scheduling and Queue Time

Infinite capacity scheduling — the default in most ERP systems — treats each work center as if it has unlimited capacity. It assigns operations to time slots based on routing and due dates, without checking whether the work center can actually handle the load. The result is a plan that is theoretically feasible but operationally impossible.

When infinite capacity plans are released to the floor, queue time appears spontaneously. Jobs pile up at real constrained work centers because the plan never accounted for the constraint. Schedulers then spend their day expediting — pulling urgent jobs out of the natural queue sequence and bumping other jobs backward. Every expedite creates ripple effects: the bumped jobs are now late, triggering the next round of expediting.

Finite capacity scheduling enforces resource limits during planning. It will not schedule more work to a work center than the work center can process in available time. When demand exceeds capacity in a time period, finite capacity scheduling either flags it explicitly or moves work to a different period — giving planners a real constraint signal rather than a phantom plan.

The queue time reduction from switching to finite capacity scheduling is immediate and significant. In our experience with job shops transitioning from infinite to finite capacity planning, average lead times drop 20-35% within the first 90 days — not because the machines got faster, but because WIP release is now controlled at the rate the system can absorb rather than at the rate sales is booking orders.

For more on the mechanics of how finite scheduling constrains WIP release, see our capacity planning formulas post.

Queue Time Targets by Work Center Type

Not every work center should have the same queue time target. The appropriate target depends on the work center's role in the system:

Constraint work centers: Target zero queue beyond the planned protective buffer (typically 1-2 days of buffer ahead of the constraint). The constraint should never starve. Every hour of constraint time lost to starvation is lost throughput that can never be recovered.

Pre-constraint feeders: Target a small, controlled buffer — enough to ensure the constraint never starves, but not so much that WIP accumulates uncontrollably. The buffer size should be calculated based on the variability in upstream processing times: higher variability upstream requires larger buffers.

Post-constraint operations: Minimize queue aggressively. Once work has passed through the constraint, it has already earned its throughput. Post-constraint queue is pure waste — it adds lead time without adding value and creates a finishing bottleneck that delays invoicing.

Non-bottleneck work centers: Accept variable queue as a function of utilization fluctuation, but monitor for trend increases that signal an emerging constraint. A non-bottleneck work center with a growing queue trend is a constraint in formation.

Reducing WIP to Reduce Queue: The Practical Approach

Implementing a WIP reduction program requires three operational changes:

1. Set a WIP cap per work center. Establish a maximum number of open work orders that can be physically present at each work center. When a work center hits its WIP cap, the upstream release point holds work until a slot opens. The cap should be set at 2-3 days of work at average throughput — enough to buffer variation, not enough to hide constraint status.

2. Control release at the constraint. The "drum" in TOC's Drum-Buffer-Rope scheduling is the constraint work center. Release work into the system only at the rate the constraint can process it. This is operationally counterintuitive for most shops: if the constraint can process 40 jobs per week, you release 40 jobs per week regardless of how many open orders are in the backlog. The remaining backlog waits in the scheduling system, not on the shop floor.

3. Eliminate the expedite culture that rebuilds WIP. WIP reduction fails if supervisors can override WIP caps by expediting. Every expedited job that jumps the queue is a job that gets its place taken by another job pushed to the back. Net WIP doesn't decrease — it just redistributes. Expediting should be reserved for genuine customer emergencies and tracked as a quality metric, not normalized as standard operating procedure.

How RMDB Manages Queue Time Across the Planning Horizon

The scheduling system is the mechanism through which queue time policy is enforced or violated. A scheduler who understands queue time theory but is working with an infinite capacity MRP system will struggle to implement WIP caps — the system will generate plans that override them immediately.

RMDB's finite capacity engine enforces WIP release control directly in the scheduling logic. Work center loads are constrained during planning, which means the schedule itself reflects real queue time rather than theoretical infinite-capacity queue times. Planners can set protective buffer sizes per work center, configure constraint work center designations, and see projected queue time for every work center across the full planning horizon before releasing work to the floor.

The practical result is that queue time becomes a managed variable — not a consequence of scheduling decisions but an explicit input to them. When a customer requests a 3-week lead time on a standard 5-week job, the planner can see exactly which work center's queue is the binding constraint and make a data-driven decision about whether to accept the order, negotiate the date, or expedite (knowing the real cost of doing so).

RMDB's integration with EDGEBI adds real-time visibility into queue time by work center, making it possible to monitor queue buildup against targets during execution — not just at planning time.


Queue time is the time a job spends waiting at a work center before processing begins. It is distinct from run time (actual machine processing), setup time (changeover), and move time (transit between work centers). In most job shops, queue time accounts for 80-90% of total manufacturing lead time, making it the dominant lever for lead time reduction.
Little's Law states that the average number of items in a system (WIP) equals the average throughput rate multiplied by the average time each item spends in the system (lead time): WIP = Throughput × Lead Time. For production schedulers, this means cutting WIP is mathematically equivalent to cutting lead time at the same throughput rate. You cannot reduce lead time without reducing WIP — or increasing throughput.
This is the queuing theory hockey stick effect. At low utilization (50-70%), queue time is short and predictable. As utilization approaches 85-90%, queue time begins growing rapidly. Above 95% utilization, queue time grows toward infinity — the system can never catch up. This is why capacity buffers matter: running a work center at 95% average utilization doesn't give you 5% spare capacity, it gives you an unpredictable queue that will occasionally grow to days or weeks.
Infinite capacity scheduling generates plans that assume unlimited capacity at every work center, which means it systematically underestimates queue time. Finite capacity scheduling enforces real resource limits, which forces it to sequence jobs so that no work center is overloaded. The result is a schedule where WIP is released at the rate the system can actually absorb — keeping queues short and predictable rather than long and chaotic.

Queue time is costing you lead time you don't need to spend. Contact User Solutions to see how RMDB enforces WIP release discipline and drives queue time down across your shop. Trusted by GE, Cummins, BAE Systems for 35+ years of finite capacity scheduling.

Expert Q&A: Deep Dive

Q: Our quoted lead times are 6 weeks but we know most jobs sit waiting most of that time. How do we quantify the actual queue time?

A: Pull job traveler data for the last 90 days. For each work order, calculate the delta between the timestamp when the job arrived at each work center and the timestamp when processing started. That delta is queue time per operation. Sum it across all operations and divide by total lead time. In shops that haven't actively managed WIP, queue time typically accounts for 75-90% of elapsed lead time. Once you have the number, you'll know which work centers are generating the most queue and can prioritize accordingly. If you're running RMDB, this report is built into the work center performance module.

Q: We reduced WIP by 30% and lead times dropped, but our on-time delivery actually got worse temporarily. Why?

A: WIP reduction exposes hidden problems — and that's the point. When WIP is high, every work center has a large buffer of jobs to pull from, which masks scheduling errors, quality holds, and setup inefficiencies. The queue absorbs the variability. When you drain WIP, the variability has nowhere to hide. Jobs that were previously covered by a three-week queue are now exposed as genuinely late. The short-term delivery deterioration is real and expected. It typically lasts 4-8 weeks while you address the root causes that the WIP buffer was masking. After that, on-time delivery improves significantly because you're solving real problems instead of papering them over with inventory.

Frequently Asked Questions

Ready to Transform Your Production Scheduling?

User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.

User Solutions Team

User Solutions Team

Manufacturing Software Experts

User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.

Let's Solve Your Challenges Together