← All posts
Tech

Most technology business cases are written backwards

If the technology is in the title and the ROI came from the vendor, your business case was built to justify a decision, not guide one. Here's how to write it forward, and what to cost that usually gets missed.

Infographic: the backwards business case versus the forward business case, with five signals your case is backwards.

Here’s the sequence most technology business cases actually follow:

  1. Someone decides they want a technology (a conference, a demo, a competitor has it)
  2. IT or a consultant is asked to build the business case
  3. The case is written to justify the decision that’s already been made
  4. Finance approves, because the numbers were engineered to work
  5. Around month 8, the promised outcomes start looking unrealistic
  6. By month 14, the program delivers technology but not the value in the case

This is the backwards business case. It’s the norm. And it produces bad outcomes because the case was built to justify the investment, not guide it.

The forward business case

The forward business case starts with a different first question. Not “what technology should we buy?” but:

  • What’s our most expensive unsolved business problem?
  • What is it costing us today, measurably?
  • What capability would reduce that cost?
  • What’s the most efficient path to that capability?

Only then does technology enter the conversation.

Backwards

  • "We need Salesforce. Here's the ROI model."
  • Built around license cost and assumed productivity
  • Technology chosen first; numbers fitted afterward

Forward

  • "Our sales cycle is 47 days vs. a 31-day benchmark. That 16-day gap is about $2.8M in deferred annual revenue."
  • "We need real-time pipeline visibility and automated follow-up. Salesforce, HubSpot, or a custom workflow could deliver it."
  • "Here's the comparison and the 90-day proof point."

The second is harder to write. It requires a current-state baseline. It also survives the CFO meeting. The first one doesn’t.

Five signals your business case is backwards

  • The technology is in the title
  • The ROI model was built by the vendor
  • The “business owner” is IT
  • There’s no current-state baseline
  • The benefits say “improved efficiency” with no numbers

How many of those does your last business case have?

Three questions before any investment

Before a vendor demo, before an RFP, before a budget conversation, I ask three questions. If they can’t be answered clearly, the investment isn’t ready.

1. What business behavior changes when this works? Not “what capability does this enable.” What will people do differently, measurably differently, because this technology exists? If the answer is “it’ll be more efficient,” you don’t have an answer yet.

2. Who owns the outcome, not the system? Not the IT owner. Not the vendor relationship manager. Who in the business is accountable for the behavior change in question one? If that person isn’t in the room, the investment will drift.

3. What does failure look like at 90 days, and who calls it? Every technology investment needs a kill switch and someone authorized to pull it. Not at 18 months. At 90 days. Organizations that skip this question spend years on programs that should have been restructured in the first quarter.

Most organizations answer question three in the post-mortem. By then, it’s expensive.

Cost the capability, not just the project

Even a well-written forward case can be undone by the budget underneath it. Most technology programs are scoped by feature, budgeted by implementation cost, and governed by delivery milestone. Then everyone is surprised when “scope creep” shows up at month six.

It’s rarely scope creep. It’s capability cost that was never modeled.

Usually costed Usually missed
Software licensing Ongoing optimization and configuration as the technology evolves
Implementation services Change management as a sustained activity, not a one-time event
Infrastructure Integration maintenance as neighboring systems change
Initial training The internal capacity to actually own and operate the capability
The cost of not decommissioning the system being replaced

When you model capability cost instead of implementation cost, the budget number looks higher up front. It also stays accurate. The organizations that skip capability costing don’t spend less. They spend the same amount, just in surprises instead of plans.