Limited Budget, Unlimited Demand
Why efficiency gains in internal IT disappear, and the one cost that limits demand while improving the work.
An internal IT organisation receives its budget once a year, and with it an expectation that is rarely written down but always present: next year, more for the same money, or the same for less. The budget is a number. The demand placed on the organisation is not. The backlog grows faster than it is worked off, every request arrives marked as important, and the prioritisation meeting has become the place where disappointment is allocated rather than work. However much the organisation delivers, it is perceived as slow, because what it delivers is measured against what it has been asked for, and what it has been asked for has no upper bound.
This is the ordinary condition of a cost centre. Mary Poppendieck described it plainly: a cost centre is measured on its costs and little else, its budget rarely rises when times are good, and it is the first to be cut when they are not.¹ Inside that frame, the demand side looks like a nuisance to be managed. It is more than that. It is the reason the efficiency the budget holders expect cannot show up where they are looking for it.
Where the gains go
In 1865 William Stanley Jevons argued that it is “wholly a confusion of ideas to suppose that the economical use of fuel is equivalent to a diminished consumption.”² Cheaper use of coal widened the uses to which coal was put, and consumption rose. Transport economists later found the same pattern on roads: adding lanes to congested highways brings more traffic, roughly in proportion to the added capacity, and the new traffic is mostly created rather than diverted from elsewhere.³
The road case is the closer analogy, because of the currency in which the price is paid. A driver on a free road pays in time. Yoram Barzel showed that when a good carries no money price, waiting becomes its whole price, and demand responds to it exactly as it would to a price in money: fall, and more is demanded.⁴ A requester in internal IT is in the same position. Asking costs nothing in money; the only price is the wait. When IT becomes more efficient and delivers more, the wait shortens somewhat, requests that were not worth waiting for become worth making, and the capacity gained is taken up by demand that did not exist before. The wait need not return to where it was. What returns is the full backlog.
The consequence is easy to state and hard to see from above. An efficiency gain can be taken in one of two forms: as lower cost for the same output, or as more output for the same cost. With demand unconstrained, the organisation does not get to choose. The choice is made silently and always in favour of output. And because the backlog does not shrink, the added output is invisible too. Management sees neither the saving it expected nor the extra delivery it received.
The usual response is to defend the budget by arguing for the value of what IT delivers, in business cases, benefit estimates and value scores. That route does not hold, for reasons argued at length elsewhere: the worth of a specific piece of work is a counterfactual no instrument can read, so it cannot serve as the signal that justifies a cost or steers a portfolio.⁵ There is a different lever, and it sits on the other side of the ledger. Instead of justifying the cost, limit the demand. The claim is not that the absorbed demand is worth little. Nobody can know that. The claim is that without a limit the organisation has lost a decision it should own: whether a given efficiency gain is to be taken as cost or as output.⁶
Why nothing limits it
In a market, placing an order is not free. Whoever orders commits to pay on delivery, and that commitment limits demand. It also carries information: a buyer who pays reveals, at least, that the purchase was worth the price to them.
Internal IT is the special case. The requester does not pay, or pays in a way that never reaches them in a feedback loop they perceive. The budget is held elsewhere, the charge, if there is one, lands on a cost centre, and the person who asked for the change experiences none of it. Health economists have a name for the result. When insurance reduces the price of care at the point of service to zero, demand rises wherever it responds to price at all. Mark Pauly called this moral hazard and was careful to add that it has little to do with morals: it is rational behaviour, because each user bears only a sliver of the cost of their own use.⁷ The same holds for the business colleague who files one more request. Nothing about the request is illegitimate. It is simply free.
Pauly also reports an observation of James Buchanan’s about the British National Health Service that fits internal IT uncomfortably well: people demand care as though it were free, yet when they vote on the budget, they provide for less than they demand. An organisation does the same with its IT. The budget is set centrally, with cost in view. The demand is exercised locally, with cost out of view. Both decisions are reasonable where they are made, and they do not add up.
Donald Reinertsen put the requirement into a single principle for product development: “ensure decision makers feel both cost and benefit.”⁸ The internal requester is a decision maker who feels the benefit and not the cost. Demand then does two things. It grows without limit, and it stops carrying the requester’s own estimate of what a request is worth to them, since nothing forces that estimate to be made. Many requests may matter little to those who make them; nobody can tell which.
This is a claim about internal services, and only about them. It does not generalise to markets, where the promise to pay is itself the cost.
Three limiters that miss
Organisations do limit demand, whether they intend to or not. The three common ways each fall short, and the way each falls short points to what a working limiter would need.
The first is the queue. Waiting does limit demand, as Barzel’s analysis requires, but it does so by consuming what it rations. For the marginal person in a queue, the time spent waiting exhausts the entire worth of the good: in his phrase, “If there is a free lunch, it will come to have zero value.”⁹ The queue also selects by the wrong property. Who waits depends on how cheap waiting is for them, not on how much the thing waited for matters. And in IT it rewards a further behaviour: requesting early and speculatively, to hold a place in line for something that may be needed later.
The flow tradition’s answer is admission control. Poppendieck’s advice to firms facing more demand than they can serve is not to accept work faster than the bottleneck completes it, and then to grow capacity to meet the rest.¹⁰ WIP limits at the commitment point do the same inside the system. Both protect flow. Neither limits demand. They move the queue upstream of the point where work starts, and the requester’s price is still the wait. Her second step, growing capacity, is exactly what unconstrained internal demand absorbs. And a firm can turn customers away. An internal IT organisation generally cannot turn away its own business.
The second limiter is a budget or a price. Chargeback bills departments for what they use; showback shows them the cost without billing it. Reinertsen goes further and proposes internal markets to decentralise control, and prices that rise with congestion to push demand out of busy periods.⁸ On roads, where the traffic economists concluded that only congestion pricing is left as a remedy, this works because the driver pays.³ Inside a company it does not, because the money lands on a budget and the budget belongs to someone other than the person asking. A price paid by the cost centre changes the cost centre’s accounts, not the requester’s behaviour. The variant that reaches the requester directly is a quota: Kent Beck suggests giving customers a share of development capacity to use as they please.¹¹ A quota does make each requester ration. But sizing the shares means deciding in advance where capacity will pay off most, which is the same value knowledge that the budget route lacks.
The third limiter is the hurdle: the request form, the business case template, the approval step. Public economics calls these ordeals, deliberately imposed costs that are pure deadweight, accepted because they sort applicants.¹² They filter. But they burn the time they cost, and they sort well only under conditions that, as the next sections show, internal IT tends to violate.
Each of the three either fails to reach the requester or destroys what it charges. A working limiter would need to do neither.
A cost that produces
There is a cost that reaches the requester personally and does not destroy what it charges: the requester’s own active participation in the work. Providing the information the work depends on, clarifying what is meant, taking part in refinement, reviewing early versions and saying what is wrong with them. Time spent this way limits demand, because it is time the requester must find. And it improves the result, because it is spent on the result.
Barzel draws the relevant distinction. A money price is a transfer: what the buyer pays, the producer receives. Time spent in a queue is captured by nobody.⁹ Participation adds a third case. Set side by side, the three mechanisms differ in what happens to the price once it is paid. An ordeal is negative-sum: the time is burned. A price is zero-sum: the money moves from one budget to another. Participation is positive-sum: the price is paid in a currency that raises the worth of what is bought. The comparison has a limited scope and should be read that way. It compares what each mechanism costs the organisation, not how accurately each one separates important requests from unimportant ones. Filtering is a different question, and it is the one on which participation struggles.
Why the time is productive in IT specifically has to do with what IT works on. In product development, the process a product supports usually lies outside the organisation that builds it. In enterprise IT, the work object is a business process running through systems the same organisation owns, and the process belongs to the business.¹³ The two sides then hold different halves of what a change needs. The business knows how it wants to work. IT knows which systems the process touches, how the data flows between them, and which governance and compliance obligations apply, much of which the business never sees. Elinor Ostrom, one of those who developed the concept of coproduction for public services, named the condition under which contributions from two parties produce more than either alone: the inputs must complement each other rather than substitute for one another, so that “each has something the other needs.”¹⁴ In enterprise IT that condition is met by construction. Collaboration is not a courtesy extended to the business. The work cannot be specified without it.
This answers the objection that arrives first: that the business experts are too expensive to spend their time with IT. Their time is a real cost, though a cost to the organisation, not to them. The honest comparison is not with an afternoon saved. It is with building without their knowledge, and with what follows from that. John Seddon calls demand caused by a failure to do something, or to do it right, failure demand, and argues that the greatest lever on a service system is to change the characteristics of its demand.¹⁵ Work built on a guess about intent comes back as rework and follow-up requests. Participation reduces that share. So it limits demand in a second way, not by deterring requests but by removing the ones the organisation creates for itself.
Get Bruno Baketarić’s stories in your inbox
Join Medium for free to get updates from this writer.
None of this makes coproduction a discovery. Ostrom and her colleagues developed the concept in the late 1970s. The Agile Manifesto’s fourth principle holds that business people and developers must work together daily.¹⁶ Beck lists real customer involvement as a practice, with the stated aim of cutting waste by bringing those who have the needs together with those who can meet them.¹¹ What these accounts share is that they treat participation as a benefit, something a customer might even pay for. What is proposed here is narrower: using the cost of participation as the limit on demand, so that the mechanism which constrains how much is asked for is the same one that improves what is built.
Where it breaks
A mechanism proposed as the answer deserves the same scrutiny as the ones it replaces, and this one has a structural weakness. It works through two effects, and they pull against each other.
The limiting effect needs the time to feel costly to the requester. The contributing effect needs the time to be given willingly and competently. A requester who resents the hours participates grudgingly, and grudging participation contributes little: the review is skimmed, the question is answered by whatever is quickest. A requester who enjoys working with IT, or has slack, contributes well and feels no limit. The mechanism works only in the band where the time is costly enough to make people choose and meaningful enough that they do not disengage.
The sorting also runs the wrong way. Albert Nichols and Richard Zeckhauser argued that ordeals sort well when their cost falls inversely with the benefit, so that those who need something most find the hurdle cheapest.¹² A time requirement in IT does the opposite. It is most expensive for the busiest people, and the busiest are often the domain experts with the most consequential requests. Left to itself, a participation requirement deters first the requesters whose participation would help most. And where IT could in fact do the work alone, where in Ostrom’s terms the inputs substitute for one another, participation adds nothing and becomes an ordeal again.¹⁴
Then there are the two ways the cost escapes. The first is delegation. The requester sends someone junior, who has the time but not the knowledge. The limit disappears, because the requester is no longer paying, and the contribution disappears, because the person paying cannot supply it. The second is displacement, and in IT it is the default. The work of clarifying, specifying and deciding moves to a role on the IT side: the product owner, the business analyst, the requirements engineer. In IT that role often slides towards proxy for the business colleagues, and at its extreme towards order taker. Beck is blunt about proxies: working without a customer, or with a stand-in for one, produces waste: features that go unused, and tests that miss what acceptance really requires.¹¹ Displacement preserves the requester’s zero cost by design. It also meets a second obstacle. The role that absorbs the work would need to shape the business process to do it well, and business colleagues typically reject IT influence on how they work. That is Ostrom’s second condition failing: coproduction requires that both parties have real options, and here one of them does not.¹⁴
Last, incentives. Where requesters are rewarded for their “real” work, and their bonus depends on it, every hour spent with IT is an hour taken from what they are measured on. Participation under those terms will be grudging or delegated, whatever the policy says.
The failure-demand effect survives all of this in part, since fewer self-inflicted requests are fewer requests regardless of how willingly anyone participated. But it does not resolve the tension. It only means the mechanism is not all-or-nothing.
Who can install it
Every failure mode in the previous section has the same shape. The mechanism binds the requesters, and IT cannot bind the business. It cannot require business colleagues to participate, it cannot stop them from delegating, it cannot give its own roles influence over business processes, and it has no say over how business colleagues are rewarded. Whatever form the limit takes, it has to be put in place by someone with authority over both sides.
That is the lowest position in the hierarchy where business and IT share a superior. In a divisional organisation with its own IT, it may be the head of the division. In a company with a shared IT function, it is the chief operating officer or the chief executive. The position that can install a limit on demand is, in the typical case, the one furthest from the work.
What that position has to do is specific, and the form matters. Ostrom’s fieldwork includes cases where coproduction withered under top-down command: central authorities took over schools that villages had regarded as their own, ran them by decree, and village contributions dwindled.¹⁴ A decree that the business shall participate would repeat that failure. The top position’s job is to make the requirement binding, so that participation is a condition for work to start, not a favour IT can only ask for; to give both sides real options, including IT’s standing to shape the processes it builds; and to remove the incentives that punish participation. How participation happens is best left to the people doing it.
The same office holds the expectation of yearly efficiency gains, the authority to limit demand, and the incentives that decide whether participation is real. That is the case to take to it. Without a limit on demand, an efficiency gain in IT can only ever appear as more output, never as lower cost, and no amount of value justification will change the arithmetic. With a limit, the organisation can decide which of the two it wants. The limit that serves this purpose best is not a price and not a hurdle. It is the requirement that those who ask for the work take part in it.
¹ Mary Poppendieck, “The Cost Center Trap”, Lean Essays, 5 November 2017, https://www.leanessays.com/2017/11/the-cost-center-trap.html. Her remedy, steering IT by business outcomes, is a form of value steering; see note 5.
² William Stanley Jevons, The Coal Question, 1st ed. (London and Cambridge: Macmillan, 1865), ch. VI, “Of the Economy of Fuel”, p. 103.
³ Gilles Duranton and Matthew A. Turner, “The Fundamental Law of Road Congestion: Evidence from US Cities”, American Economic Review 101(6) (2011), 2616–2652. The authors conclude that neither more roads nor more public transit relieves congestion, leaving congestion pricing as the main candidate remedy (p. 2646).
⁴ Yoram Barzel, “A Theory of Rationing by Waiting”, Journal of Law and Economics 17(1) (1974), 73–95, at p. 75.
⁵ See also “Steering by Value: The Signal That Isn’t There” for why the worth of a bet cannot serve as a control signal.
⁶ See also “Steering by Value: The Only Decision You Control” on the commitment as the one decision fully in anyone’s hands, and why it has to be an owned judgement
⁷ Mark V. Pauly, “The Economics of Moral Hazard: Comment”, American Economic Review 58(3), Part 1 (1968), 531–537, at pp. 532, 534–535. The observation attributed to Buchanan is reported in Pauly’s note 1, p. 533, citing James M. Buchanan, The Inconsistencies of the National Health Service (London: Institute of Economic Affairs, 1964).
⁸ Donald G. Reinertsen, The Principles of Product Development Flow (Redondo Beach: Celeritas, 2009): E14, the First Market Principle (p. 42); F4, the Principle of Congestion Pricing (p. 176); D20, the Second Market Principle (p. 262).
⁹ Barzel, “A Theory of Rationing by Waiting”, pp. 74, 80, 83 (note 16), 87–88.
¹⁰ Mary Poppendieck, “When Demand Exceeds Capacity”, Lean Essays, 11 June 2022, https://www.leanessays.com/2022/06/when-demand-exceeds-capacity.html
¹¹ Kent Beck with Cynthia Andres, Extreme Programming Explained: Embrace Change, 2nd ed. (Boston: Addison-Wesley, 2004), ch. 9, “Real Customer Involvement”.
¹² Albert L. Nichols and Richard J. Zeckhauser, “Targeting Transfers through Restrictions on Recipients”, American Economic Review 72(2) (1982), 372–377, at pp. 376–377.
¹³ See also “The Estate Is Not a Tree”, section “Why this lands on IT”, on why the business process runs inside the enterprise IT estate, not beyond it.
¹⁴ Elinor Ostrom, “Crossing the Great Divide: Coproduction, Synergy, and Development”, World Development 24(6) (1996), 1073–1087, at pp. 1073, 1079–1082; the Nigerian cases at pp. 1076–1078.
¹⁵ John Seddon, Freedom from Command and Control: Rethinking Management for Lean Service (New York: Productivity Press, 2005), pp. 37–38.
¹⁶ “Principles behind the Agile Manifesto”, 2001, https://agilemanifesto.org/principles
