I consult, write, and speak on running better technology businesses (tech firms and IT captives) and the things that make it possible: good governance behaviors (activist investing in IT), what matters most (results, not effort), how we organize (restructure from the technologically abstract to the business concrete), how we execute and manage (replacing industrial with professional), how we plan (debunking the myth of control), and how we pay the bills (capital-intensive financing and budgeting in an agile world). I am increasingly interested in robustness over optimization.

I work for ThoughtWorks, the global leader in software delivery and consulting.

Monday, January 30, 2012

Business Cases: Simplicity over Sophistry

In textbook portfolio management, we have a thorough and well researched business case that details the features, costs, and ROI we expect to achieve for each initiative.

Even if this did describe how most businesses start IT projects (and it does not), it is futile. Business cases are easily co-opted, marginalized, and bypassed in the normal course of day-to-day business.

Let's look at the theory behind having a business case. A business case defines why we want to make an investment. Beyond just being a rational thing to do, policy dictates that we have a business case: the rules governing capitalization require that we explicitly define what we expect to achieve, at what cost, for what benefit, over what time. A well formed business case satisfies the preliminary (pre-capitalization) obligations that allow an investment committee to approve or reject a proposed investment.

But most software investments are never pitched to an investment committee. We only need investment committee approval when spend is expected to exceed a set threshold, which in some businesses can be as high as $10m. Most IT projects are projected to cost far less than this. Funding for these projects is secured through the annual budgeting cycle. The temporal nature of financing decreases the demand for a business case. That, in turn, means a whole lot of IT investment is going on without a clearly articulated statement defining why it is being done in the first place.

We tend to assume that the more thoroughly it is researched and written, the stronger the case. This tends to lead to lengthy and elaborate justifications (perhaps they are lengthy and elaborate to justify both the investment being proposed and the time required to produce the business case itself). But rather than insight and wisdom, we get rationale that is highly suspect. This is true for all kinds of investments. John Kay pointed out that the economic cases for the HS2 rail project in the UK and the trams in Edinburgh are strangely precise, wildly optimistic, and ultimately justified by impact ancillary to the problem they should seek to solve: it makes no sense to offer a 25 minute journey from the center of town to the airport on a GBP1b tram when you can offer the same journey in the same amount of time on a far less expensive bus. They are vanity projects justified by complex, black box analyses. We see this same phenomenon in IT: people will go to great lengths to justify technology projects as a means of career advancement, job protection, skill acquisition, or organizational power building.

Nothing erodes the credibility of a business case faster than overstated benefits. Academic examples of business cases use hard figures such as revenue increases or cost decreases to calculate project ROI. But most corporate IT investments don't directly increase revenue or directly reduce costs. They make people "more productive" or they "improve customer service". These are worthwhile things to do, but they are soft benefits. Since these usually do not become hard benefits such as staff reductions or additional sales, we use proxies, things like "positions not hired" or "customers retained", to make them more tangible. Although it's good to acknowledge potential strains and risk of losses, these make for weak justifications when they are unlikely (projecting an un-needed job is only valid if there is funding for a position) and when they are hard to quantify (we generally don't know with any accuracy what customers we stand to lose if we don't make this investment).

The disparate nature of these measures often drives us to consolidate our projected benefits into a single index of "business value." As covered previously, this confuses and weakens our case. Better that we communicate projected hard and soft benefit independently, and do not overstate either our optimism or the precision with which we can measure.

Finally, change doesn't happen in isolation. Technology investments are usually implemented in conjunction with a broader package of business initiatives that may stretch from marketing to fulfillment to accounting policy. Although one specific investment may be the focus of a business case, we have to keep in mind that businesses are constantly changing how they operate, interact with suppliers, and appeal to customers. Market forces also take their toll, forcing us to react to changes in our operating and competitive landscapes. This makes it hard to trace with any accuracy the impact any single change has on any specific outcome. Most often, the best we can say is that a solution is a contributing factor to a changed state of the business. That is still reason enough to make an investment, but it dulls the confidence we can responsibly have in a projected ROI.

All told, writing elaborate business cases is tilting at windmills.

This is not to say that business cases lack value. A good business case is critical to governance, portfolio management and execution. They capture the best information that we have at the time. They provide a foundation to "why" we elect to make an investment, guidance as to "what" it will mean to fulfill that investment, and an ability to assess both the attractiveness, viability and success.

But we should think about our business cases a little bit differently than the textbook would have us do.

Thomas Lissajoux makes the point that it shouldn't take more than a day to write a business case, and it shouldn't require more than a single sheet of A4 to make your case. A business case may be multi-faceted, but it need not be overly verbose. We should also follow John Kay's advice and be less concerned with precision and more concerned with clearly and simply expressing our expectations. If we're investing too much time, or being elaborately descriptive, or pursuing precision, or building too complex a model, we are reaching for justifications. Short and simple will also mean that our business case is accessible, understandable and believable to a wide audience of stakeholders and participants over the life of an investment.

Elaborate models developed in support of precise justification are not business cases, but sophistry. The textbook business case is best left to academics to debate. Those in business are best served by simple statements of wants, needs and expectations.