Six months ago you won an argument that most portfolios never even have. You worked out which resource was genuinely setting your delivery speed, you proved it with evidence rather than volume, you got the money, and you elevated it: routine work lifted off the specialists, a checking step automated, two people hired and ramped. Capacity on the constraint went up by forty per cent, exactly as the business case promised.
Throughput went up by about seven.
Nobody lied to you and nothing failed in a way an audit would recognize. What happened is the most predictable event in the management of a constrained system, and one that almost no business case makes room for: the limit moved. You did not remove your constraint, because a working system always has one. You handed the job to whatever was standing next in line, and at that moment the return on everything you had bought was capped by a ceiling nobody had ever measured, for the very good reason that until that morning it had never been binding.
The effect deserves a name, because the unnamed version gets absorbed as disappointment rather than managed as arithmetic. Call it the ceiling behind the ceiling. When you elevate a constraint you do not buy the capacity you added. You buy the gap between where you were and wherever the next limit sits. Everything above that line is capacity you own, pay for, staff, and cannot convert into anything at all.
You buy the gap, not the increase
The logic is unglamorous, and it decides the return on the largest capacity decisions most organizations make.
A portfolio's throughput is set by its binding limit. Raise that limit and throughput rises with it, but only until it meets the next limit in the chain, at which point throughput stops and stays stopped no matter how much further you raise the first one. So the value of an elevation is not the capacity you added. It is whichever is smaller: the capacity you added, or the distance from your old ceiling to the next one.
Three consequences follow, and each of them contradicts the way these decisions are normally made.
Your business case is almost certainly overstated, and not by a little. Every elevation case in existence is built by multiplying the added capacity by the value of an hour of it. That calculation silently assumes the next ceiling is infinitely far away. It rarely is. If the next limit sits close behind the one you are lifting, you can spend the full cost and collect a fifth of the benefit, and the case will still have looked immaculate at approval.
The stranded capacity is worse than idle. New capacity on a resource that now sits upstream of the real limit does not politely wait. It produces work. That work reaches the new constraint and stops there, so what you have actually bought is a growing pile of nearly finished things, ageing in a queue, going stale, needing rebasing and retesting, manufacturing rework out of nothing but delay. You have paid to convert money into work in progress, which is the one asset class in a portfolio that reliably depreciates.
The cheap move and the expensive move have to be bought as a pair. This is the part that catches experienced people, because it sits in genuine tension with a rule they have correctly learned. The non-constraint trap says that improving anything other than the constraint buys you nothing, and that is true of the system as it stands today. But a resource that will become the constraint the moment your planned elevation lands is not a non-constraint in any useful sense. It is a component of the elevation. Priced alone it is worth zero, which is exactly why it never gets funded, and without it the thing you did fund returns a fraction.
A worked example
Numbers make the shape concrete. These are illustrative rather than precise, but the structure is one most portfolios will recognize.
A financial services firm runs its change portfolio through a platform engineering group of five people. They are the constraint: every piece of change in the portfolio passes through them, and nothing reaches production that they have not touched. After meetings, incidents and administration, each contributes about 30 productive hours a week, so the constraint runs at 600 constraint-hours a month. Across the portfolio, an hour of that group returns roughly $800 of value, which is the value per constrained resource hour the whole organization is really being paid on. The constraint therefore delivers about $480,000 a month.
The elevation is well designed. Scheduling and reporting are lifted off the group, one manual verification step is automated, and two engineers are hired. Steady-state capacity reaches 840 constraint-hours a month, an increase of 240, or forty per cent. All in, it costs about $190,000 a year, plus a hiring dip on the way through.
The business case writes itself: 240 extra hours at $800 is $192,000 a month, about $2.3 million a year, against $190,000 of cost. Nobody on the board needs persuading twice.
Now the ceiling nobody measured. Everything this group produces has to clear the change advisory board before it goes live. The board sits fortnightly and approves at most four production releases per sitting, so eight a month. An average release embodies about 80 constraint-hours of platform work. The board can therefore convert at most 640 constraint-hours a month into anything a customer or a regulator will ever see.
Before the elevation, the platform group produced about 600 hours of work a month, roughly seven and a half releases. The board approved everything that arrived, every time, and appeared in no capacity analysis anywhere in the firm, because a resource with spare capacity is invisible.
After the elevation, capacity is 840 and the ceiling is 640. Delivered throughput goes from 600 to 640. That is a gain of 40 constraint-hours a month, worth $32,000, against a case that promised $192,000. You collected about one dollar in six. The other 200 hours a month, $160,000 of capacity every month, is now producing releases that queue in front of a fortnightly meeting, at a rate of two and a half a month, for ever.
Here is the part worth sitting with. Moving the board from fortnightly to weekly, with the same four slots per sitting, raises the ceiling from 640 to 1,280 constraint-hours a month. It costs a recurring hour in some senior diaries and a little more preparation from reviewers. Do that first and the same $190,000 of elevation delivers its full $192,000 a month, roughly $2.3 million a year instead of $384,000. The identical spend returns six times as much purely because of the order it was bought in.
And now the subtlety that makes this so hard to catch in advance. If you had proposed the board change on its own, in the year before the elevation, it would have been worth precisely nothing. Capacity was 600, the ceiling was 640, and doubling a ceiling nobody is touching adds not one dollar of throughput. Any competent analysis would have rejected it, and would have been right to. The board change is worthless alone and indispensable alongside. That is not an argument you can win with a governance process that scores initiatives one at a time.
Where the next constraint actually goes
The reason the next ceiling is so rarely spotted in advance is that people go looking for it among the things they already count, which means teams and headcount. It is usually somewhere else entirely. In portfolios, the second constraint tends to be one of five things, and only the first of them appears on a resource plan.
Another specialist group. The familiar case, and the least common. Where it does happen it is at least visible, because the organization already has a capacity model, a cost code and a line manager for it.
A cadence. A board, a release window, a monthly cycle, a quarterly planning event. Its capacity is measured in slots per period, not in hours, which means it cannot appear in any plan denominated in full-time equivalents. Cadence ceilings are the most common second constraint in change portfolios and, by a distance, the cheapest to lift, because the fix is a calendar entry rather than a salary. Decision latency is this constraint seen from the side of the work that is waiting.
A single shared asset. One pre-production environment, one copy of the anonymised data set, one integration test rig, one relationship with a regulator who will take three submissions a quarter and no more. Shared assets are almost never modeled as capacity at all, because nobody thinks of a machine or a relationship as having a queue.
A single named approver. Not a team, a person: the one who signs the risk acceptance, the architect whose review is mandatory, the sponsor whose name has to be on the change. A team of eight has a capacity plan. A person who happens to be the last signature has a calendar, and nobody is managing it as a system resource.
The far end of the pipe. The ceiling may sit past the point where you stop looking, in the ability of the business to receive, adopt and operate what you deliver. That is the absorption constraint, and elevating a delivery constraint while the receiving organization is already full is the purest form of paying for stranded capacity.
Notice what four of the five have in common. They are rules, cadences, assets and individuals, not teams. They have no capacity plan, no utilization figure, no owner accountable for their throughput, and in most cases no budget line. That is precisely why they are the ones left standing when you elevate the thing that has all four.
Your instruments keep pointing at the old constraint
The second cost of a constraint that moves is not the stranded capacity. It is that every mechanism you built to manage the old constraint keeps running, correctly and diligently, aimed at a resource that is no longer setting your speed.
Your ranking metric becomes wrong. If you have done the work of ranking the portfolio by what it consumes of the constrained resource, that ratio has a denominator, and the denominator is the old constraint. The day the limit moves, you are dividing value by hours of a resource that now has slack, and the ordering it produces is no longer economic. It will go on producing a confident, precise, well-argued list, which is exactly what makes it dangerous. A ranking that is obviously broken gets fixed. A ranking that is measuring the wrong resource gets obeyed.
Your work in progress limit is now set to the wrong drum. A limit calibrated to what the old constraint could carry will, after the elevation, either starve the new capacity or, far more often, flood the new constraint. Either way the number that used to protect flow is now the number damaging it.
Your buffers protect the wrong thing. Feeding buffers, expediting rules, the standing agreement that this particular group is never interrupted: all of it was built to keep the old constraint from starving, and all of it is still running. Meanwhile the resource that now governs delivery, very often a fortnightly meeting or one person's signature, has no buffer, no protection and no early warning signal of any kind.
Your improvement budget keeps flowing to yesterday's bottleneck. Attention is sticky. The group everyone spent two years learning to protect goes on receiving the tooling, the hiring and the executive sympathy, long after the marginal hour there stopped being worth anything.
There is a general rule underneath those four. The more successfully you manage a constraint, the more institutional machinery you build around it, and the more expensive it becomes to notice that it is no longer the constraint. Organizations that never found their constraint at all cannot suffer from this. It is a failure mode reserved for the ones doing it properly, which is why it so rarely gets written about.
Why single-project management is blind to this
Every instrument a project-centered organization owns is incapable of representing a ceiling of this kind.
A resource plan models people and hours. A cadence has neither. There is no field in any mainstream planning tool for "this board converts eight releases a month into value and will not convert a ninth", so the constraint actually governing your portfolio is not merely unmanaged, it is unrepresentable. What cannot be entered cannot be forecast, and what cannot be forecast surprises you every time.
The queue in front of the new constraint belongs to no project. It is twelve projects each waiting a fortnight longer than they expected, which is well inside the tolerance of every one of their plans and worth a line of commentary in none of their reports. Twelve project managers write twelve plausible local explanations, nobody sums the column, and a systemic ceiling presents itself as a dozen unrelated minor slips. This is the same blindness that hides the price of one more project: a cost that lands on shared capacity is a cost that no single-project view is built to see.
And the elevation itself is never audited against its case. The business case promised $2.3 million a year, the money was spent, the capacity arrived, the hires are on the payroll and are demonstrably busy. There is no point in the governance calendar at which anyone compares the throughput of the portfolio before and after, in the currency the case was written in, so the missing five sixths never becomes a finding. It is not concealed. It is simply nobody's question.
Underneath all of it sits the Project Illusion in its capacity form: the belief that an organization's ability to deliver is the sum of the capacity of its parts, so that adding capacity anywhere adds delivery somewhere. It is not a sum. It is a chain, and a chain does not get stronger in proportion to the metal you add to a link that was not the weakest one.
What to do instead
1. Measure the next ceiling before you fund the elevation, and size the purchase to the gap. No elevation case should reach a board without a second number beside the capacity being added: where the limit lands after this, and how far away it is. In the worked example that number is 640 constraint-hours, it was knowable from a meeting invitation and a release log, and establishing it would have taken an afternoon. If the gap is 40 hours and you are buying 240, you are buying 200 hours of stranded capacity, and the board deserves to hear that before it approves rather than after.
2. Buy the pair. When the next ceiling sits close behind the one you are lifting, the enabling move is not a separate initiative to be scored on its own merits. It is part of the elevation, and it has to be funded, sequenced and approved as one thing. This is the most common way that genuinely good analysis produces a poor return: two proposals, each assessed individually, one of them worth nothing alone and both of them worth a fortune together.
3. Lift cadence ceilings before you buy capacity ceilings. Slots per period is the cheapest capacity in the building. A board that meets weekly rather than fortnightly doubles its throughput for the price of a diary entry. A standing slot that is used when there is something to approve and released when there is not costs nothing at all. Before anyone signs a requisition, walk every gate the work must clear and ask what its capacity is in units per month, then ask what it would cost to double. You will often find the answer is nothing, and that it doubles the return on the expensive thing you were about to buy.
4. Re-identify the constraint the moment you change it, and put a trigger on that. Do not wait for an annual review. Make any elevation of more than about ten per cent an automatic trigger to re-run the identification, and when the constraint moves, re-point the machinery deliberately: recompute the ranking on the new denominator, reset the work in progress limit to the new drum, move the protection to the resource that now needs it, and stand down the rituals guarding the old one. Write down which resource each mechanism is currently calibrated against, so that on the day it moves you know exactly what has to change.
5. Watch for the signature, which is a queue where there was never a queue. A constraint that has moved announces itself within weeks, not by anyone becoming busy but by work beginning to wait somewhere that used to be quiet. Measure waiting time in front of every hand-off, gate and approval rather than the busyness of the people behind them, because busyness will not tell you this and waiting will. A queue that was two days last quarter and is nine days this quarter is the system telling you where the limit went.
6. Give the next constraint an owner before it becomes one. The reason cadence and asset constraints go unmanaged is that nobody is accountable for their throughput. A team has a manager who gets asked about capacity. A fortnightly board has a secretary who gets asked about minutes. Name someone accountable for the throughput of every gate the portfolio must pass through, and ask of them what you would ask of any capacity owner: how much can it convert per month, how long is the queue in front of it, and what would it cost to lift.
The objection you are already forming
"So there is always another constraint. Lift one and the problem simply reappears somewhere else, which makes this whack-a-mole, and a reasonable argument for not bothering."
The regress is real. It is also nothing like as bleak as it sounds, for three reasons.
Ceilings are not evenly spaced. Sometimes the next one is 40 hours above your head and sometimes it is a very long way up. That distance is a measurable fact about your system rather than a mystery, and knowing it before you spend is the whole difference between a six-fold return and a one-sixth one. The argument here is not that you should stop elevating. It is that you should find out how far the ceiling is before you buy the ladder.
The second and third ceilings are usually far cheaper to lift than the first. The first constraint in most portfolios is a scarce human skill, which is why it is expensive, slow and painful to elevate, as anyone who has paid a hiring dip can confirm. The ones standing behind it are disproportionately rules, cadences and shared assets, and those are lifted with a decision rather than a budget. The staircase gets cheaper as you climb it, at least for a while, which is the reverse of what people assume when they picture an endless queue of expensive constraints.
And the alternative to a constraint that moves is not a system without constraints. It is a system whose constraint is unmanaged and unknown. You will have one either way, and the only question is whether you know where it is this quarter. A constraint that keeps moving is not evidence that the method is failing, it is the clearest evidence available that it is working, because a constraint only moves when something has genuinely got better. The organizations that never see their constraint move are not the ones who have solved this. They are the ones who have not lifted anything.
The uncomfortable version, worth naming plainly: the day your elevation succeeds is the day your management system becomes wrong, and nothing in your governance calendar is designed to notice. The ranking, the limits, the buffers and the attention all go on pointing at a resource that has stopped setting your speed, with exactly the confidence they had when they were right. So whatever you are currently planning to elevate, the useful question is not how much capacity it will add. It is what will be the binding limit on the morning after it lands, how far above your head that ceiling sits, and what it would cost to raise it in the same breath.
This piece follows on from How to Find the One Resource That Sets Your Delivery Speed, which tells you where to start, and The Hiring Dip, which tells you what an elevation costs on the way in. This one is about the morning after it works. If your improvement budget is currently spread across teams that are not setting your speed, The Non-Constraint Trap is the piece to read first, and if the ceiling behind your delivery constraint turns out to be the organization's ability to absorb what you deliver, start with The Absorption Constraint.
Leave a Reply