Whether a new system streamlines your operations is decided before you build it

A new system streamlines your operations when it is built well and aimed at the right problem. Most of what decides the outcome happens before the build: mapping how the work runs, choosing the problems worth solving and getting the team ready to use it. The costliest failures are the wrong route: solving the wrong problem, solving the right problem the wrong way, or building something nobody uses. Before you compare quotes, compare how each option would find out that it was on the wrong route.

Most of the risk in a new system sits before the build

Software is getting faster to build. Google says about 75% of its new code is now generated by AI and approved by engineers, up from 50% in the autumn of 2025.¹ As code gets faster to produce, more of a project’s outcome depends on the decisions made around it.

Most of the time sat outside the code even before AI. Bain estimates that writing and testing code takes about 25–35% of the time from idea to launch. Teams using AI coding assistants see productivity gains of 10–15%, while some companies report 25–30% by pairing the tools with a redesign of the whole process.²

The build is essential, and it has to be done well. A badly built system fails however carefully it was chosen. In an operations project, the work around the build means understanding how the work really flows, choosing the problems worth solving, redesigning the process, getting the team to adopt the system and measuring what changed. That is the part most companies skip.

A new system’s real cost includes building the wrong thing

Buyers compare fees because fees are visible. The larger costs never appear on the invoice:

• The wrong problem. The money is spent, and the real bottleneck is still there.
• The right problem, solved the wrong way. Months of rework follow, and the team learns to work around the system.
• A system nobody uses. The software is paid for and abandoned.

None of these shows up in a quote. All of them show up in the year after launch.

The odds favor planning slowly and building fast

Bent Flyvbjerg and Dan Gardner drew on a database of more than 16,000 projects for How Big Things Get Done. Only 8.5% came in on budget and on time, and only 0.5%, or 1 in 200, also delivered the benefits promised.³

IT projects miss hardest on value. McKinsey and the University of Oxford studied more than 5,400 IT projects. The large ones, with budgets above $15 million, ran on average 45% over budget and 7% over time, and delivered 56% less value than predicted.⁴

1. Cost over budget45%
2. Time over schedule7%
3. Value below forecast56%

Large IT projects fall furthest short on value

Measure	Average
Cost over budget	45
Time over schedule	7
Value below forecast	56

Source: McKinsey and the University of Oxford, 2012⁴

The risk also sits in a long tail. Flyvbjerg and Alexander Budzier found that 1 in 6 of the 1,471 IT projects they studied was a “black swan”, with an average cost overrun of 200% and a schedule overrun of almost 70%.⁵

These studies cover large projects, and none of them looks at operations systems for companies. Use them for the scale of the risk; they cannot forecast a single project. Their shared lesson is Flyvbjerg’s: plan slowly, while change is cheap, then deliver fast.

A requirement that is wrong before building starts gets paid for twice

Barry Boehm and Victor Basili put avoidable rework at 40–50% of the effort on software projects. Two of its main sources are hastily specified requirements and designs that handle only the normal case.⁶ Every requirement that is wrong when building starts gets paid for twice: once to build it and once to undo it.

The cheapest place to find a wrong requirement is on a screen that is not yet connected to anything. Boehm and Basili note that better systems come from requirements that emerge through prototyping and shared learning. A clickable prototype moves those discoveries to a point where a change costs hours. After launch, the same change costs weeks and some of the team’s trust.

Redesigning the process before automating it multiplies the gain

In 1990, Michael Hammer described how Ford set out to cut the headcount of its accounts-payable department, then more than 500 people, by about 20% with better systems. By redesigning the process itself, it reached a 75% reduction where the new process was in place.⁷

1. Conventional program (planned)20%
2. Process redesigned (achieved)75%

Redesigning the process cut Ford's headcount nearly 4 times as much as the plan

Approach	Reduction
Conventional program (planned)	20
Process redesigned (achieved)	75

Source: Hammer, Harvard Business Review, 1990⁷

Note: The department had more than 500 people. The 75% applies where Ford put the new process in place.

Automating a broken process makes the mess run faster. Remove the steps that should not exist first. Then automate what is left.

Compare options by how they would find out they are wrong

When you weigh a software subscription, a developer, a consultant and an operations firm, ask each the same question: before I pay for the build, how would you find out that we are solving the wrong problem? A good answer involves your team, a map of the real process and something you can click before code is written. A weak answer is a promise.

Then ask who builds the system and who stays until your team uses it. If the answer is a different firm for each step, every requirement has to survive a handover.

Illustration. Three people each spend eight hours a week retyping information between tools, at a loaded cost of $40 an hour, close to what US employers pay per hour for office staff, wages and benefits included.⁸ Over 50 working weeks, that comes to $48,000 a year. A build that automates the wrong step of that process can arrive on time and on budget and still leave most of the $48,000 in place. On paper the project succeeded. The cost it was meant to remove is still being paid.

Put a number on that cost for your own process before you compare quotes. It is the figure every option should be measured against.

Two weeks spent understanding your operations is the cheapest insurance

A 14-day diagnostic exists to remove as much of the wrong-route risk as possible before the build starts. The problem is chosen with the people who live with it. The fix is tried on screen by the team, as a clickable prototype on its own data. The build is priced on evidence instead of guesses.

The same team then builds the system, trains the people who will use it and measures what changed, so no requirement has to survive a handover between firms.

This is the argument of our manifesto, and it shapes how we work. We would rather tell a client not to build something than build the wrong thing well.