The Program Has A Budget And No Builder

The program was announced with a name, and the name is doing more work than it appears to. It signals to the board that the operating problems are being addressed in an organized way, it gives the executive team a place to send difficult items, and it justifies a budget that has already been approved.

Over the trailing twelve months, SEC full-text search returns 17 filings describing an operational excellence program and 9 describing a digital transformation initiative. Those are filings rather than companies, and the counts are small because most programs of this kind are described in other words or not described publicly at all. The shape underneath is common.

A program of this type is assembled from a predictable set of parts: an executive sponsor, a steering committee, a small program office, several workstreams with named leads, an outside adviser, and a schedule of readouts. Every part is there to decide, coordinate, or report. None of them builds anything, and that absence is not visible until the first readout produces its recommendations.

The Recommendations Sort Into Three Piles

Within a few months the program produces its findings, and they divide reliably into three groups with very different fates.

The first two piles are why programs of this kind are worth running. They are real, they are cheap, and the organization already contains the people who execute them.

The third pile is the one the program was not designed for. Each item in it needs somebody to write software against a process that only exists inside your company. The information technology group owns the enterprise system, the network and the endpoints, and building new internal applications has never been its function. The outside adviser produced the recommendation and does not implement it. The workstream lead owns the outcome and has an operations team, not engineers.

A recommendation with no builder is not scheduled. It is described, and being described is what allows it to move to the next quarter without anyone noticing.

Why The Software Pile Is Assumed To Be Large

There is a good reason executives at this size flinch at the third pile, and it deserves to be stated fairly rather than dismissed.

The study of information technology project risk (Flyvbjerg & Budzier, Harvard Business Review, 2011) examined 1,471 projects and found an average cost overrun of 27%, with one in six projects carrying a cost overrun of 200% on average and a schedule overrun of almost 70%. The distribution has a long tail, and anyone who has lived through an enterprise system implementation has met it. That experience becomes the reference class for every software item afterwards, including items that are nothing like it.

The distinction that matters is scope, not technology. The projects in that tail share a set of properties: many stakeholders, a scope that changed after approval, a dependency on replacing something that currently works, and a duration long enough for the sponsoring executive to change. An item from the third pile — one workflow, one executive owner, a defined start and end, built beside the systems you already run — has none of those properties. It is a different risk class, and pricing it as though it belonged to the first one is how the pile stops moving.

The way to keep it in the smaller class is to refuse to combine items. Programs create pressure to bundle, because a bundle is easier to approve once and easier to report on. A bundle of five small builds is a large build, and it inherits the risk profile of the thing everyone was afraid of.

The Value Is In The Practice Adopted, Not The Plan Produced

There is good evidence that management practice is worth money, and it is worth being precise about what the evidence measures.

Management practices vary enormously across firms and correlate strongly with performance (Bloom & Van Reenen, Quarterly Journal of Economics, 2007), which is the finding programs of this kind are built on. But the causal experiment is more instructive. A randomized trial providing management consulting to textile plants (Bloom, Eifert, Mahajan, McKenzie & Roberts, Quarterly Journal of Economics, 2013) raised productivity by roughly 17% in the first year — and the intervention was not a diagnostic. Consultants worked inside the plants until specific practices were actually adopted and running. The return came from the change in operation, not from the recommendation.

The same distinction appears in the productivity literature at the level of whole technologies. The productivity J-curve (Brynjolfsson, Rock & Syverson, American Economic Journal: Macroeconomics, 2021) describes how general purpose technologies require substantial complementary investment — process change, new systems, retraining — before measured productivity moves, so returns appear late and understate the value being built. Programs typically fund the plan and the coordination, and leave the complementary investment to be found inside existing budgets, which is where it stops.

Leading change (Kotter, Harvard Business Review, 1995) named a version of this failure a generation ago: declaring victory on the announcement rather than on the change in operation. The modern form is a program that reports green on every workstream while the pile of unbuilt items grows quietly underneath it.

Fund One Item Separately And Watch What Happens

The practical move is not to reform the program. It is to take one item out of it and treat that item as its own commitment, with its own price, its own date, and its own measure.

There are three reasons to do this rather than adding a build workstream. It is faster, because it does not wait for the program's cycle. It is a real test, because a single item either works by a date or does not, and the answer arrives while the program is still running. And it produces the evidence the program itself lacks: a before and after number for one process, measured the same way twice.

Choose the item using the criteria the program does not apply. One executive owner. A boundary the item does not cross. A place in the path where something is committed — an approval, a handoff, a record — rather than a place where something is reported. And a current cost that people can feel weekly rather than one that has been modelled. If the item's current cost cannot be counted because nothing in the process records its own state, that is not a reason to skip it. It is the first thing the build fixes.

First Steps

1. Take the program's recommendation list and write a name beside each item. The person who would do the work, not the department that owns the outcome. Items with no name are the third pile, and they are the whole subject.
2. Sort that pile by recurring cost, not by size. The item worth doing first is usually small and expensive to keep living with, and it is rarely the one at the top of the program's own priority order.
3. Price the top item on its own, before the next steering committee. A separate price and a separate date are what keep it out of the bundle, and the bundle is what makes it large.

One Item, Priced Before The Next Readout

A program is a good way to decide what should change and a poor way to make software exist. Those are different capabilities, and no amount of governance converts one into the other.

A fifteen-minute call — nothing paid, nothing signed — takes a single item from the pile apart: what the process does today, what it would do instead, what has to be built, what it costs, and what it will be measured against. If the honest answer is that the item does not need software, that is what we will say and the item leaves the pile.

Where something has to be built, that work runs as a monthly engineering partnership, with the targets for each release agreed before it starts, including what happens when something goes wrong. One workflow at a time, never a bundle. The work runs in a repository we own, and paid-for deliverables transfer to you monthly — full history and documentation. After that, $15,000 a month puts one accountable person on keeping it running, with a written monthly report of what ran and what changed — which is a better readout than the one the workstream currently produces.

References

1. Flyvbjerg, B., & Budzier, A. Why Your IT Project May Be Riskier Than You Think. Harvard Business Review, 2011.
2. Bloom, N., & Van Reenen, J. Measuring and Explaining Management Practices Across Firms and Countries. Quarterly Journal of Economics, 2007.
3. Bloom, N., Eifert, B., Mahajan, A., McKenzie, D., & Roberts, J. Does Management Matter? Evidence from India. Quarterly Journal of Economics, 2013.
4. Brynjolfsson, E., Rock, D., & Syverson, C. The Productivity J-Curve: How Intangibles Complement General Purpose Technologies. American Economic Journal: Macroeconomics, 2021.
5. Kotter, J. P. Leading Change: Why Transformation Efforts Fail. Harvard Business Review, 1995.
6. U.S. Securities and Exchange Commission. EDGAR Full-Text Search. Filing counts cited are from full-text search over the trailing twelve months.