Start Less to Finish More: The Case for a Portfolio Work-in-Progress Limit

Ask a leadership team how their portfolio is doing and you will often hear a proud answer: everyone is busy, every project has started, nothing is sitting idle. Full utilisation is treated as the sign of a well-run organisation.

It is usually the opposite. A portfolio where everything has started is a portfolio where very little is finishing, because starting work and finishing work are not the same act, and only one of them pays.

This piece is about the single most under-used lever in multi-project management: deciding how many things you allow to be in progress at once, and holding that number down on purpose.

Starting is not progress. Finishing is.

There is a deep instinct in most organisations that starting a project is the same as making progress on it. A new initiative gets approved, work begins, and the initiative moves from "not started" to "in flight" on the dashboard. Everyone feels the portfolio has advanced.

But value is not realised when work starts. It is realised when work finishes and the outcome reaches the business. A project that is eighty percent complete has returned nothing. It has consumed capacity, taken on risk, and started losing time-sensitive value, and it will go on doing all three until it crosses the finish line. Half-built value is not half-value. In most cases it is no value at all.

This is why a portfolio full of started, unfinished work is a worse position than it looks. Every open project is a claim on your scarcest people and a store of value you have paid for but not yet collected. The dashboard shows activity everywhere. The bank account shows almost nothing, because nothing has landed.

The law that governs how long things take

There is a piece of arithmetic that decides, more than any amount of effort, how quickly work moves through a portfolio. It is called Little's Law, and it comes from the study of queues. In plain terms, it says:

Average time to finish a piece of work equals the amount of work in progress divided by the rate at which work is completed.

Read that again with a portfolio in mind. The rate at which you complete projects is set by your constraint: the specific team, skill or asset that actually limits delivery. You cannot finish work faster than your constraint can carry it, no matter how much else you start. So if completion rate is fixed by the constraint, the only variable left that decides how long each project takes is how many projects you have open at once.

Double the number of concurrent projects and you double the time each one takes to finish, while completing no more of them. Halve the number in flight and each one finishes twice as fast, on the same capacity, with the same people. Nothing about the work changed. Only the size of the queue did.

A worked example

Suppose your constrained team can genuinely complete about one project a month. That is your throughput, and it is set by the bottleneck, not by ambition.

Now suppose you have twelve projects open at once, because each one seemed worth doing and there was apparent room when it started. By Little's Law, the average project now takes twelve months to finish, because it is queued behind everything else drawing on the same constrained people. Over a year you complete roughly twelve projects, but the first of them does not land until month twelve, and most land late in the year.

Cap the work in progress at four instead. Throughput has not changed: you still complete about one a month. But now the average project finishes in four months, not twelve. Over the same year you complete roughly the same number of projects, yet the value starts arriving three times sooner and keeps arriving steadily from month four onward.

Same people. Same capacity. Same total output. Radically different timing of when value lands. And because value delivered in spring is worth more than the identical value delivered in autumn, the low-work-in-progress portfolio is simply worth more, before you have improved a single process.

The numbers here are illustrative, not a benchmark. The reversal is the point. Starting less did not cost you throughput. It bought you speed to value.

Why it is usually better than the numbers even suggest

Little's Law assumes throughput stays constant as you pile on work in progress. In real portfolios it does not stay constant. It falls.

Every extra concurrent project adds more than its own work. It adds handoffs, dependencies, meetings, status reporting and, above all, context-switching for the constrained specialists everyone is waiting on. A specialist split across six projects loses time to every switch and holds up all six. Beyond a certain load, the marginal project consumes more coordination and constraint capacity than it contributes, and total throughput starts to drop. That tipping point is the coordination ceiling, the level of concurrent work past which doing more things at once makes the organisation deliver less.

So the real trade is not "same throughput, faster finishes." Above the ceiling it is "more work in progress, slower finishes, and fewer of them." Cutting concurrent work does not just bring value forward. It can raise the completion rate itself, because the constraint spends less of its day being switched between and more of it producing. Starting less can literally finish more.

The fix is a limit, not an exhortation

The instinct, once a portfolio is overloaded, is to ask people to focus, to work harder, to stop letting things drift. Exhortation does not remove a queue. The queue is a structural fact: too much work chasing too few constrained hours. You cannot encourage your way out of arithmetic.

What removes it is a limit. Decide the maximum number of projects that may be in flight at once, set at what the constraint can actually carry, and hold the line. When the portfolio is at its limit, a new project cannot simply be added. It waits until something finishes, or it displaces something already running, deliberately and on the record. The operating rule is short: stop starting, and start finishing.

This turns a new commitment into a genuine choice rather than a reflex. Pulling work in only when the constraint is free is the same discipline that makes value per constrained resource hour the right way to decide what fills the slot when one opens. First you cap how much is in flight. Then you make sure the highest-return work is what you let in.

The objection, and the answer

The objection is always the same. If we only run four projects, the people not on those four will be idle. We will be wasting capacity.

Two answers. First, the people who look idle are, by definition, not the constraint. Keeping non-constraint resources busy by starting more work they can begin but the bottleneck cannot finish is the definition of local efficiency bought at the cost of global throughput. Busy is not the same as productive. A person fully occupied building the front half of something that will sit and wait for the constrained team has not added value. They have added inventory.

Second, the alternative to a small amount of visible idle time is a large amount of invisible delay, spread across everything in flight and paid for in time-sensitive value lost while projects queue. Idle time on a non-constraint is cheap and obvious. Delay on the constraint is expensive and hidden, and it is the one that actually determines what the portfolio delivers. Choosing to tolerate the cheap, visible cost to avoid the expensive, hidden one is not waste. It is good economics.

And when a client or a sponsor is waiting, remember what they are waiting for. Starting their project does not help them. Only finishing it does, and finishing it sooner is exactly what a lower level of work in progress delivers.

The shift

Judging a portfolio by how much has started is judging it by the wrong number. It rewards the very overload that slows everything down, and it flatters a dashboard that is busy everywhere and finishing nowhere. Treating each project as if it could be started freely because there seemed to be room, without regard for the queue it joins, is a version of what Flow Economics calls the Project Illusion: pricing a project as though it were the only claim on your people.

The better measure is how fast work reaches the finish line, and the fastest way to move that number is counter-intuitive. Start less. Cap the work in progress at what your constraint can carry, pull new work in only as old work completes, and let the queue shrink. You will not do more at once. You will finish more, sooner, with the people you already have.

---

Flow Economics is the discipline of understanding how value actually moves through an organisation when its resources are constrained, and of making decisions that maximise what the whole system delivers rather than what each project looks like on its own. If your portfolio is measured by how much has started rather than how fast it finishes, the Flow Economics framework is a good place to see the full picture.