The Absorption Constraint: Why Your Finished Projects Are Not Earning Yet
Somewhere in your organisation is a piece of work that was delivered on time, closed properly, celebrated in a steering pack, and is currently earning nothing. The system is live. The process is documented. The training deck exists. What has not happened is the thing the business case was actually promising: the people who were supposed to work differently are still working the old way, because the fortnight of attention it would take to change how four hundred of them do their job has not been available since March.
The project is finished. The benefit has not started. And in most portfolios, nobody owns the gap between those two facts, because the project that would have owned it has been closed.
This piece is about the resource that gap belongs to. Your delivery organisation has a constraint, and a good deal of flow economics is about finding it and running the portfolio around it. But delivery is not the end of the value chain, it is the middle of it. Downstream sits a second resource with finite capacity, a queue in front of it, and no capacity plan anywhere: the organisation's ability to absorb the change you just handed it. In a surprising number of portfolios, that resource, not any delivery team, is the one setting how much value the business actually captures in a year.
The value clock starts at adoption, not at go-live
Every cost-of-delay number in your portfolio rests on an assumption that is almost never stated: that value begins on the delivery date. That is what makes drag cost computable, and it is what makes a slipped milestone feel expensive. Move the date, move the money.
But look at what has to be true for a delivered change to earn its business case. People have to be trained, and trained in a way that survives contact with a busy Tuesday. The old process has to be switched off, not merely deprecated, because as long as both exist most people will use the one they already know. Customers or suppliers may have to be migrated. Supervisors have to enforce the new way through the weeks where it is slower than the old way. Exceptions have to be worked out. Only when all of that has happened does the run rate in the business case arrive, and until it has, the change is earning approximately zero regardless of how live it is.
So there are two dates, not one. There is the date the thing was delivered, which every project tracks obsessively, and there is the date it reached its benefit run rate, which almost nobody tracks at all. The gap between them is where an enormous amount of portfolio value sits unnoticed. And the gap is not mostly made of adoption effort, in the same way that decision latency is not mostly made of deliberation. It is made of waiting: the change sitting delivered and inert, waiting its turn for the attention of the people who could actually land it.
Absorption is a resource, and it is shared
Here is the part that makes this a portfolio problem rather than a change management problem.
Ask who does the absorbing. Not who signs the benefits case, but who actually spends the hours: the regional operations managers who run the briefings, the team leaders who supervise the transition, the small group of experienced practitioners everyone asks when the new screen does something odd, the trainers, the frontline supervisors who carry a productivity dip in their own numbers while their people learn. Now ask that question for the next change in your portfolio, and the one after. You will find the same names.
That is a shared, finite, constrained resource by every test in how to find the one resource that sets your delivery speed. It has a real capacity, it serves every project rather than one, it cannot be bought quickly because its value is precisely that these people know the business, and demand on it is the sum of everything the portfolio delivers plus everything else the business is doing to itself: the reorganisation, the regulatory change, the office move, the system upgrade nobody counts as a project.
And nobody has ever put a capacity number against it. Your delivery capacity is planned to the person-day. Your absorption capacity is assumed to be infinite, because it appears on no plan, and the work it does appears on no timesheet. Which means the portfolio commits to a delivery volume without ever asking the only question that determines whether the volume converts into money: how much change can the receiving organisation actually take in per year, done properly?
When you do ask it, the answer is usually far smaller than the delivery rate, and often far smaller than anyone expects. Absorption is slow because it is human, and its capacity is set by the scarcest thing in any operational business: the attention of the people who both know how the work is done and have the authority to change it.
An absorption queue eats the capacity that would clear it
Every queue in flow economics is expensive. This one has a property that makes it worse than most, and it is worth being precise about.
A queue in front of a busy engineer does not make the engineer slower. It sits there, it ages, it delays value, and all of that is bad, but the server keeps serving at its rate. An absorption queue is different, because the queue itself degrades the resource. Deliver change into an organisation faster than it can land change, and you get change fatigue: people stop engaging with the new process because they have learned that another one is a quarter away, supervisors ration their own credibility rather than spend it on the fifth initiative this year, and the informal answer to "are we doing this one properly?" becomes "let us see if it sticks". Absorption capacity falls, so the queue lengthens, so fatigue deepens. It is a reinforcing loop, and it is the mechanism behind organisations that describe themselves as change-exhausted while their delivery function is hitting every target it has.
The queue also decays. A change waiting eighteen months to be adopted was designed against a process that has since been altered twice, for a team structure that has been reorganised, and integrated with a system that has had two releases. Landing it now requires reopening it, which is rework manufactured entirely by the wait, and some of the queue is never landed at all: it is abandoned without ceremony, having consumed its full build cost and returned nothing. That is the worst possible outcome for an investment, and it is produced not by a bad decision but by a mismatch between two rates.
And while all of that is happening, the money is already spent. Every delivered-but-unabsorbed change is capital that has been fully invested and is earning nothing, which is exactly the condition that should make you re-run its return on the remaining investment, except that the project is closed and no one is looking.
A worked example
Numbers make the shape clear. Take an operations function of a few hundred frontline people, and a change portfolio serving it. The figures are illustrative; the arithmetic is the point.
The delivery organisation ships 12 significant operational changes a year. It used to ship eight, and an improvement programme lifted it, which was reported as a fifty percent throughput gain and was, in delivery terms, entirely real.
Absorption runs at about 4 a year. That is the honest figure for how many changes this business can brief, train, supervise, and drive to a stable new normal without the last one falling over. Nobody has ever written that number down.
Each change is worth about £20,000 a month at its full run rate, once people are genuinely working the new way.
Now run the year. Twelve changes arrive, roughly one a month. Four are absorbed, one a quarter. The other eight join a queue and are absorbed at the same one-a-quarter rate through the following two years. The fifth change, delivered in month five, starts earning in month fifteen: ten months of waiting. The twelfth, delivered in month twelve, starts earning in month thirty-six: twenty-four months of waiting. Add up the waiting across those eight changes and you get 136 change-months of value delayed, which at £20,000 a month is roughly £2.7m of benefit deferred out of a single year of successful delivery. Add the build cost of eight changes that spent the year earning nothing, and the fraction of the queue that will be scrapped rather than landed, and the number gets worse.
Now the uncomfortable comparison. Suppose the portfolio had delivered 4 changes that year instead of twelve, matched to what the business could land. Realised value in the year: identical, because four changes were going to be absorbed either way. But there would be no queue, no decay, no fatigue tax on next year's absorption capacity, and the build cost of eight changes would still be in the bank, available to spend on something else or to spend later against a better-informed design.
Read that again, because it is the whole argument. The fifty percent delivery improvement produced no additional value whatsoever in its first year. It produced a queue. This is the non-constraint trap operating at the largest scale it can operate at: not one team improved in the wrong place, but the entire delivery function improved in the wrong place, because the constraint on value was never inside delivery at all.
Why single-project management is structurally blind to this
If this cost is that large, why is it so rarely managed? Because the frame has a boundary in exactly the wrong place, and the cost lands just past it.
A project is defined by a start and a finish, and the finish is delivery. That boundary determines what gets measured, who is accountable, when the team disbands, and when the governance stops. Adoption sits on the far side of it, owned in principle by a business sponsor whose day job is running an operation, with no plan, no schedule, no dedicated resource, and no forum that reviews it weekly. So the queue forms in the one place the portfolio has no instrument pointed at: after the last status report.
Worse, every actor is behaving correctly. The delivery function is maximising delivered output, which is what it is measured on and funded for. The operations managers are protecting their people from taking on more change than they can survive, which is responsible leadership. The sponsor signed a benefits case in good faith and is now discovering that landing it competes with running the business. Every local decision is defensible, and the aggregate result is a portfolio that converts a minority of what it builds into money.
This is the Project Illusion in its purest form. On time, on budget, in scope, and not earning. The triple constraint measures the production of a deliverable, and a deliverable is not a benefit. It is an option on a benefit, exercisable only by an operational organisation that has the capacity to exercise it. Manage projects one at a time against their own baselines and you will never see the shared resource that decides how many of those options ever get exercised, because it does not belong to any of them.
What to do instead
The remedy is not a better adoption plan bolted onto each project. It is to treat absorption as what it is, a constrained resource serving the whole portfolio, and to run it with the same discipline you would apply to a delivery bottleneck.
1. Measure time to benefit, not time to delivery. For every change, record the delivery date and the date the benefit run rate was actually reached, and report the gap. This single number, averaged across your portfolio, tells you whether you have an absorption problem and how big it is. It is the same move as measuring flow efficiency rather than busyness: stop measuring how much you produced and start measuring how long value spent waiting.
2. Find your absorption constraint by name. Not the function, the specific group whose hours every change consumes. It is usually a small population: regional managers, team leaders, a handful of senior practitioners, the training function. Apply the same test you would apply to any candidate constraint: if you could clone them tomorrow, would a queue of waiting value start moving? If yes, you have found the resource that actually sets your rate of value capture.
3. Put a capacity number on it, then cap what you deliver into it. A portfolio work-in-progress limit that stops at go-live is only half a limit. If you cap the work in flight in delivery but not the change in flight in the business, you have simply moved the queue somewhere no one can see it. The logic of starting less to finish more applies unchanged, with "finish" redefined as "earning".
4. Rank by value per absorption hour when absorption is the constraint. Value per constrained resource hour is not a statement about delivery teams, it is a statement about whatever your scarcest resource happens to be. If that resource is the attention of your operations managers, then the right ranking of your portfolio is by value returned per hour of their attention, and it will differ sharply from a ranking by build cost or by delivery effort. Some cheap-to-build changes are ruinously expensive to land, and some expensive builds land almost by themselves.
5. Extend full kit to the landing, not just the start. Full kit says work should not be released until it can actually run. The same rule applies at the other end: a change should not be delivered until the conditions for absorbing it exist, which means the trained supervisors, the freed management time, the switched-off old process, and the support model are all in place. Delivering into an organisation that cannot receive it is precisely the mistake of starting a project that cannot proceed, and it is more expensive because the money is already spent.
6. Shrink the increment. A large change consumes a disproportionate block of absorption capacity and returns nothing until fully landed, which is the batch size argument moved downstream. Smaller, sequenced increments land inside the attention span of a busy operational team, start earning sooner, and leave capacity to absorb the next one. Big-bang deployments are batch size decisions made in the place where batch size hurts most.
7. Protect the constraint from everything else that consumes it. Your absorption capacity is not spent only on your portfolio. Reorganisations, regulatory changes, tooling migrations, audits and management initiatives all draw on the same managers and the same frontline patience. If your portfolio plans as though it has the whole of that capacity, it is planning against a number that does not exist. Subordinating to the constraint means the whole enterprise sequences against it, which is exactly the kind of cross-portfolio arbitration a Value Management Office exists to do.
The objection you are already forming
"This is not our problem. We build it, the business adopts it. If they cannot absorb what we deliver, that is a business readiness issue for the sponsor to solve. We are not going to slow our delivery down because the operation is not organised. Delivering less is not an improvement, it is just delivering less."
The boundary in that objection is an accounting convention, not an economic one. The portfolio's throughput is not measured in things delivered, it is measured in value realised, and in the worked example above the portfolio realised exactly the same value from twelve changes as it would have from four. The eight extra were not throughput. They were inventory: fully paid for, sitting in a queue, ageing, some of it destined to be written off. Every operating discipline in the world treats over-production ahead of a downstream bottleneck as waste rather than achievement, and this is that, with a governance chart drawn around it.
Notice also that you already accept this logic one step upstream. Nobody argues that releasing forty tickets to an engineer with a queue of thirty is a productivity gain, because the queue is visible and the absurdity is obvious. The only difference here is that the queue forms in a part of the organisation your reporting stops before, so the same act looks like success. Invisible does not mean absent, it means unmanaged, and unmanaged queues are where portfolio value goes to die.
And the recommendation is not, in fact, to deliver less. It is to stop converting delivery capacity into inventory and start converting it into value. That capacity does not have to go idle. It can go to the changes that are cheap to absorb and therefore start earning immediately. It can go to raising absorption capacity itself, which is the only investment that lifts the whole portfolio's rate of value capture: better training design, a dedicated landing function, reduced complexity in the operating model. It can go to smaller increments that land within the attention the business actually has. Every one of those is a better use of a delivery team than building a thirteenth change to put behind the twelfth in a queue.
The instinct to define done as delivered is the most expensive habit in portfolio management, because it puts the finish line at the point where the spending stops rather than the point where the earning starts. Before you fund another improvement to your delivery rate, measure the gap between your delivery dates and your benefit dates. If that gap is long and getting longer, your constraint is not where you have been managing it, and everything you do to deliver faster is making the queue you cannot see a little bit longer.
If this reframed how you read your own portfolio, the two ideas underneath it are worth reading next: why improving anything other than the constraint changes nothing, in The Non-Constraint Trap, and how to identify which resource is genuinely setting your rate, in How to Find the One Resource That Sets Your Delivery Speed.