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 a different 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 green-lighting 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 2024. 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.

The second half of this post is available here.

Until next time, take care and prosper.

Sriram

agileorgdesign.com

Newsletter Home