The program was announced with a name, and the name does more work than it appears. It signals to the board that operating problems are addressed in an organized way, gives the executive team a place to send difficult items, and justifies a budget already 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 such programs are described in other words or not publicly at all. The shape underneath is common.
Such a program has predictable parts: an executive sponsor, a steering committee, a small program office, several workstreams with named leads, an outside adviser and scheduled readouts. Each part exists to decide, coordinate or report. None builds anything, and the absence is invisible until the first readout produces recommendations.
The Recommendations Sort Into Three Piles
In a few months the program's findings divide reliably into three piles with different fates.
| Pile | Example | What happens |
|---|---|---|
| Policy and organization | Change approval limits, move teams, cut reports | Done, usually in-quarter |
| Procurement | Consolidate vendors, renegotiate, buy a tool | Done, per contract cycle |
| Software | A team handoff stops running on email | Assigned, then carried |
The first two piles are real, cheap, and executed by people the organization already has.
The program was not designed for the third pile. Each item needs somebody to write software against a process that exists only in your company. The IT group owns the enterprise system, the network and the endpoints, and building internal applications has never been its function. The outside adviser does not implement the recommendation. 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
Executives at a company of this size flinch at the third pile for a good reason. 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%. That tail becomes the reference class for every software item, including items nothing like it.
The distinction that matters is scope, not technology. The projects in that tail share four 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. A third-pile item, one workflow with one executive owner, a defined start and end, built beside the systems you run, has none of those properties. It is a different risk class, and pricing it like the first is how the pile stops moving.
The way to keep it in the smaller class is to refuse to combine items. A bundle of five small builds is a large build, and inherits the risk of the thing everyone feared.
The Value Is In The Practice Adopted
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.
Programs typically fund the plan and the coordination, and leave the complementary investment, the process change and new systems, to be found inside existing budgets, which is where it stops. The result is a program that reports green on every one of its workstreams while the pile of unbuilt items grows quietly underneath it.
Fund One Item Separately
The practical move is not to reform the program. It is to take one item out of it and treat it as its own commitment, with its own price, its own date, and its own measure. It is a real test, because a single item either works by a date or it does not, and the answer arrives while the program is still running. And it produces the evidence that the program itself lacks: a before and after number for one process, measured the same way twice.
Choose the item using 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 reported. And a current cost people feel every week rather than one that has been modelled. If that cost cannot be counted because nothing in the process records its own state, that is the first thing the build fixes.
First Steps
- Write a name beside each recommended item. The person who does the work, not the department owning the outcome. Items with no name are the third pile.
- Sort that pile by recurring cost, not by size. The best first item is usually small and costly to live with, and rarely the one at the top of the program's priority list.
- Price the top item on its own, before the next steering committee. A separate price and date 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. They are different capabilities, and no governance turns 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. Paid-for deliverables transfer to you every month, with full history and documentation. Then $10,000 a month puts one accountable person on keeping it running, with a written monthly report of what has run and what has changed, which is a better readout than the workstream produces.
References
- Flyvbjerg, B., & Budzier, A. Why Your IT Project May Be Riskier Than You Think. Harvard Business Review, 2011.
- Bloom, N., Eifert, B., Mahajan, A., McKenzie, D., & Roberts, J. Does Management Matter? Evidence from India. Quarterly Journal of Economics, 2013.
