Your Resource Constraint Is Probably a Policy

Your risk log has a line in it that reads something like this: resource constraint, architecture review, insufficient capacity to meet demand in the second half. It has been open for three quarters. It is reviewed monthly, it is rated amber every time, and the mitigation column says that a business case for two additional architects is in preparation.

Every word of that line is true. It is also, in most portfolios I have taken apart, describing the wrong thing, and the error is not in the arithmetic. It is in the word insufficient, which treats the shortfall as a fact about the resource when it is usually a fact about the rules the resource works under.

Here is the distinction the line cannot express. Some of the demand on that team is there because the work genuinely requires an architect. The rest is there because somebody wrote a rule 10 years ago saying an architect has to be involved, and nobody has revisited it since. Both kinds of demand arrive in the capacity model as identical hours. Only one of them can be removed this month, for almost nothing, by a person with the authority to change a sentence.

What is a resource constraint, and what is it not?

A resource constraint is any limit on the availability of a person, skill, team, asset or approval that caps how much work a portfolio can complete in a period. It is not a limit on what you would like to do, and it is not a busy team. It is the specific point at which committed demand exceeds available supply, so work begins to wait.

That definition has a consequence most constraint registers ignore: a resource constraint is a relationship between two quantities, not a property of one of them. Demand over supply. You can relieve it from either side. Organizations behave as though only the supply side exists, because the supply side is the one with a budget line, a job description and a recruitment process attached to it.

The theory of constraints has drawn this distinction for decades, and it is worth restoring. A physical constraint is real scarcity: five architects, and a sixth would have to be found, paid and trained. A policy constraint is manufactured scarcity: five architects doing work that a rule, a threshold, a template or a habit sends to them and need not. From inside the capacity model the two look the same. From outside, their prices differ by two orders of magnitude.

So the useful question is not whether you have a resource constraint. You do, and in Flow Economics language the one that governs your delivery speed is simply the constraint, the resource whose capacity, rather than anyone's effort, sets the pace at which the whole portfolio completes work. The useful question is what a released hour of that resource costs you by each available route, priced against what an hour of it returns. That return is your value per constrained resource hour, the portfolio value produced per hour of the constrained resource, and it is the number that makes every route comparable. Once both sides are in dollars, a rule and a recruitment campaign have to compete on equal terms, and they rarely finish in the order the risk log assumed.

Is your resource constraint physical or is it a policy?

Four questions separate the two, and they take about an hour to answer for any candidate resource. Ask them about the work in front of the team, not about the team.

1. Who requires this person specifically, and where is that written down? If the answer is a named standard, a gate checklist, a template field or a delegated authority schedule, you are looking at a policy. If the answer is that nobody else could physically do it, ask the next question anyway, because that answer is wrong more often than it is right.

2. What proportion of the incoming work is below the size at which the review changes any decision? A review applied to every item regardless of value is a review calibrated for the largest item, and the small items pay full price for it. This is the same mechanism that makes the sub-threshold portfolio so expensive.

3. If a competent person one level down did this and the constrained resource spot-checked one in five, what would actually go wrong? Write the answer as a specific failure with a cost attached, not as a category of risk. Most of the time the honest answer is a small, recoverable loss that the organization is currently insuring against at several hundred dollars an hour.

4. How much of the team's time goes on producing artifacts nobody downstream opens? Ask the recipients, not the producers. This is the largest single source of policy demand I find, and it is invisible to the producers by construction.

Anything that fails those questions is not a shortage of architects. It is a shortage of decisions wearing the costume of a shortage of architects, and it has been wearing that costume for as long as the register has been open.

What does it cost to release one hour of the constrained resource?

Every route to relief reduces to one number, and putting all of them in that number is the point of this article. Call it the relief price: the cash you spend to release one hour of your constrained resource for a year, counting the hours the relief itself consumes.

relief price = cash cost of the relief, divided by the net constraint hours it releases

Two details make it honest. First, net. A relief that releases 600 hours and consumes 90 in the building of it releases 510. Hiring is the worst offender here, because a new starter consumes the existing team's time before returning any of their own, which is the subject of the hiring dip. Second, for a year. Some reliefs are one-off spend against a permanent gain, which makes them better in every year after the first. Say so explicitly rather than hiding it in an average.

The relief price is useful because it is a single figure, in dollars, comparable across routes that no governance process currently compares. A recruitment case, a policy change, a tooling purchase and an outsourcing arrangement are prepared by four different functions, on four different forms, on four different timescales, and are never laid side by side. Put them all in dollars per released hour and they can finally be ranked against each other, and against the value of an hour.

A worked example: four ways to relieve the same team

The figures below are illustrative, but the shape is one I have watched play out repeatedly.

A mid-sized insurer, Calder, runs its change portfolio through five solution architects. No project passes a design gate without them. Each architect contributes about 30 productive hours a week once meetings and interruptions are stripped out, across 46 working weeks: 6,900 constraint hours a year. Across the portfolio an architect hour returns about $980 of value, so this team is the throttle on roughly $6.8 million of annual delivery. They are the constraint, and the risk log has identified them correctly.

Four routes to relief exist. Only one of them has ever been written up.

Route A, hire two more architects. Fully loaded, $145,000 each, so $290,000 a year, permanently. In year one the 2 new architects reach about 60% output, which is 2 x 30 x 46 x 0.6, or 1,656 hours, and onboarding them consumes about 250 hours of the existing team. Net release: 1,406 hours. Relief price: $206 an hour in year one, falling to about $105 once they are fully productive.

Route B, put a threshold on the design gate. Last year 240 changes passed the gate. About 150 of them were small, and each consumed roughly 6 hours of architect time in preparation, attendance and write-up. Not one of those 150 reviews changed a design decision. Exempting changes below a defined size, with a quarterly sample audit, releases 900 hours. Cost: a governance manager's time to draft the rule, plus one board paper. About $3,500. Relief price: $4 an hour.

Route C, delegate the standard patterns. Around 620 hours a year go on designs that repeat a pattern the team has already approved a dozen times. Writing those patterns into a catalog that senior engineers apply without a review costs about 90 architect hours and no cash at all. Net release: 530 hours. Relief price: $0 an hour, paid for in the currency it releases, and self-financing inside about 8 weeks.

Route D, buy the modeling tool. $85,000 to license and implement, and it removes about 300 hours a year of documentation work. Relief price: $283 an hour in year one, and much better afterwards.

Four routes to relieving the same constrained team of five solution architects, each drawn as a horizontal bar of architect hours released in year one with the cash cost per released hour printed to the right. Delegating standard patterns to a catalog releases 530 hours at zero dollars an hour. Putting a threshold on the design gate releases 900 hours at four dollars an hour. Hiring two more architects releases 1,406 net hours at 206 dollars an hour. Buying a modeling tool releases 300 hours at 283 dollars an hour. The two cheapest routes are both policy changes, and together they release 1,430 hours, slightly more than the two hires, for 3,500 dollars of cash rather than 290,000 dollars a year.
One resource constraint, four prices for relieving it. The two routes at the top were never written up, because neither needed a budget and so neither had a process to travel through.

Now read the two policy routes together, which is how they would actually be taken.

  • Routes B and C release 1,430 hours between them, which is 21% of the organization's annual capacity to deliver change.
  • At $980 an hour, that is about $1.4 million of throughput a year.
  • Total cash required: $3,500, plus 90 hours of the constrained resource's own time.
  • Taken together they release slightly more capacity in year one than the 2 hires do, and they land in about 6 weeks rather than about 9 months.
  • The recruitment case, at $290,000 a year, was the only one of the 4 that anybody had written down.

None of this is an argument against hiring. At $206 an hour against a $980 return, Route A is a good investment and Calder should make it. The point is the order, and the honesty. Calder spent 14 months failing to get 2 hires approved in a flat-budget year, while a threshold rule that released two-thirds as many hours for the price of a board paper sat unwritten, because the organization has no process for a relief that does not cost anything. A governance machine built to scrutinize spend has nothing to say about a route that requires none.

Why single project management is blind to this

Ask which project should have proposed the threshold rule, and the question answers itself.

The rule sits above every project and inside none of them. Any single project that challenged the design gate would be spending its own political capital, in its own gate review, to release hours that would mostly go to other people's work. Its own share of the 900 hours is about 6. So the rational move for each project manager individually is to comply with the rule, absorb the 6 hours, and complain about architecture capacity in the monthly report, which is exactly what all of them do.

This is the Project Illusion in its governance form: the assumption that a portfolio is a set of independent projects, so that managing each one well manages the whole. Under that assumption, policy demand on shared capacity is nobody's item. It is not a project cost, it appears in no business case, and it has no owner, which means nothing in the system has an interest in removing it. The constrained resource, meanwhile, can see the entire pattern clearly, because all of it lands on them, and has authority over none of the rules generating it. The information and the authority sit in different places, permanently, and the register writes the result down as a capacity problem.

There is a second blindness worth naming. A per-project view cannot see that relieving a resource which is not the constraint returns nothing, so policy reliefs get spread evenly across teams in the name of fairness and the return evaporates. Releasing 900 hours from a team that is not the constraint moves no delivery date at all, which is the argument of the non-constraint trap. Relief has to be aimed, and aiming it requires a portfolio view.

What to do instead

1. Split the register in two. Go through every line recorded as a resource constraint and mark it physical or policy, using the four questions above. Do it in a room with the constrained resource present, because they know which of their work is required and which is ritual, and nobody has ever asked them to separate the two. Expect the split to surprise the people who own the rules.

2. Price every candidate relief in dollars per constraint hour released, net. One number, one line, on the same page for every route. If your organization does nothing else from this article, this alone will reorder its next capacity decision, because it will be the first time the free routes and the expensive routes have been compared at all.

3. Publish what an hour of the constrained resource is worth, and defend it. You cannot judge a relief price without it. Calculate your value per constrained resource hour once, approximately, and publish it. Approximate is enough: every decision in the example above holds at any value above about $290 an hour, and yours is almost certainly higher than that.

4. Give policy reliefs an owner and a date, the way you would a project. This step is always skipped, and skipping it is why the free routes stay untaken. A relief that costs nothing has no budget, no sponsor and no gate, so it has no forcing function either. Name a person, name the date the rule changes, and put it on the portfolio board's agenda next to the spending items. Free is not the same as easy.

5. Spend the released hours on purpose, in advance. Released capacity is worth nothing until something valuable occupies it, and by default it will be occupied by whatever arrives loudest. Before taking a relief, name the work the hours will go to from the top of your ranked queue, and record which delivery date moves as a result. A benefit nobody has to defend afterwards is a benefit nobody will realize.

6. Set an expiry date on every rule that draws on the constraint. Calder did not have 150 pointless reviews because anyone decided to have them. It had them because the rule requiring them never expired while the organization around it changed. Any standard, gate, template or sign-off that consumes constrained capacity should carry a review date, and at that date the burden of proof belongs to the rule, not to the person questioning it.

The objection you are already forming

"These rules exist for a reason. The design gate went in after a bad year, and the reason we have not had that kind of failure since is that an architect looks at everything. You are proposing we remove a control and book the saving as a benefit."

That is the right objection, and it deserves a precise answer rather than a reassurance. Three things.

First, a control has a price, and a control paid for in constrained capacity is expensive in a way no control document records. Calder's design gate costs 900 hours a year on small changes, which is $882,000 of throughput annually. That may well be worth paying. But it has never once been presented as an $882,000 control, so nobody has ever been asked whether it is. Pricing a control is not the same as removing it, and pricing it is all that step two asks for.

Second, the alternative to a universal review is almost never no review. It is a review calibrated to what is at stake: a threshold, a sample audit, a delegated approval with a spot check, a pattern catalog that encodes the architect's judgment once instead of re-enacting it 150 times. Every one of those keeps the control. They differ only in how much of your scarcest resource they consume in order to deliver it.

Third, if the control genuinely is load bearing at every size, keep it, and then say the true thing out loud: the organization has chosen to spend 13% of its delivery capacity on assurance, deliberately, with the figure known. That is a legitimate choice, and I have seen regulated portfolios where it is the correct one. What is never legitimate is spending that capacity without knowing the figure, which is the default, because the cost shows up as delay spread across 14 projects while the control shows up as a line in a standards document.

The habit worth breaking is the one that treats a resource constraint as a fact of nature. It almost never is. It is the sum of a real scarcity and an accumulated set of decisions, most of them sensible when they were made and none of them revisited since, and those two parts have wildly different prices. An organization that can tell them apart gets a fifth of its delivery capacity back for the cost of a few meetings. An organization that cannot spends 14 months on a recruitment case instead, and reports the constraint as amber while it waits.

If you have not yet established which resource sets your delivery pace, start with How to Find the One Resource That Sets Your Delivery Speed, because a relief aimed at the wrong resource returns nothing however cheap it was. For the number that makes relief prices comparable, see Value per Constrained Resource Hour. And if you want to know what the waiting is costing while the decision sits open, Drag Cost puts a weekly price on the delay that amber register entry is already producing.

Ben Rawson

Ben Rawson is the founder of Flow Economics and co-author, with Albert Ponsteen, of the forthcoming Flow Economics: The Missing Layer Between Strategy and Delivery. More about Ben


Leave a Reply

Your email address will not be published. We use it only to send you one link to confirm your comment, so no fake or automated comments appear here. It does not sign you up for anything.