Business Cases Budget the Software and Assume the Change

← Back · ACT III · Chapter 21: Decision Artifacts That Govern Outcomes

The cost of changing how people work rarely appears in an investment case. Written down as conditions the business agrees to meet, it can be staffed and budgeted before approval and checked at the review afterward.

Most business cases are careful about the money they can see. License fees, implementation, the integrator’s hours, a contingency line, and on the other side the savings, phased over three years. Finance tests those numbers, and it is right to.

What the case usually leaves out is the cost of the organization actually changing. Someone has to redesign the work. Some decisions have to move to different people. Output dips while teams learn the new way, and something else has to stop so there is time to learn it. None of that is free, and very little of it shows up on the page the investment committee approves. The case treats it as an assumption, as if the organization will absorb whatever the project needs.

Why It Stays Off the Page

Part of the reason is who writes the first draft. On many purchases it comes from the vendor, and I watched a lot of those drafts get written on the vendor side, by people who were good at it and careful with the numbers they could see. A vendor can price its own software and services with confidence. It has no way to price your operations team’s time, and no reason to make the purchase look harder than it has to.

The rest of the reason is inside the buyer. The cost of change is spread across departments that do not own the project. It appears as overtime in one place, a delayed initiative in another, a quarter where the forecast came in below plan. None of it lands on the project’s cost center, so nobody is asked to estimate it.

Write It Down as Conditions

The cost of change is hard to put in dollars up front, and a made-up figure would do more harm than leaving it out. There is a more useful way to get it onto the page. Write down what has to be true on the business’s own side for the returns to arrive, and make each item a condition of the approval.

A condition is plain and checkable. Take a new payables system, as an illustration. The payables team runs the old and new process side by side for four weeks, with temporary staff approved to cover the gap. Approval of invoice exceptions moves from the regional offices to the central team by the end of the second quarter. The monthly aging report the new system replaces is retired, so nobody keeps producing both. Each condition names the function that has to deliver it and the date it has to be done.

Written that way, the cost of change sits on the page next to the money, as commitments the business makes, and the committee can see it is approving two things: the system, and the change the system depends on.

New Orleans has a current example of a condition nobody wrote down. On October 15 the city’s inspector general reported that its fleet division had been paying about $1.4 million a year since 2025 for vehicle tracking software and had paid for 2,481 licenses. Only 62 percent of the city’s 2,577 vehicles were connected to it. City employees and the police unions objected on privacy grounds, and nearly two thirds of the unconnected vehicles were police vehicles. The city policy governing its vehicles was silent on tracking software, so nothing required anyone to install it, and the inspector general estimated that about $498,000 went to unused licenses. The objections were legitimate and they were known. Settling them, and deciding which vehicles would carry the system, was the condition the purchase depended on, and the license count was set without it.

What Changes for Finance

The approval has to account for capacity. If the conditions cannot be staffed this year, the committee finds out before it funds the license rather than after. Some cases get smaller, and some move to a better quarter. Both beat funding a project that goes live on time and on budget and then never produces the returns.

The review a year later gets easier too. When the returns come in light, finance can check the conditions before anyone argues about the technology. If the parallel run was cut to one week, or the old report is still being produced every month, that is the first finding, and it belongs to the business. If the conditions were met and the returns still did not arrive, the conversation with the vendor starts on solid ground.

The conditions also outlast the project team, which usually breaks up at go-live and takes what it knew with it. The conditions sit in the approval record, where the next review can find them.

Why a Good Vendor Should Want It

A vendor that can deliver has good reason to want this written down. Today, when returns lag, the default explanation is that the product fell short, because the product is the only part of the purchase anyone described in detail. With the conditions on record, a miss on the buyer’s side shows up as exactly that. The vendor answers for its own part, and the renewal conversation is about that part, with the buyer’s side of the record sitting right next to it.

Where It Sits

The conditions are one entry on a Request for Value, the page a business owner writes before any vendor is asked for anything. It starts with what the purchase has to produce for the business, and the conditions follow from asking what the business itself has to do for that to happen. A free template of the page is on the Guides page.

Most business cases already handle what the company pays the vendor. The conditions add what the company has to do itself, and that part usually decides whether the returns show up.

Keep reading: ACT III · Chapter 21: Decision Artifacts That Govern Outcomes