The Little's Law formula is one of the few results in operations that is not a model or a rule of thumb. It is an identity, it holds in any stable system, and most delivery leaders have seen it on a slide. Very few have used it to make a decision, because in its textbook form it answers a question about time, and portfolios are funded in money.
What is the Little's Law formula?
The Little's Law formula is L = λ × W. The average number of items in a system (L) equals the average rate at which items pass through it (λ) multiplied by the average time each one spends inside (W). For a portfolio, read it as: work in progress equals throughput times flow time.
John Little proved it in 1961. It does not care what order work is done in or how variable the tasks are. It needs only a stable system and consistent units.
Here is the handover this article is built around. The Little's Law formula prices delay in weeks. Flow Economics prices it in dollars, using drag cost: the value a project loses for every week its finish slips. Multiply the weeks the formula gives you by the drag cost of the work waiting in them, and the formula stops being a description of your queue and becomes the price of it.
How do you rearrange the Little's Law formula for a portfolio?
The same identity answers three different questions, depending on which term you solve for.
1. Forecast: flow time = WIP ÷ throughput. How long will the average project take from start to finish, given how many are open and how fast they complete?
2. Reality check: throughput = WIP ÷ flow time. What completion rate does your plan assume? If the plan promises a delivery time with a given number of projects open, this is the rate it needs.
3. Set a limit: WIP = throughput × target flow time. How many projects can be open at once if you want them to finish within a target time?
The third is the one that changes behavior, because it converts a promise to sponsors into a hard number of slots.
Where do people get the Little's Law formula wrong?
The formula is never wrong. The inputs often are. Three mistakes account for most of the misuse.
Measuring throughput in the wrong place. Portfolio throughput is set by the constraint: the team, skill or asset that limits how fast work can finish. A team that closes 40 tickets a week tells you nothing if every project also needs 2 weeks of the one security architect. Measure the completion rate at the point that sets the pace. If you have not located it, find your constraint first.
Counting items of very different sizes. If six of your open projects are two-week fixes and four are year-long programs, an average flow time describes none of them. Group like with like, or count in constraint hours rather than projects.
Applying it to a system that is not stable. The formula holds when work arrives no faster, on average, than it leaves. If you approve three projects a month and finish two, WIP grows every month and so does flow time. Your forecast becomes a moving target, moving the wrong way.
What does the Little's Law formula cost you in dollars?
Take a worked example. Calder, a mid-sized insurer, runs its change portfolio through a data engineering team that finishes about two projects a month. That team is the constraint. 18 projects are open that need it.
By the forecast form, flow time is 18 ÷ 2 = 9 months. The portfolio plan, approved in the spring, promised sponsors 4 months.
The reality check exposes the plan. To finish 18 open projects in 4 months each, the team would need to complete 18 ÷ 4 = 4.5 projects a month. It completes two. The plan was not optimistic. It was arithmetically impossible on the day it was signed.
The limit form gives the fix. To deliver in 4 months at 2 a month, WIP must be 2 × 4 = 8. 10 projects are open that the constraint cannot serve within the promise.
Now add the price. Suppose the average open project carries a drag cost of $40,000 a month: the benefit it would be earning if it were live. Every project now spends 5 months longer in the system than it would at a WIP of 8, so each one loses 5 × $40,000 = $200,000 of value to waiting. At 2 completions a month, that is $400,000 of value lost every month.
There is a shorter route to the same number. The 10 surplus projects multiplied by $40,000 a month is $400,000 a month. The monthly drag cost of an overloaded portfolio is the excess WIP times the average drag cost per project. You can read it off the project count.
Drag cost is not uniform, so if the projects at the front of the queue carry the highest drag cost per constraint month, the bill shrinks even at the same WIP. That is why sequencing by value per constrained resource hour matters as much as the limit itself.
Why does single-project management miss this?
Each of Calder's 18 plans assumes the data engineers will be available when its tasks come due. None is wrong about its own work. All are wrong about the queue.
This is the Project Illusion: judging each project as though it were the only claim on the people it needs. Little's Law is a portfolio-level identity. The W in the formula is made of waiting, and waiting only exists between projects, so no single project plan can show it. It appears only when you count everything that shares the constraint.
What should you do with the formula this quarter?
1. Name the constraint and measure its completion rate. Use the last 6 months of finished projects, not planned capacity.
2. Count the open work that needs it. Include the projects marked "started" that have not touched the constraint yet. They are in the queue.
3. Run the reality check on your current plan. Divide open WIP by promised flow time. If the answer exceeds the measured completion rate, tell sponsors now, while the conversation is about dates and not about failures.
4. Set a portfolio work-in-progress limit from the third form. Throughput times target flow time. Hold it, and admit new work only as something finishes. We cover the mechanics in Start Less to Finish More.
5. Put a dollar figure on the excess. Excess WIP times average drag cost per month. Report it next to the project count, so the cost of saying yes is visible at the point someone says it.
Isn't Little's Law too simple for real projects?
The objection you are already forming: projects are not widgets. They vary in size, interrupt each other and change priority mid-flight.
All true, and none of it breaks the formula, which holds under any variability and any ordering rule. Variability makes the tails longer, but it never makes average flow time shorter than WIP divided by throughput. If anything, the simple calculation flatters you, because the context switching that comes with high WIP lowers throughput, and lower throughput lengthens flow time further.
The formula is simple. What it reveals is not comfortable: most portfolios carry more open work than their constraint can finish on the dates promised, and the gap has a price you can state in one line.
---
Flow Economics is the discipline of managing a portfolio by how value moves through its constrained resources rather than by how each project looks on its own. If you want to put a dollar figure on your own queue, the Flow Economics framework is the place to start.
Leave a Reply