The savings that became a project.

Picture a one-page maintenance report from an oil refinery in Lima, Ohio, at the end of 1994. One line stands out: maintenance spending over the past six months is up 30 percent. This is not a healthy refinery. It spent the 1980s cutting costs, it now lags well behind other American refineries, and its owner, BP, has begun to think about selling or closing it.¹ An executive reading that line would reasonably ask who let the costs run away. The number is accurate. It is also the only number on the page, and it does not say what the money did.

What the money did, it later turned out, was begin to rebuild the refinery's ability to keep its equipment running. The report reads the spending as a cost of delivering today's output. The work it paid for was preserving tomorrow's capability. Both are real obligations, and every maintenance budget trades one against the other. My argument is that a saving made by postponing work is incomplete until someone has written down what work was removed, what obligation remains, and what would make waiting stop being acceptable. Repeated postponement does more than delay work. It can consume the very capacity needed to catch up, and that is how ordinary upkeep turns into a recovery program with its own budget line.

This is not an argument for approving every maintenance request. Some deferrals are sensible: cash is short, the asset is close to retirement, or the work really can wait. Some maintenance is waste. The distinction that matters is between an explicit, bounded tradeoff and a saving that is booked without any account of what it will cost later.

An old suspicion, stated carefully

The first essay on this site, Technology is not a toaster, leaned on a study by Bent Flyvbjerg and Alexander Budzier of 1,471 IT projects. The average cost overrun was 27 percent. About one project in six was what they called a black swan, with a cost overrun averaging 200 percent, which means a final cost three times the original budget, and a schedule overrun of almost 70 percent.³ I wrote then that I suspected many of those overruns were the deferred lifecycle arriving all at once, as an emergency migration or a rebuild that should have been a series of upgrades.

That was a guess, and it deserves to be treated as one. The study did not examine causes of that kind. Its sample drew heavily on public agencies (92 percent) and on projects based in the United States (83 percent), although the authors found little difference in the rest.³ A 200 percent overrun describes how bad the tail is. It does not say what put a project there. This essay and the one that follows it try to turn the guess into a mechanism that can be checked. This one is about organizations: how repeated decisions to postpone can wear away the capacity to do the work at all. The next, When everything has to change at once, turns to the technical side, and to what happens when a working system can no longer be changed one step at a time.

How a shortcut becomes a trap

The clearest account of the mechanism comes from Nelson Repenning and John Sterman of MIT, in an article published in the California Management Review in the summer of 2001.¹ Its title borrows a remark they heard from an engineer at a car company: nobody ever gets credit for fixing problems that never happened. Their model starts with a manager who needs more output than the operation is producing. There are two ways to get it. People can work harder, spending more of their time producing. Or they can work smarter, spending time on maintenance and improvement that raise the capability of the process. The second yields the more lasting gain, but it does not improve performance right away, and time spent on it is time not spent producing.

Under pressure, the obvious move is a shortcut: skip the scheduled maintenance, postpone the improvement, and put the hours into output. The shortcut works, at first. Capability does not collapse the day the maintenance is skipped. Supervisors who defer preventive work, the authors write, "often experience a 'grace period'" during which output rises and nothing seems to go wrong. They call this better before worse. Then the equipment and the processes erode, breakdowns rise, corrective work eats more of the day, and there is even less time for prevention. The loop that should reinvest in capability runs in reverse. That is the capability trap. Getting out of it runs the other way, worse before better: spending more time on improvement lowers output in the short run, which is exactly when pressure to stop is greatest.¹

The next step is my reasoning rather than the paper's. Consider what catching up requires. The people who would do the preventive work are usually the same people answering the breakdowns. Much equipment can be opened only during a planned shutdown, and those windows are scheduled long in advance. So the backlog of postponed work competes for the two scarce things the emergencies also consume: skilled hours and access to the equipment. Each round of deferral does not merely add an item to a list. It adds an item while shrinking the capacity to work through the list. That is the precise sense in which a saving can become a project. At some point the backlog is larger than anything the ordinary budget can absorb, and someone has to fund the recovery as a program in its own right.

Figure 2 makes the competition visible with an invented team and an hour budget that never changes. Slide hours from prevention to delivery and watch the quarter improve. Then look at two possible later quarters, one where waiting stayed cheap and one where it did not.

Notice what the figure does not claim. In the left-hand later quarter, waiting cost nothing, and the move was the right call. Nothing in the model says which world you are in. That depends on the equipment, the system and the work, and it is the thing a deferral decision should try to find out rather than assume.

What the Lima case shows

As Repenning and Sterman tell it, Lima shows both directions of the loop. Cost cutting through the 1980s set off a vicious cycle of more breakdowns, higher maintenance costs and less planned maintenance. In 1994 the refinery began an improvement program built around workshops in which employees worked through the dynamics of maintenance for themselves. It was not a top management initiative; it began with an equipment specialist, a maintenance training supervisor and an engineer, and eventually 80 percent of employees took part. In the first six months, maintenance costs rose 30 percent. In January 1996 BP announced that it intended to sell the refinery, and a few months later that it would close it, having found no buyer at a satisfactory price.¹

The program kept going. The authors report that pump mean time between failures rose from 12 months to 58, and that pump failures fell from more than 640 in 1991 to 131 in 1998. In July 1998 Clark USA agreed to buy the refinery for $215 million and keep it running.¹

Be careful with those numbers. They are case results, which the authors assembled from company presentations and correspondence, not the output of a controlled evaluation. They do not show that the program alone rescued the refinery, and the paper's aggregate return figures should not be read as a forecast for anyone else's maintenance budget. What the case does show is the shape of the decision. The 30 percent was the first visible result of a recovery, and on its own it looked exactly like a failure of cost control.

Between knowing and doing

Recovery takes more than recognizing the problem. The US Chemical Safety Board's final report on the fire at Chevron's refinery in Richmond, California, on August 6, 2012, shows how sound technical judgment can fail to become completed work. A pipe carrying hot gas oil had been thinned by sulfidation corrosion, a damage mechanism that attacks carbon steel faster when the steel has little silicon in it. When the pipe ruptured, the release engulfed 19 Chevron employees, who escaped, and approximately 15,000 people from the surrounding communities later sought medical treatment.²

The board found that in the ten years before the fire, a small number of Chevron staff had repeatedly recommended inspecting every component of such lines or upgrading them to a more resistant alloy, and that the recommendations were not implemented effectively. Requests to replace the line were denied under the criteria that governed what went into a planned shutdown. No high-level manager was assigned responsibility for the corrosion initiative, so it fell to lower-level employees who lacked decision-making or funding authority. The refinery's dashboard tracked 26 process safety indicators but not whether these recommendations had been carried out. Among the board's recommendations was an auditable process for turnaround work that is denied or deferred, with a way to raise it to higher management.²

Notice what the report does not say. It does not describe a finance executive turning down a request for money, and it does not put a figure on a saving. The failure it documents lies in the path between expertise and completed work: who owned a recommendation, who tracked whether it was done, and who had the authority to put it into the shutdown plan. That path is the part of the problem most organizations can fix without anyone spending more.

The same choice in technology

In technology the tradeoff arrives every budget cycle, usually as a postponed upgrade. Suppose a team is asked to delay moving a customer database to a supported version so that its engineers can finish a product launch. That can be the right call. The launch is today's output, and it pays for everything else. McKinsey consultants Vishal Dalal, Krish Krishnakanthan, Björn Münstermann and Rob Patenge offered a vocabulary for what the delay costs. Technical debt has a principal, the work needed to modernize the stack, including deferred maintenance and upgrades, and an interest, the complexity tax every project pays today through fragile integrations and workarounds.⁴ They added that the goal is not zero debt, because getting there would mean spending everything on remediation rather than on what sets a company apart. That is the right attitude. Their vocabulary is a way to talk, though, not an accounting measure. Nobody can read the principal off a balance sheet.

What the decision needs is a record. Here is a short one I propose for postponing consequential work. It is my suggestion, not a form used at BP, Chevron or anywhere I have worked.

1. Work postponed. The deliverable and what in the business depends on it: "move the order database to the supported release," not "IT modernization."
2. Benefit of waiting. The cash preserved, the people freed for another commitment, or the disruption avoided, for a stated period, with the alternatives considered.
3. Conditions that make waiting acceptable. The support arrangement, the workload assumed, the recovery arrangements, and the expertise still available.
4. What waiting may change. The size of the later job, extra intermediate steps, or the availability of people and suppliers. Mark what is unknown as unknown.
5. Trigger and owner. The event or date that reopens the decision, and the role accountable for reopening it.
6. Evidence of closure. Completion, deliberate retirement, or a renewed decision with updated evidence.

The last field does the most work. Repeated postponement should leave a visible history, because the third renewal of the same deferral is a different decision from the first, made with less capacity and less time. The record should be short enough that people actually fill it in, and it belongs on consequential obligations, not on every low-risk patch. A cash crisis can justify waiting. The record turns that from a drift into a decision, with a consequence and a date attached.

Making recovery testable

Lima's 30 percent is also a warning in the other direction. A rising maintenance bill can mean recovery, or it can mean a program that spends without fixing anything. The two look alike for months, and the people running the program have every reason to say they are still in the worse part of worse before better. So before granting a recovery program the patience it asks for, agree on evidence other than spending. The age of the oldest critical items in the backlog should fall. The share of hours going to planned work rather than emergencies should rise. Restoration should be demonstrated: the pump that kept failing runs, the restore of the old database is tested. Specific, named risks should be closed. These are my proposed tests, not validated predictors, and the right ones differ by setting. Whatever they are, write down in advance what result would trigger a redesign or a stop. Activity is not evidence. A busy recovery team is the one thing every recovery program can show.

Objections, considered

Cash preserved today can keep the business alive. Agreed, and sometimes it is the only thing that matters. A company that runs out of money does not get to maintain anything. The argument here is not that maintenance always wins. It is that the choice should compare the consequences of spending and of waiting, liquidity included, and leave a decision someone can review.

A rising maintenance budget can mean poor execution. Also agreed, which is why the previous section exists. A recovery story earns credibility through milestones and stopping rules that are set before the money is spent, not through the size of the bill.

Preventive maintenance can itself be wasteful. It can. Replacing parts on a calendar regardless of their condition is not the same as maintaining capability, and some prevention prevents nothing. The record is meant for work tied to a known failure mechanism and a real consequence, not for every item on a schedule.

Refineries are not software systems. True. Pipes corrode and pumps wear in ways that code does not, and the failure rates of industrial equipment say nothing about databases. What carries over is the allocation problem, finite skilled hours split between output and upkeep, and the accountability problem, the path from a recommendation to completed work. The corrosion stays in the refinery.

These cases were chosen after the outcome. They were, and hindsight makes every warning look obvious. Lima and Richmond are illustrations of a mechanism, not a sample from which to estimate how often deferral ends badly. The fair test is what the decision-makers could have known at the time. At Richmond, the board found that the people closest to the pipe did know.

This just shifts the blame from IT to finance. It should not. A finance committee cannot weigh a request that says only "modernization needed." Shared responsibility means technical teams supply the clarity, the operating constraints and credible estimates, and someone with authority owns the decision. A vague request is not a business case, and a rejected vague request is not a villain.

A saving is incomplete until we know what it makes harder to do later.

Before the next saving is booked

• Which obligation remains after the saving? Name the work postponed and what depends on it, in words a board member could check.
• What would tell us waiting has become unsafe or uneconomic? A trigger written down now, not discovered in an outage.
• Who has the authority and capacity to act when that happens? One accountable role, with the hours and the access to do the work.
• If we are recovering, what will show it is working? Evidence other than spending, and a point agreed in advance at which we redesign or stop.

Back to the report from Lima. The 30 percent line is still true. What it needed beside it was a second column: the planned work completed, the repeat failures that stopped, the pumps that ran longer. In the case, those numbers arrived years later, and only because the people running the program kept going through a report that looked like a failure. A board does not have to wait years for them. It can ask for that second column the first time the maintenance bill goes up, and for the deferral record the first time it goes down.