Most organizations that adopt WIP limits do it team by team. Each board gets a number on its columns, the teams learn to stop starting and start finishing, and cycle times on those boards improve. Then, a year later, the portfolio is delivering no faster than it was, and leadership concludes the method has run its course.
It has not run its course. It was installed in the wrong place. A limit on work in progress only shortens delivery where it caps the work competing for the resource that sets the pace, and in most portfolios that resource does not own a board.
What are WIP limits?
WIP limits are explicit caps on how many items may be in progress at once in a stage of a workflow. When a stage reaches its limit, nothing new may enter until something leaves. The queue gets shorter, and because waiting time grows with queue length, items finish sooner without anyone working harder.
The mechanism is sound, and it deserves credit. It is Little's Law at work: average flow time equals work in progress divided by throughput, so if throughput holds steady, less work in progress means faster finishes. We walked through the arithmetic in Start Less to Finish More. On a single team with a single board, WIP limits deliver what they promise.
The trouble starts when you ask which work, and whose throughput. WIP limits as usually practiced count tickets, on a team's own board, against that team's own capacity. Portfolio delivery is set by something else: the constraint, the one team, skill or asset whose capacity decides how much the whole organization can finish. What the portfolio needs is a portfolio work-in-progress limit: a cap on the number of projects allowed to draw on the constraint at the same time, enforced at the point where projects are started rather than on any team's board. WIP limits on team boards are a good habit. The portfolio work-in-progress limit is the decision that changes how fast value lands.
Why don't WIP limits on team boards speed up the portfolio?
A worked example makes the gap visible. The figures are illustrative.
Harbour runs 5 delivery teams, each with a WIP limit of 3 items on its board. Every project in the portfolio also needs work from one shared group, a 6-person data platform team, and that team is the constraint. Assume each project needs about 1 month of the data team's full capacity, that the projects are roughly equal in size, and that each starts returning about $40,000 a month once it is live.
Every board is within its limit. But the limits count tickets, not projects, and when a team finishes an item it pulls the next one from whichever project is waiting. So the 15 items in progress across the 5 boards belong to 14 different projects, and all 14 need the data team. If the data team splits its time evenly, each project gets a fourteenth of it, every project takes about 14 months to clear the constraint, and the portfolio earns nothing from any of them in year one.
Now cap the portfolio at 4 projects drawing on the data team, with the other 10 waiting outside, and keep everything else the same. The first 4 finish in about 4 months, the next 4 by month 8, the next 4 by month 12 and the last 2 by month 14. In year one the first batch returns 4 projects × 8 live months × $40,000 = $1,280,000, and the second returns 4 × 4 × $40,000 = $640,000. That is $1,920,000 of benefit in the year against zero, from the same people finishing the same 14 projects by the same date.
That is the conservative version, because it assumes splitting the data team 14 ways costs nothing. In practice every switch between projects burns constraint hours, so the uncapped portfolio would finish later than month 14. Past a certain load, extra concurrent work lowers total output, the point we call the coordination ceiling.
Why does nobody see it on the dashboard?
Because every measure in view is local, and every local measure looks fine. Each team reports a cycle time within target and a board within its limit. Each project reports progress, because each one is moving, slowly. The data team reports full utilization, which reads as good news. The number that is wrong, the count of projects queued at the constraint, belongs to no project and no team, so nobody reports it.
This is the Project Illusion in its flow form: the belief that a portfolio is healthy because each of its parts is. Team WIP limits can even make it worse. A team that finishes faster pulls new work sooner, and the next item it pulls often opens yet another project upstream of the constraint. The boards look disciplined while the queue that matters gets longer.
How do you set WIP limits for a project portfolio?
1. Find the constraint before you count anything. A limit only means something against the resource that sets the pace. If you are unsure, it is the team every project is waiting on.
2. Count projects, not tasks. The unit is a project actively drawing on the constraint. Even one small task in the constraint's queue counts, because it holds a share of the constraint's attention.
3. Start from what the constraint actually works on. Look back over the last 2 weeks and count the projects the constraint team genuinely put hours into, not the ones assigned to it. Set the first limit at or slightly below that number, then lower it a step at a time while flow time keeps falling.
4. Enforce it at the start gate, not on the board. The decision that breaks a portfolio limit is the decision to start a project, so that is where the limit lives. When the portfolio is full, a new project waits, or something already running is paused to make room, deliberately and on the record. Use the wait to assemble the project's full kit, so it arrives ready to use its slot.
5. Fill each freed slot on economics. When a project leaves, the next one in should be the one that returns the most per hour of the constraint, which is the logic of value per constrained resource hour.
6. Keep the team WIP limits. They are still good practice, just not the portfolio control.
Will a portfolio WIP limit leave people idle?
The objection you are already forming: if only 4 projects may draw on the data team, the delivery teams will run out of work.
Some of them will, some of the time. That is not a defect. Those teams are not the constraint, so their idle hours cost little, and the alternative is to keep them busy building work the constraint cannot absorb. That work does not move faster for being started. It sits in the queue as inventory and often comes back as rework. Spare capacity on a non-constraint is cheap and visible. Queuing at the constraint is expensive and invisible, and in the example it is where the $1,920,000 went. The utilization trap is the habit of choosing the second to avoid the first.
Teams outside the limit still have useful work: preparing the next projects so they arrive ready, and doing the testing and data preparation that would otherwise land on the constraint.
WIP limits were never wrong. They were pointed at the board in front of each team rather than the queue in front of the constraint. Move one number, the count of projects allowed to draw on your constraint at once, from nobody's responsibility to the portfolio's, and the method starts doing for the whole organization what it already does for your teams.
Leave a Reply