Little's Law in Project Management: The One-Equation Test

A PM asks to add a fourth project to a portfolio that's already running three, and the honest answer to "will this slow anything down" usually comes from a gut feeling instead of a number. Little's Law in project management replaces the gut feeling with an equation: work in progress equals throughput multiplied by cycle time, or L = λW. Rearranged, cycle time equals WIP divided by throughput. If the team's throughput doesn't change, and it usually doesn't just because a new project got added, then adding work in progress raises cycle time in direct, calculable proportion. That turns "this might slow things down" into "this adds one week to everything already running."

In short. Little's Law says WIP equals throughput times cycle time, proven by John D. C. Little in 1961. Rearranged as cycle time equals WIP divided by throughput, it predicts what adding a project does to everything already in flight, without needing the team to work any differently. It's also the reason WIP limits lower cycle time: less work in progress at the same throughput means less time waiting behind everything else.

What Little's Law in Project Management Actually Says

The equation has three variables, and mixing up which one you're holding fixed is the most common way to misuse it.

Symbol	Name	What it measures	Typical unit
L (or WIP)	Work in progress	How many items are in the system right now, started but not finished	items
λ	Throughput (arrival/completion rate)	How many items enter or leave the system per unit of time, at steady state	items per week
W	Cycle time	How long an item spends in the system from start to finish, on average	days or weeks

John D. C. Little proved the relationship L = λW in 1961, in a paper that showed it holds regardless of arrival pattern, service order, or how work gets prioritized inside the system. That generality is what makes it useful outside its original queueing-theory context: a project portfolio is a system with things entering (new tasks or projects), things in progress (WIP), and things leaving (completions), so the same equation applies without modification.

A Worked Example: Adding a Fourth Project

Take a team running three projects with 12 tasks in progress across all three, finishing 4 tasks a week. By Little's Law, average cycle time is 12 divided by 4, which is 3 weeks per task.

Now a fourth project lands, adding tasks without adding people. WIP rises to 16 while throughput, the rate the same team finishes work, stays at roughly 4 tasks a week in the near term, since headcount didn't change. Average cycle time becomes 16 divided by 4, or 4 weeks. Every task already in flight, on every one of the original three projects, now takes about a week longer on average, not because anyone is working slower, but because there's more in progress sharing the same completion rate.

The diagram below shows the same team under both scenarios, with throughput held constant to isolate what adding the project actually changes.

Nothing in that calculation depends on how good the team is. It's an identity, not a performance judgment, which is exactly why it survives the "we'll just work harder" objection that usually follows a scope-add conversation.

Why This Is Also Why WIP Limits Work

WIP limits cap the L side of the equation directly. Hold throughput roughly constant and cut WIP, and cycle time falls by the same ratio, because cycle time is nothing more than WIP divided by throughput turned around. That's the entire mechanism behind why capping work in progress speeds up how fast individual items finish, even though it looks, from the outside, like the team is doing less at any given moment.

A cumulative flow diagram is where this shows up visually before anyone runs the arithmetic: a widening band is WIP climbing while throughput hasn't caught up, which is the same imbalance Little's Law describes algebraically. Reading the chart and doing the math are two views of the same underlying system.

Using It Before You Say Yes to a New Project

1. Get current WIP and throughput first. Count tasks genuinely in progress across the portfolio right now, and measure completions per week over the last several weeks.
2. Compute current average cycle time. WIP divided by throughput gives you the number to compare against.
3. Estimate the WIP the new project adds, not its headcount or budget, its actual task count in flight at any one time.
4. Recompute cycle time assuming throughput doesn't move. This is the honest baseline, since a new project rarely raises completion capacity on day one.
5. Bring that number, not a feeling, to the conversation about whether to take the project on, or what has to change (more throughput, a paused project, a WIP limit) to avoid the slowdown the equation predicts.

The three-project portfolio tipping point is where this conversation usually gets forced, since that's where informal capacity tracking stops working and someone has to answer "can we take this on" with more than intuition. Little's Law is the fastest gut check available before reaching for a full capacity model: it needs only two numbers you can usually pull from this week's board, WIP and recent throughput, and it answers the specific question a sponsor is actually asking, which is how much later everything else finishes if the answer is yes.

If the honest answer is that current utilization is already tight, the free Resource Heatmap shows where the capacity actually is across your existing projects before you run the Little's Law math on a new one, so the throughput number you plug in reflects real availability rather than a headcount total.

Run the free Resource Heatmap See current utilization across every active project before you estimate what a new one adds to WIP. No signup required. → Open the Resource Heatmap