A change portfolio I was asked to look at had a problem everybody could name, and they all named it the same way: a capacity constraint in regulatory review. Nine projects were late, and all nine were late for the same reason, which was that each of them was waiting on a team of three specialists. Those three were excellent. They were also fully booked, and had been fully booked for as long as anybody could remember. There was a business case in preparation for a fourth.
That business case was a competent answer to the wrong question. The question it answered was how to relieve the constraint. The question nobody in the building had asked was whether those three people should have been the constraint at all.
Here is the part that capacity planning processes almost never say out loud. You do not get to choose whether your portfolio has a capacity constraint. You only get to choose where it sits, and whether relief can be bought in weeks or in years. Most organizations decline to make that choice. Declining does not avoid it. It hands the decision to headcount history and budget politics, and those two reliably put the constraint in the one place where relief is slowest, dearest and least repeatable.
What is a capacity constraint, and why does every portfolio have one?
A capacity constraint is the resource whose available hours set the rate at which a portfolio can finish work. It is not the busiest team, and not the most expensive one. It is the resource that nearly every project has to pass through, and whose hours run out before any other resource's hours do.
Every portfolio with more approved work than it can run at once has one. That is not a failure of planning, it is arithmetic. If no resource binds, then every resource has spare headroom at the same time, which means you are paying for capacity nobody is using, everywhere, all year. A portfolio with no capacity constraint is a portfolio whose demand has collapsed. So the useful question was never how to eliminate the constraint. It is where to put it.
The phrase arrives in most organizations as a complaint: we have a capacity constraint in architecture review, said the way you would report a fault. In Flow Economics the same resource gets a different name and a different job. We call it the constraint, the single resource whose rate sets the rate of the whole system, and we treat it as a control point, a place you choose deliberately to meter the portfolio from, rather than a defect to be removed. Everything that is not the control point gets protective capacity, which is deliberate spare headroom whose only purpose is to stop ordinary variation in one team turning into delay across all of them. Once you see the constraint as a control point, the design question becomes obvious, and almost nobody asks it: which resource do you want to be the one that meters your portfolio?
Why does an undesigned capacity constraint land in the worst possible place?
Because the forces that place it by default are selecting for exactly the wrong property.
Organizations economize hardest on headcount where each head is most expensive and most specialized. Regulatory specialists, enterprise architects, actuaries, safety engineers, the handful of people who understand the billing platform. Three of those feels generous when each one costs what four analysts cost, and the work they do is hard to describe in a business case. So the number stays at three.
Now notice what else is true of that group. The external market for them is thin, so you cannot hire quickly. Their work is judgment-heavy, so you cannot train a replacement in a quarter. It is poorly documented, because documenting judgment is slow and nobody has been given the time to do it. And it arrives as conversations rather than tickets, so the queue in front of them is invisible and nobody can say how long it is.
Every one of those properties makes the resource a terrible control point. And the budget process selects for all of them at once, because thin markets and undocumented judgment are precisely what make a role expensive per head, and expensive per head is what the budget process minimizes. The default placement of your capacity constraint is therefore not random. It is reliably, almost mechanically, the worst available choice.
A resource makes a good control point when it has five properties. This is the checklist worth taking into your next capacity review.
1. Visible. Work arrives in a countable queue, so you can state the backlog in hours rather than in adjectives.
2. Elastic at the margin. You can add a meaningful increment of capacity inside one quarter, at a price you know in advance, and give it back later.
3. Broad. Nearly all value passes through it, so one sequencing decision steers the whole portfolio instead of one corner of it.
4. Tolerant of load. Running it hot slows things down without generating rework. A resource that makes mistakes when rushed cannot be run near its limit at all.
5. Stable. It stays the binding resource when the mix of work changes, so your ranking and your buffers do not need rebuilding every quarter.
Score your current capacity constraint against those five. In most portfolios I have looked at, the honest answer is one out of five, and the one is broad.
A worked example: the same portfolio, two places to be constrained
Numbers make the difference concrete. These are illustrative, built on the pattern above.
The portfolio runs 11 projects to completion in a year. Average value, annualized, is $1.3 million each, so throughput is about $14.3 million a year. Three regulatory specialists each contribute about 1,380 productive hours a year once meetings and interruptions are removed: 30 hours a week across 46 weeks. That is 4,140 specialist hours. Each project consumes about 376 of them. 11 projects need 4,136 hours. The specialists are the capacity constraint, to within 4 hours.
So an hour of specialist time carries $3,454 of portfolio value. That is the value per constrained resource hour, the number that tells you what the whole organization is really being paid on, and it is startlingly high for the obvious reason: there are very few of those hours.
Option A, the business case on the table. Hire a fourth specialist. Loaded cost $210,000. Lead time to a productive hire, in that market, 9 months. The in-year gain is about 3 months of one person, say 345 hours, which is 0.9 of a project, or $1.2 million. Over a full year the fourth specialist adds 1,380 hours, or 3.7 projects' worth of specialist capacity. That reads like a strong return, and taken on its own it is. Two things are wrong with it anyway. First, the organization cannot do it twice: that market produces perhaps three or four plausible candidates a year and the competition for them is everybody. Second, those 3.7 projects do not actually arrive, because something else binds first. We will come back to that.
Option B, moving the constraint on purpose. Spend $120,000 and 180 specialist hours writing standing interpretations for the 12 question types that make up most of the demand, a precedent library, and a decision template a senior analyst can complete without a specialist in the room. Specialists then see only genuinely novel judgment. Specialist hours per project fall from 376 to 158.
Watch what that does.
- Specialist load across 11 projects falls to 1,738 hours of 4,140, about 42%. They stop binding and start holding protective capacity, which is also the first time in 4 years that an urgent regulatory question gets answered the same week it is asked.
- The binding resource becomes integration engineering: 9 engineers, 12,420 hours, about 820 hours per project. That supports just over 15 projects a year.
- Throughput goes from 11 projects to 15. 4 more projects at $1.3 million is $5.2 million a year, recurring.
- The cost was $120,000 of cash plus 180 specialist hours. Priced at the old rate of $3,454, those hours were worth about $621,700 of deferred throughput, so call it $742,000 all in, once, against $5.2 million a year afterwards.
Now the part that matters more than the $5.2 million, and that almost no capacity plan captures. With the constraint sitting on integration engineering, throughput is $19.5 million across 12,300 constraint hours, so a constraint hour is worth about $1,585. And an hour of relief can be bought: a contract integration engineer, available on 3 weeks' notice, fully loaded at $95 an hour. One of them, 1,380 hours, costs $131,100 and carries 1.68 projects, or $2.19 million of value.
That is a return of roughly 17 to 1, available inside a quarter, and reversible when the contract ends.
Compare the two options on the thing that actually distinguishes them. Option A buys 3.7 projects' worth of a capacity you can never buy again, after a 9 month wait, and most of it is wasted because integration binds at 15 projects regardless. Option B buys 4 projects immediately and then installs a dial that converts $131,000 into $2.19 million as often as there is ranked work to put through it.
Option A relieves the capacity constraint. Option B changes which resource is the capacity constraint, and picks one where relief is a purchase rather than a recruitment campaign.
Why single-project management is blind to this
Ask which project should have paid the $120,000 for the precedent library, and the question dissolves.
The specialists' time appears in no project's budget, because they are shared. The library benefits all 11 projects and is owned by none of them. A project manager who proposed it would be spending their own contingency to produce a benefit that lands nine tenths outside their own scope, and would then be assessed on the nine tenths they gave away. So it never gets proposed, year after year, in organizations full of people who can see the problem perfectly well.
This is the Project Illusion in its capacity form. The illusion is that a portfolio is a set of independent projects, each with its own costs, benefits and resource needs, so that managing each one well manages the whole. In a constrained system that is false, and the place it is most false is here. Where the capacity constraint sits is a property of the portfolio, not of any project. No business case has a line for it. No project plan can move it. It gets settled by headcount decisions taken in a different forum, on a different cycle, by people who were not asked about delivery rate and would not have had the data to answer.
It is also why the conversation always arrives as Option A. A single-project view can see a queue in front of a team, and can calculate that more of that team would shorten the queue. What it cannot see is that the queue is the consequence of a placement decision, and that placements can be changed for a fraction of what relief costs. The same blindness is what makes the ramp cost in the hiring dip invisible, and what sends improvement money to whichever team complains loudest in the non-constraint trap.
What to do instead
1. Name your capacity constraint, in hours, as a decision rather than a diagnosis. Write down which resource it is, how many productive hours a year it has, and how many hours each project takes from it. If three people cannot agree on the resource, you do not have a capacity constraint problem yet, you have a measurement problem. Start with finding the constraint.
2. Score it against the five properties. Visible, elastic, broad, tolerant, stable. Do it in a meeting, out loud, on one page. The score is the argument: it is very hard to look at one out of five and keep treating the placement as a fact of nature.
3. Price an hour of relief at the resource you have, and at the resource you would choose. Two numbers for each: what an extra hour returns, and what an extra hour costs to buy, with the lead time attached. The ratio between them is the real measure of whether your portfolio can respond to anything at all. In the example it moves from unavailable at any price this year to 17 to 1 in 3 weeks.
4. Move the constraint by removing demand, not by adding people. This is the cheap direction and it is consistently the neglected one. Most scarce specialist time goes on work that is only nominally specialist: routine questions with precedent, reviews that confirm what a template would have caught, approvals that exist because nobody ever wrote the rule down. Standing interpretations, precedent libraries and pre-completed templates are the tools. They convert the question "who can do this work" into "what does this work actually require", and the answer is usually less than you think.
5. Give the resource you moved the constraint off genuine protective capacity, and then defend it. 40% loaded is not waste. It is the thing that makes same-week answers possible and stops one person's vacation becoming 3 projects' delay. It will look like slack in a utilization report, which is a problem with the report. See the utilization trap for why a resource planned to 100% cannot recover from anything.
6. Re-rank the portfolio against the new constraint in the same week you move it. A ranking built on specialist hours is wrong the moment integration engineering becomes the control point, and a stale ranking will send your newly purchasable hours to the wrong work. Rank by return on the constrained resource, and rebuild the ranking whenever the control point moves.
7. Put the placement on an annual agenda with a named owner. Where the capacity constraint sits should be reviewed once a year by whoever owns delivery rate, alongside the headcount plan rather than after it. That single agenda item is what stops the budget process choosing your control point for you, by accident, for the fifth year running.
The objection you are already forming
"This reads like a shell game. You have not added any capacity. You have moved the bottleneck from one team to another and called it a win. Something is still constrained, and the projects are still queueing, just somewhere else."
The first half is correct, and it is the entire point. Something will always be constrained. What changed is which something, and that is not cosmetic, because the 2 candidates differ by roughly a factor of 20 in how fast and how cheaply they can be relieved. A portfolio constrained by 3 specialists with a 9 month lead time has no response available to a demand increase, a resignation or an acquisition. The same portfolio constrained by integration engineering can add 1,380 hours in 3 weeks, and hand them back later. One of those organizations can be managed. The other can only be apologized for.
The second half, that projects still queue, is also true, and worth being precise about. Queues do not disappear, they relocate, and in the example they relocate to a resource where the queue is visible, countable and priced. That is an improvement before anybody buys a single hour of relief, because a visible queue can be ranked and an invisible one cannot.
There is one version of the objection that does land, and Flow Economics should be straight about it. If you move the control point onto integration engineering and then buy relief aggressively, you will meet the next constraint behind it, probably business analysis, and your 17 to 1 will decay toward something far more ordinary. That is real, and it is the mechanism described in the ceiling behind the ceiling. The answer is not to pretend otherwise. It is that the next constraint is now also a choice, made with the same checklist, with the same question asked before the money moves. The difference between an organization that chooses its control point and one that inherits it is not that the first one runs out of constraints. It is that the first one is never surprised by where the next one shows up, and has already priced an hour of relief there.
Your capacity plan almost certainly tells you whether you have enough capacity. It almost certainly does not tell you whether the resource that binds is one you would have picked. Those are different questions, and the second is worth more, because the first gets answered once a year and the second decides what every answer after that costs you.
If you have not yet established which resource sets your delivery rate, start with How to Find the One Resource That Sets Your Delivery Speed. To price an hour of it, see Value per Constrained Resource Hour. And if you want the counterweight to this piece, the reason relief at the constraint returns less than the arithmetic promises, read The Ceiling Behind the Ceiling.
Leave a Reply