In March your portfolio board did something admirable. At the second review in its stage gate process, a project that was still 18 months from delivering, and whose business case had evaporated somewhere around Christmas, was stopped. The paper was clear, the discussion took 11 minutes, and $1.2 million of unspent budget went back to the center. Somebody said the words "this is what good governance looks like", and they were right.
5 months later the portfolio is running about 6 weeks behind where the plan said it would be, across almost everything, and nobody has connected the 2 events. There is no reason anybody would. The stop decision recovered every dollar that had not yet been spent. It recovered none of the 430 hours of integration engineering the project had already consumed, and those 430 hours were never really a cost of that project at all. They were the organization's entire capacity to deliver change of any kind, for about two and a half weeks.
That is the whole idea in this piece. A project spends from two accounts. One of them has a refund policy and one of them does not, and every stop, pause and change of direction you make is a partial refund on the cheap account and a total write-off of the expensive one. A typical stage gate process examines the account that refunds, and says nothing about the hours of the constraint.
It needs a name, because an unnamed loss gets absorbed rather than managed. Call it sunk capacity: the constraint-hours a project has already consumed at the moment you change your mind about it, which no cancellation recovers, no budget records, and no stop decision is ever priced against.
Note what this is not. It is not an argument for stopping fewer projects. Stopping work whose economics have turned is one of the most valuable things a portfolio board does, and most boards do not do it nearly often enough. The argument is about the price you pay when you do it, and about the fact that the price is almost entirely set by a design choice nobody remembers making: where inside a project's life the scarcest people do their work.
The two currencies a project spends
Money behaves well when a decision is reversed. Unspent budget returns to the pot and can be spent on something else this year. Committed spend can sometimes be canceled at a penalty. Even genuinely sunk cash leaves the organization no worse off in capability terms: the people are still there, the capacity is still there, and next year's budget arrives on schedule regardless.
Constraint-hours behave badly in every one of those respects.
They cannot be stored. An hour of your constrained team that goes unused in March is not available in June, it simply evaporates, which is why the true capacity of your organization to deliver change is a rate and not a balance.
They cannot easily be bought. If they could, the resource would not be your constraint. Adding people to it makes you slower before it makes you faster, and the increase you eventually collect is a fraction of the one you paid for, which is the hiring dip and the ceiling behind the ceiling respectively.
And once spent, they cannot be recovered under any circumstances whatsoever. There is no penalty clause, no partial credit, no write-back. The hours went into a design, the design was for a project you no longer want, and that is the end of it.
So the two accounts are not merely different in size. They are different in kind. One is a stock, denominated in something recoverable and replaceable. The other is a flow, denominated in the only thing that actually sets your delivery rate. If you have not priced yours, value per constrained resource hour is the number, and in most corporate portfolios it lands somewhere between $600 and $2,000 for every hour of the constrained team.
Hold those two facts together and the ordinary stop decision looks different. It is not a decision about $1.2 million of released budget. It is a decision in which $1.2 million is released and several hundred thousand dollars of throughput is destroyed, and only one of those 2 figures appears on the paper.
Why a stage gate process protects the money and not the constraint
Here is where the losses come from, and it is not carelessness. It is four sensible things interacting.
Good engineering practice puts the hard thinking first. Resolve the difficult technical questions early, before commitments harden. Every methodology says so and every methodology is right. But the difficult early thinking is precisely what your constrained specialists do: the integration pattern, the data model, the security design, the decision about which of three platforms can actually carry the load. The front of a project is where your scarcest capacity lives, by design, and for good reasons.
Your scarcest people are also your most credible people. So they get pulled into shaping, feasibility assessment and estimating, for candidates that have not been approved and some of which never will be. Every hour of that draw is exposed in full, because there is not even a project yet to attribute it to.
Stage gates are calibrated in money. A gate exists to limit financial exposure, so it is placed where cumulative spend is still modest: before the build teams scale up, before the suppliers mobilise, before the licenses are bought, before the rollout budget commits. That is a defensible place to put a gate if money is what you are protecting. Now overlay the two curves. Cash spend is back-loaded. Constraint draw is front-loaded. "Still modest spend" and "most of the constraint already consumed" are the same point on the timeline. Your stop decision arrives reliably after the expensive currency is gone and before the cheap one is committed, which is exactly the wrong way round.
Nothing in the plan shows the profile. The business case carries a constraint total, if it carries one at all. The resource plan shows FTE by team by month. Neither produces the one line that would make this visible: cumulative constraint-hours consumed by this project, plotted against the dates of its own gates. Absent that line the front-loading is invisible, and an invisible profile cannot be reshaped.
None of the four is a mistake in itself. Together they guarantee that your portfolio spends its irreplaceable currency at the moment of maximum uncertainty and its recoverable currency at the moment of least.
A worked example
Numbers make the shape concrete. These are illustrative, but the pattern is one I have watched in organization after organization.
A change portfolio runs everything through a group of seven integration and data engineers. They are the constraint: nothing ships without them, and everything queues for them. Each contributes about 30 productive hours a week once meetings and interruptions are stripped out, across 46 working weeks. That is 9,660 constraint-hours a year, and that figure, not the budget, is the organization's real capacity to deliver change. An hour of that group returns about $1,200 across the portfolio, so annual throughput runs at roughly $11.6 million.
In the year just finished the portfolio started 18 projects. Four of them were stopped or fundamentally redirected after starting. Nobody regards this as a problem, and nobody should: a portfolio that never kills anything is not exercising judgment. The board was praised for it.
The money side of those four decisions was reported carefully.
- Total approved budget across the four: $6.4 million.
- Cash actually spent by the time each decision was taken: $1.9 million, about 30%.
- Returned to the center: $4.5 million, and correctly celebrated.
The capacity side was not reported at all, because there is no form on which to report it. Reconstructed afterwards from timesheets, it reads like this.
- Planned constraint draw across the four projects: 2,600 hours.
- Share of that draw already consumed when the stop decision was taken: 62%, because in every case the integration design, the data mapping and the platform decisions had been completed early, on purpose, to de-risk the project.
- Constraint-hours destroyed: 1,612.
- Priced at $1,200: $1,934,400 of throughput the portfolio will never produce.
Read those two columns next to each other. The 4 decisions spent $1.9 million of cash and destroyed $1.93 million of throughput. The invisible loss was the same size as the visible one. Only one of them was in the paper, and the one in the paper was the one that came back.
Now change one thing, and only one thing. Not the gate criteria, not the ranking, not the stop rate, not the budget. Just the order of work inside the project, so that the constraint's bulk contribution falls after the decision point rather than before it, with only the genuinely decisive early questions answered up front. Suppose that gets the consumed share at the gate down from 62% to 20%.
- Constraint-hours consumed by the four before the decision: 520 instead of 1,612.
- Hours recovered: 1,092.
- Value of those hours: $1,310,400.
- As a share of the portfolio's annual output: about 11%.
11% more delivered value, for no money, no additional headcount, no new tooling, no change to the approval criteria, and no reduction in the number of projects the board stops. The entire gain comes from changing when a particular group of people does a particular piece of work, relative to a decision the organization already knew it was going to take.
The redirection case is larger than the cancellation case
Cancellation is the vivid version, which is why I led with it. It is not the expensive version.
The expensive version is the project that survives with a different answer. The vendor changes. The regulator's guidance is reinterpreted. A second business unit is brought in, so the data model has to become tenant-aware. The channel that the whole integration was shaped around gets descoped. In every case the project continues, its status stays green, and a body of constraint work completed under the previous assumption is destroyed and redone.
Nobody calls this a write-off, because the project did not stop. It appears as a re-baselined date, or as nothing at all. But the hours are just as gone as the canceled ones, and the volume is higher, because redirection is far more common than cancellation. This is the near relative of the scope ratchet: the ratchet describes scope that only grows, this describes direction that changes underneath work already done.
Continue the worked example. The 14 projects that were not stopped drew about 6,900 constraint-hours between them. Nine of those projects had at least one direction change taken after the relevant constraint design work was complete. An honest audit of redo attributable to those changes, and it has to be an audit rather than an estimate, because nobody's timesheet has a code for this, came to about 9% of their draw: roughly 620 hours, or $744,000.
Add it up. 2,232 constraint-hours, about 23% of the year's entire delivery capacity, or $2.7 million of throughput, spent producing answers that the organization itself subsequently decided it did not want. Not wasted through incompetence. Wasted through sequencing.
Why single-project management is blind to this
Two blindnesses stack here, and the second is subtle enough to be worth care, because it is produced by advice that is otherwise correct.
The first is the familiar one. A project's own economics are indifferent to which resource it consumed. A dollar spent on a contractor and an hour spent by the constrained group are both just cost in a business case, so no project manager has ever been asked to account for the second differently from the first. And no project has any incentive to defer its constraint work, because deferring raises that project's own technical risk while the saving lands on a portfolio the project manager is not measured on. The individual optimum and the system optimum point in opposite directions, which is the Project Illusion doing what it always does.
The second is more interesting. Flow Economics itself teaches, correctly, that stop-or-continue decisions should avoid the sunk cost fallacy and look only at value remaining against cost to complete, which is the whole argument of return on remaining investment. That is right, and nothing here contradicts it. At the moment of the decision the 430 hours are gone, and they should have no influence on whether you continue.
But "ignore sunk cost when deciding" gets heard as "sunk cost does not matter", and those are different claims. Sunk capacity is irrelevant to the decision and enormously relevant to the design of the system that produces the decision. How much irreplaceable capacity you have exposed by the time a foreseeable decision arrives is a variable you control, months in advance, for free. A portfolio can be entirely rigorous about ignoring sunk cost at the gate and still be structurally wasteful, because it never asked how much would be sunk by the time the gate arrived.
What to do instead
1. Ask every business case for a constraint curve, not a constraint total. Six numbers will do: cumulative constraint-hours expected to be consumed by the end of each phase, with the gate dates marked on the same timeline. This costs the author an hour, and it is the single artifact that makes front-loading arguable. If the profile cannot be produced at all, that is itself a finding, and the answer is almost never that the draw is even.
2. Move the gate to where the capacity exposure is, not where the money is. The useful rule is mechanical: no phase that will consume more than about 15% of a project's total constraint budget begins without an explicit continue decision taken shortly beforehand. Some portfolios will find this means adding a gate. More will find it means moving one that already exists a few weeks earlier, which costs nothing and changes the price of every subsequent reversal.
3. Buy the killing information with hours you can replace. For each project, name the one or two questions whose answers could stop it or turn it: is the platform capable, will the vendor survive diligence, does the regulator read it our way, will anybody actually use this. Then answer those questions with capacity you can purchase, which means a spike by a non-constrained team, an external firm, a supplier proof of concept, a prototype, a paid assessment. The point is not to avoid early work. It is to avoid spending the one currency you cannot refund on the questions most likely to change the answer.
4. Defer volume, never defer decisions. This is the distinction the whole approach rests on. The decisions only your constrained specialists can make, which pattern, which platform, which model, cost hours of thought, and those hours should happen early, because everything downstream depends on them. The volume that follows those decisions, the detailed integration build, the implemented data model, the environment work, is where the hundreds of hours sit, and that is what moves to the far side of the gate. Early decision, late build. A design that is settled but not yet constructed is exactly the position a portfolio wants to be in when it changes its mind.
5. Cap and meter pre-approval constraint time. In the worked example the constrained group spent about 700 hours a year on shaping, feasibility and estimating for candidates, and a little under half of those candidates were never approved: 315 hours, roughly $378,000, entirely exposed and entirely unrecorded. Set that draw as an explicit annual allowance, publish it in hours, and make sponsors spend from a fixed pool rather than from the group's goodwill. A sponsor who has to spend from a capped allowance to have an idea assessed will bring you better ideas.
6. Report one number a year. Constraint-hours destroyed by stops and direction changes, priced at your value per constrained resource hour, presented next to the cash those same decisions released. The two figures belong on the same page, because they came out of the same decisions. This is the two-ledger discipline applied to reversal rather than to saving, and it works for the same reason: nothing changes behavior like a number that has a trend.
One clarification, because it looks like a contradiction and is not. Full kit says do not start a project until the inputs for it exist. This piece says move the constrained group's bulk work later inside a project. They answer different questions. Full kit governs whether to start at all. Sunk capacity governs where inside a started project the scarcest hours land. A project that has full kit and front-loads its constraint draw is simply a project that will be stopped expensively.
The objection you are already forming
"You are telling me to leave the architecture until late. I have spent my career watching projects fail for exactly that reason, and the rework will cost me more constraint-hours than your sequencing saves."
It is the right objection and it has a numerical answer, so let us work the numbers rather than trade convictions.
Suppose you move H constraint-hours from before the gate to after it. If the project proceeds, which happens with probability 1 minus p, deferral costs you an inefficiency premium: the work is done with less settled context, or in a slightly worse order, at a penalty of r times H. If the project is stopped or redirected, which happens with probability p, deferral saves the whole of H. Deferring is worth it when r is less than p divided by 1 minus p.
Put the worked example's own numbers in. 4 of 18 projects stopped or turned, so p is about 0.22, and p over 1 minus p is about 0.28. Deferral pays whenever the penalty for deferring is under roughly a quarter. A 28% rework premium on deferred integration work is a very large penalty, far larger than reordering usually incurs, so in this portfolio almost every available deferral is worth taking. Run the same sum with your own stop-and-redirect rate before you accept or reject the argument, because if yours is one in 20 rather than one in 5, the inequality tightens to about 5% and the objection wins.
There is also a case where the objection wins outright regardless of the rate. Where feasibility is genuinely unknown, where nobody can say whether the thing can be built at all, r is not 28%, it is enormous, because discovering the answer late invalidates everything downstream of it. Spend the constraint's hours early in that case, without apology. But spend them on the question and not on the volume: a two-week proof, scoped and time-boxed, is an option premium worth paying. 6 months of completed integration design before anybody has tested the commercial assumption is not a risk reduction, it is an unhedged bet placed in the only currency you cannot replace.
The last part of the objection is about people rather than numbers. Constrained specialists mostly do not enjoy working this way. Settling a design and then handing the construction of it to somebody else, in slices, months later, is less satisfying than building the thing properly in one continuous pass, and your best engineers will tell you so. That is a real cost, and it deserves acknowledging rather than managing away. It is also the same trade this discipline keeps asking for: smaller batches are less satisfying than big ones, limiting work in progress feels like under-using good people, and both produce more value anyway.
What changes when you get this right is not the number of projects you stop. It is that stopping stops hurting. A portfolio that owes 20% of a project's constraint draw at the gate can change its mind cheaply, and a portfolio that can change its mind cheaply will do it earlier, more often, and on better evidence. That is the second-order gain, and it is worth more than the hours. Expensive reversals do not merely cost capacity, they teach a board to postpone reversals, and there is nothing in a portfolio more expensive than a decision everybody has already made and nobody has yet taken.
If you have not identified which resource sets your delivery speed, start with How to Find the One Resource That Sets Your Delivery Speed, because none of these numbers exist without it. For the price you put on an hour of that resource, see Value per Constrained Resource Hour. And for the measurement failure that lets a decision like this go unpriced year after year, read The Asymmetric Ledger.
Leave a Reply