Last year your organization ran a cost exercise, and it worked. Somebody found $180,000 of annual spend that could not be tied to a deliverable, made the case, and removed it. The saving was real, it was signed off, it appeared in the numbers, and the person who found it was thanked in a town hall.
In the same twelve months, the portfolio delivered about a million dollars less value than it would have done otherwise, for reasons directly caused by that saving. Nobody has ever written that number down, and nobody ever will, because there is no account for it to go in.
This is not a story about a bad decision. Every step of it was competent. It is a story about an instrument, and the instrument is the problem: your organization can measure money it spends and cannot measure money it never earns. One side of the ledger is transacted, dated, owned and auditable. The other side is a counterfactual, and counterfactuals do not have journal entries. So the portfolio optimises the half it can see, with great discipline, year after year, and the half it cannot see pays for it.
Economists have a name for exactly this kind of loss: opportunity cost, the value of the best alternative you gave up by choosing what you chose. It is not a new idea and it is not wrong. Where it usually stops is a single decision, one job against another, one project against another. A portfolio needs the same idea applied at scale, priced against the constraint, the one shared resource every project competes for, and updated every time a decision like the one above gets made. That is where the concept usually runs out, and where the rest of this piece picks it up.
I want to give the effect a name, because an unnamed distortion gets argued about case by case rather than corrected once. Call it the asymmetric ledger: the structural condition in which cost reductions are bankable and throughput reductions are not, so a portfolio's measurement system rewards the first regardless of what it does to the second.
The saving that removed a chunk of your delivery capacity
Numbers make the shape concrete. These are illustrative, but the pattern is one I have watched play out in a dozen organizations.
A change portfolio runs everything through a team of six data engineers. They are the constraint: no project ships without passing through them, and every project queues for them. Each contributes about 30 productive hours a week once meetings and interruptions are removed, across roughly 46 working weeks. That is 8,280 constraint-hours a year, and it is the true capacity of the organization to deliver change. Across the portfolio, an hour of that team returns about $1,150 of value, which is the value per constrained resource hour the whole organization is actually being paid on. Total annual throughput: about $9.5 million.
Now the saving. Sitting alongside that team is a small delivery support function: two coordinators and an environments engineer, $180,000 a year all in. On paper they own nothing. They deliver no project, they appear in no business case as a benefit, and when the finance team asks which deliverable they are attached to, the honest answer is none of them. Their actual job, if you watch them for a week, is doing things so that the six engineers do not have to: preparing test data, rebuilding environments, chasing third parties for access, scheduling, keeping the request queue tidy.
They are removed. The $180,000 is booked.
What follows is completely predictable and appears nowhere. The work did not stop being necessary, so it lands on the only people left who can do it. Each engineer picks up about four hours a week of environment fixing, data preparation, chasing and coordination. Four hours, six people, forty-six weeks:
- 1,104 constraint-hours a year transferred from $35-an-hour support staff to the scarcest resource in the organization.
- At $1,150 an hour, that is $1,269,600 of throughput the portfolio no longer produces.
- Net effect of the saving: minus $1,089,600, or about seven dollars of value destroyed for every dollar saved.
- Expressed as capacity, the exercise removed thirteen per cent of the organization's ability to deliver change, and did so without a single conversation about capacity taking place.
Here is the part that makes it permanent. That $1.27 million does not arrive as a $1.27 million event. It is spread across the fourteen projects sharing the constraint, about 79 hours each, which reads as two or three weeks of slip per project. Fourteen delivery managers each write a local explanation: a supplier was slow, a specification changed late, the testing window was tighter than planned. Every one of those explanations is defensible. None of them is the cause. Nobody sums the column, because there is no column.
Meanwhile the $180,000 stays in the numbers, permanently, as evidence that the exercise worked.
The same asymmetry, running the other way
Now watch the mirror image, which is just as common and rather more depressing.
An engineer in the same team proposes automating a manual reconciliation check that the six of them collectively perform for about 300 hours a year. Tooling and build: $60,000, one off. The freed capacity is worth 300 times $1,150, or $345,000 a year, so the payback is roughly nine weeks, and it repeats every year afterwards for nothing.
It is rejected. Not out of stupidity, but because of what the form asks for. The proposal has a hard cost of $60,000 in a year when budgets are flat, and its benefit is 300 hours of somebody's time. Since no headcount is being removed, the finance function correctly declines to recognize a cash saving. The benefit is classified as efficiency, which is the word organizations use for a gain they have decided not to count, and the paper goes into next year's pile.
Put the two decisions side by side. The organization approved a change with a negative return of about $1.09 million and declined one with a positive return of $345,000 a year at a nine-week payback. Both decisions were made correctly according to the instrument. The instrument only has one column.
Why the ledger is asymmetric
Four mechanisms, and it is worth being precise about them, because each one suggests a different fix.
Spending is transacted, throughput foregone is counterfactual. A payment leaves the bank on a date, for an amount, against an invoice. Value that a portfolio would have delivered had it been faster leaves no trace at all, because it never existed. Auditability and importance are unrelated properties, but only one of them determines what appears on a report.
Savings have an owner, throughput losses are distributed. The $180,000 belongs to the person who found it. The $1.27 million belongs to fourteen projects at about $90,700 each, which is below the threshold at which anyone investigates and comfortably within the range that ordinary project noise explains. A cost that lands on shared capacity is a cost no single-project view is built to see, which is the same blindness that makes the price of a new project invisible and that hides the ramp cost in the hiring dip.
The timing is mismatched. The saving lands in this financial year, which is the year the decision is judged in. The throughput loss lands over the following eighteen months, as delay, in a period governed by a different budget and frequently a different set of people. This is the same defect that makes the annual planning cycle so expensive: the cadence of the measurement does not match the cadence of the consequence.
Cost is measurable per person, value is only measurable per system. You can calculate what an hour of any individual costs to the penny. You cannot calculate what an hour of any individual returns, because return is a property of the whole flow, not of a person. So an organization that wants everything measured at the level at which it manages people will end up with a complete picture of cost and no picture of value, purely as a consequence of where it drew the boundary. That is why cost per hour feels like a hard number and value per hour feels like a soft one, when in fact the second is the one that decides your results.
Notice what all four have in common. They are not failures of intelligence, honesty or effort. They are properties of the instrument, which means no amount of trying harder inside the instrument will fix them.
Why can't single-project management see this opportunity cost?
Ask which project should have defended the delivery support function, and the question answers itself: none of them.
Every project's business case nets its own costs against its own benefits. The support function was not a cost of any project, so removing it improved no project's case and harmed none of them on paper. It lived in the gap between business cases, which is exactly where shared capacity always lives, and things that live in that gap have no advocate at the moment they are cut. The same is true of the reconciliation automation in reverse: no single project could book $345,000 of benefit, because eleven twelfths of the freed capacity would go to other people's projects. Anything whose benefits accrue to the system is unattributable, and anything unattributable is unfundable.
This is the Project Illusion in its financial form. The illusion is that a portfolio is a collection of independent projects whose costs and benefits can be added up. Under that assumption, controlling the cost of each project controls the cost of the portfolio, and a saving anywhere is a saving overall. In a constrained system that assumption is simply false. The projects are not independent, because they share one resource, and it is that resource, not the sum of the business cases, that determines what the organization delivers. A dollar removed from constraint-relieving spend and a dollar removed from anything else are entered identically on the ledger, and they have opposite effects on the result.
What to do instead
1. Publish the price of a constraint hour, and require every proposal to be converted into it. You cannot correct an asymmetry until the missing column has a number in it. Calculate your value per constrained resource hour once, publish it, and defend it. It will be approximate, and approximate is enough: the decisions in this article flip at any value above about $165 an hour, and yours is almost certainly several times that. Precision is not what is missing. A number of any kind is what is missing.
2. Put a two-ledger view on every saving above a threshold. For any cost reduction over, say, $50,000, require two figures rather than one: the cash effect, and the effect on constraint-hours, priced. Not a paragraph of narrative risk, two numbers. In the worked example that single line, minus 1,104 constraint-hours, minus $1,269,600, would have stopped the decision in the room in which it was taken. Most savings will show a constraint effect of zero, which is exactly the point: the discipline is cheap, and it isolates the small number of savings that are catastrophic.
3. Classify spend by what it does to the constraint, then cut from the right bucket. Sort your change and support spend into three: constraint-relieving (its purpose is to remove work from the constrained resource), constraint-neutral, and constraint-consuming (it generates work for the constrained resource, including reporting, assurance, coordination and governance ceremony). Savings targets should be met from the third bucket first, and the first bucket should carry a health warning, because cuts there are capacity cuts and must be priced as such. Most organizations, left alone, cut in exactly the reverse order, because constraint-relieving spend is the easiest kind to describe as overhead.
4. Make throughput gains bookable by pre-committing the hours. This is the step that makes the discipline honest, and skipping it is why efficiency benefits have such a poor reputation. Freed constraint-hours are worth nothing until something valuable is done with them. So before approving a proposal that releases capacity, name the work those hours will go to, take it from the top of your ranked queue, and record the delivery date that moves as a result. The 300 hours from the automation become "project K finishes five weeks earlier, worth $X", which is a claim with an owner, a date, and a way of being checked afterwards. A gain nobody has to defend is a gain nobody will realize.
5. Change the question asked at the gate. Most approval processes ask what a thing costs. Add two questions that cost nothing to ask and change most of the answers: how many constraint-hours does this consume or release, and what does it displace. The second matters because the constraint is fully committed by definition, so every approval is implicitly a decision to postpone something else, and a gate that never names the displaced work is not really making a decision at all.
6. Audit your last savings round in constraint-hours. This is the fastest way to make the idea real inside your own organization, and you can do it this month. Take the last twelve months of booked savings, walk each one down to the work it eliminated, and ask where that work went. Some of it genuinely stopped, which is a real win. Some moved to a cheaper resource, which is a better one. And some moved onto the constraint, which means you sold a portion of your delivery capacity at roughly a seventh of its price. Present that number once, with the arithmetic on a single page, and you will not have to fight for the two-ledger rule again.
The objection you are already forming
"This is a comfortable argument to make when it is not your budget. I have been given a number to hit by March. Throughput does not pay that number, and 'we will earn more later' is not an answer I can give the finance director in a year when the business needs cash now."
That is fair, and none of this is an argument against saving money. It is an argument about which money, and it is a stronger argument in a hard year, not a weaker one. The $180,000 exists elsewhere. It is nearly always sitting in the constraint-consuming bucket: reports produced for audiences who stopped reading them two reorganisations ago, governance ceremony scaled to project cost rather than project risk, assurance activity that repeats something already done two gates earlier. Cutting there hits the same budget line and speeds delivery up at the same time. You will have to look harder, because that spend is defended by process rather than by a cost code, but the target is achievable in both currencies at once, and the two-ledger view is what tells you where it is.
There is also a case where the objection is not merely fair but decisive, and Flow Economics should be consistent about it. If the organization genuinely cannot pay its bills, then cash is the binding constraint, and everything in this piece applies to cash instead. Protect the constraint that binds. Cut the delivery support function, in full knowledge that you are trading about $1.27 million of future throughput for $180,000 of present liquidity, because liquidity is what you are short of. That can be an entirely correct decision. What is never correct is making that trade without knowing you are making it, which is what happens by default, in ordinary years with no cash crisis anywhere in sight, because the ledger has one column and the column that is missing happens to be the larger one.
The uncomfortable version of this is worth sitting with. Your organization almost certainly has better cost control than it did five years ago, and almost certainly does not deliver more. Those two facts are not unrelated, and they are not a coincidence. A portfolio steadily optimized against the only ledger it can read will drift, one defensible decision at a time, towards being cheap and slow. The corrective is not to care less about cost. It is to make the second column exist, so that the two can argue with each other before the decision is taken, rather than one of them winning by default and the other turning up eighteen months later as fourteen unexplained slips.
If you have not yet identified which resource sets your delivery speed, start with How to Find the One Resource That Sets Your Delivery Speed, because none of the arithmetic here works without it. For the number that fills the missing column, see Value per Constrained Resource Hour. And if you want to watch the same asymmetry operating on the spending side, where improvement money goes where it is most visible rather than where it works, read The Non-Constraint Trap.
Leave a Reply