The queue behind a full capacity plan

Open the capacity plan. Every project has a name next to every role, nothing is unstaffed, and every line reconciles. Then sit in three standups on the same morning. The first team is waiting for the data engineer. The second is waiting for a security review. The third is waiting for the one person who knows how the billing service behaves under load. It is the same person, and often the same week.

The plan records allocation. The standups record a queue. Both are accurate, and only one of them says anything about delivery.

A full calendar hides the wait

When one expert serves four projects, each project gets a slice of that person's week, and from the expert's side the week is genuinely full. From each project's side, work sits. The distance between those two views is where delivery time quietly goes.

The wait also runs longer than the arithmetic suggests, because every return to a project costs something before it produces anything. Reload the context. Reread the ticket. Re-ask a question that was answered three weeks ago and has gone stale since. Discover that the code moved underneath the request. None of that setup shows up as a gap in anyone's calendar; it shows up as items aging in a queue while the person who could clear them is demonstrably busy.

This is the state that utilization reporting describes worst. Read the report on its own and the obvious reading is that the teams need to move faster.

Concurrency has a cost curve, not a straight line

Colicev et al. (2022) followed product-development work at one large multinational for close to two years, matching project records against how several hundred employees actually spread their hours across dozens of projects. The relationship between multi-project work and hitting project dates was not a straight line. A moderate spread went together with better timeliness, which is intuitive enough: an expert blocked on a handoff in one project has something useful to do in another. Past a point, the cost of switching overtook that benefit and timeliness got worse.

How steep the cost ran depended on the conditions around the work. Projects that resembled each other, specialists with deep experience in their own field, and people who had worked together before absorbed switching more easily than unfamiliar teams moving between unrelated problems. The same nominal load lands differently on different work.

Read that study for the shape of the curve, not for a number on it. It is observational, it covers new-product development rather than software delivery, and it comes from a single company, so it shows association and not cause. It tells you what pattern to look for in your own data. It does not tell you how many projects one person can carry, and any transfer to your delivery context is an inference you are making, not a finding the study hands you.

The switching is mostly generated above the expert

If concurrency has a cost, the next question is who creates it. In most organizations, the expert does not choose their own project count. It accumulates through staffing decisions, escalations, and rescues.

Yaghootkar and Gil (2012) built a system-dynamics model of a schedule-driven multi-project environment, grounded in fieldwork at a truck developer. The model tests the move most delivery leads have made at least once: a business-critical project runs late, so people committed elsewhere are pulled onto it. The rescued project gains time by transferring the delay to the others. Those projects slip and become the next emergency, and as people move more often, productivity erodes across the whole set. The policy that saves this quarter's project schedules next quarter's crisis. A simulation is not a measurement of delivery outcomes, so treat this as a mechanism rather than a result, but it is a mechanism most delivery leads will recognize from their own last two quarters.

Smaller management moves push in the same direction. Bendoly et al. (2014) ran a controlled experiment with working professionals handling concurrent project work and found that clarifying which project mattered most did little to change how often people switched. Managerial progress checks increased switching, and when the check landed mattered. The status update meant to unstick a stalled project can pull the expert off the thing they were about to finish. Because this ran in a simulated environment rather than with live software teams, read it as evidence about what triggers a switch, not about what switching costs your dates.

Put the three together and the picture is consistent: sharing specialists can help at moderate loads, while unbounded concurrent demand creates the queue. The organization sets that demand.

Change the demand before you ask the person to change

The first instinct is to ask the expert to be faster, more available, or better at prioritizing. Those requests go nowhere, because the expert is already the scarce part of the system. What is actually adjustable is how many projects are allowed to queue on them at once.

• Pause a project instead of thinning everyone across it. A paused project stops generating requests, while a thin project keeps generating them at full rate.

• Batch similar requests into protected service windows, so the setup cost gets paid once rather than six times.

• Move a decision right. Some waits exist because only one person is allowed to say yes, not because only one person knows the answer.

• Pair on the next few requests instead of simply answering them, so the queue has a second server next quarter.

Leave some capacity unassigned on purpose. An expert loaded to the last hour has no room for a genuine exception, so the exception displaces planned work and starts the rescue cycle running again. Spare capacity here is what keeps an exception from becoming an emergency, which makes idle time a design choice rather than waste.

Keep project count per person off the individual scorecard. It describes how work is routed, not how someone performs, and turned into a personal metric it becomes something to look good at.

Run a load trace on Monday

Take the last ten work items in one product area that finished late or ran much longer than comparable items. For each one, write down:

• the specialist or scarce role it waited for

• how many active projects that person or group served that week

• how long the item sat before anyone started work on it

• what caused the expert to switch away: a new priority, an escalation, a progress check

• whether the work arrived as one coherent block or as a string of small interruptions

• whether someone else could have handled it with clearer decision rights, better documentation, or an hour of pairing

Then take the three longest waits and walk through them with the expert and the delivery leads involved. Ask what happened, not who is responsible. The point of the trace is to make the queue visible to the people who set its size.

Pick one change out of that conversation and make it real. Pause a project. Open two protected windows. Batch one request type. Move one decision right. Run it for four weeks and watch how long items wait before service starts, how often the expert switches, and how widely cycle time varies between items.

Do not watch the expert's utilization. It will probably fall while the projects move faster.

References

Bendoly, E., Swink, M., & Simpson, W. P. (2014). Prioritizing and monitoring concurrent project work: Effects on switching behavior. Production and Operations Management, 23(5), 847–860. https://doi.org/10.1111/poms.12083

Colicev, A., Hakkarainen, T., & Pedersen, T. (2022). Multi-project work and project performance: Friends or foes?. Strategic Management Journal, 44(2), 610–636. https://doi.org/10.1002/smj.3443

Yaghootkar, K., & Gil, N. (2012). The effects of schedule-driven project management in multi-project environments. International Journal of Project Management, 30(1), 127–140. https://doi.org/10.1016/j.ijproman.2011.02.005