Has Agile Killed the Business Case?

If you are a single-product startup, you probably don’t need to write a business case for every new feature or enchancement. If you have adequate measurement capabilities and tight feedback loops, you could probably iterate your way to product-market fit with hypothesis driven development. You might still need to prepare business cases for your potential customers to help them justify the purchase of your B2B product but that's another story.

It’s different when you are a large, multi-portfolio business with a shared technology organization. Your business leaders probably don’t like to think in terms of hypotheses or experiments. They are used to funding big programs with tall promises, ambiguous scope, and wishful deadlines.

Your annual demand for new functionality and new technology is far greater than the annual capacity and throughput of your technology org. Sometimes, this might be due to a sub-par tech org but it doesn’t matter, it’s the reality. To prioritize the overwhelming demand and to match it with your capacity you run an annual, not-so-agile, budgeting process that goes on for several months. One input to this process is the justification for each proposed program or initiative.

The Classic Business Case

Traditionally, the justification used to take the form of a classic business case, including a financial analysis of costs and benefits. There are books about how to prepare a thorough business case. The one I referred to in my 2015 book, Agile IT Org Design, is called Finance for IT Decision Makers and it was first published in the year 1999. It says things like this:

Any investment by a company, in IT systems for example, will have an effect on both the company’s cash flow and its profit over the following few years. It is of course important to work out the likely effects of an investment on both cash flow and profit, and most businesses do so, as we shall see. But which of the two provides the sounder basis for deciding whether to make the investment or not? For most organisations, cash flow is the main basis of financial cases to be used as aids to investment decision-making.

It goes on to explain how to perform a discounted cash flow (DCF) analysis to arrive at the internal rate of return for the proposed initiative. In those days, before Agile and Digital, IT Finance analysts used to perform this sort of analysis for big IT investments. Proposals with the best numbers (or the best backers, unfortunately) would make the cut. 

Performing this kind of analysis for every digital initiatives is probably overkill. But it is useful to identify all major heads of cost and benefit and estimate their numbers before greenlighting an initiative.

The problem with the classic approach was there was no feedback loop. There was no practice and often no means of validating the benefits post implementation. Benefits were assumed to have accrued upon execution. The OODA loop of Build-Measure-Learn was not mainstream back then.

The (Sorry) State of the Art

Cut to 2025. Benefits are still not being validated at large organizations. Even delivery is a struggle, what to talk of benefits. What’s more, the erstwhile business case has been watered down in the name of being Agile.

Present day justifications for initiatives are made with a slide deck high on polish and low on substance. Sometimes it is low on polish as well. They make vague claims of improving sales or CSAT or some such metric. Technology initiatives make vague claims of reducing the risk of legacy technology or of making the organization future-ready. Any questions about cost vs. benefit are waved away saying it would require big upfront analysis which is a pre-agile, baby boomer hobby.

There is no alternative to continue ramping up investments in digital, dummy!

No upfront analysis. No feedback loops. No validation of benefits.

Nothing agile about it. 

It’s no wonder that the benefits are imperceptible and the budget continues to bloat year on year. And CFOs and other execs struggle to answer investor and analyst questions as to the performance of various investments.

Investment Governance

Where is investment governance? It’s their job to fix this. Fix the justification. Fix the validation. I have written a bit about validation earlier. For justification, I recommend reviving the business case, albeit in a new, lite avatar. A lightweight business case must answer:

• What metric will improve through this initiative?

• By how much?

• In what time-frame?

• With how much effort? (Initiative-level T-shirt sizing)

• Under what assumptions and dependencies?

• How confident are you as to the above? On what basis?

• What measurement capabilities exist or need to come into existence, to validate the above?

Note that we don’t dig deep into costs, just a high-level effort estimate. Metrics must be business relevant but not necessarily financial. Even getting to this level of rigor won’t be easy for those used to the current, no-questions-asked state of affairs. Some coaching might be needed. But it is doable, even for technology initiatives. Their benefits can also be expressed in terms of metrics intelligible to a COO or CFO.

It is okay to be honest and answer We don’t know to some of these questions. It serves to temper the zeal with with which ideas are pushed in the fear of missing out on prioritization.

Answers to the above can be faked. That’s where the validation loop kicks in. Portfolios that make a habit of over-promising and underachieving will see their change budgets shrink over time.

Lightweight business cases upfront, robust validation loops at the other end, investment governance that adjusts funding based on results. Now that is truly agile.