Still on the Case of the IT Business Case

My post last week describing why I’m opposed to using quantitative, ROI-based business cases to justify proposed IT investments generated reactions ranging from support to condemnation to requiems for HBS.

Expressions of support reinforced a couple of the points I was trying to make in the initial post:

• For the majority of technologies, even the most rigorous and objective IT business cases are exercises in speculation and attribution.  They not only anticipate benefits, they also ascribe all these benefits to the technology and none to the individual-, group-, and organizational-level changes that simultaneously occurred.  
• Most IT business cases are something less than rigorous and objective.  Lots of people get paid to generate them, or get paid based on their rosiness.  I have a friend who used to work on ‘pre-sales opportunity assessment’ (or some similar-sounding activity) for a major vendor of supply chain software.  His job was to prepare and present business cases showing the prospective customer how much better off they’d be if they bought the system.  We were out one night and I asked him "how many times did your assessment conclude that the company actually wouldn’t benefit a huge amount from purchasing your software?"  He just smiled and bought me a beer.  I imagine that most of the people whose paychecks and commissions depend on ROI-based business cases want to continue to generate them.
• At their worst, IT business cases are like Soviet five year plans —  devices used by competing groups to come up with bigger numbers than each other in order to secure funding and avoid harsh scrutiny.  

Those who disagreed with the initial post argue that it is in fact possible to accurately describe and ascribe benefits, and that it’s an abandonment of management’s fiduciary duty not to try.  After all, this argument goes, savvy companies don’t start other capital investment projects without first building an extensive, quantitative business case.  

This is true, but these same companies also typically spend money on advertising and/or R&D.  And very few of them say things like "our analysis shows that if we drop our sponsorship of Wimbledon and sign up Scarlett Johansson as a spokesperson we’ll save $3 million and increase sales 4.6% among 18-24 year old males" or "we spent $400 million in our labs last year and introduced 8 new pharmaceuticals into the market.  So if we spend $500 million next year, we’ll get 10 new drugs out."

So it’s just not accurate to say that companies only make large investments once they’ve done an ROI calculation.  In some of the most critical areas of the business, in fact, they do something close to the opposite.  They discuss budgets, goals, and desired outcomes, but not projected ROIs.

 IT looks very much like a standard capital investment —  a company pays cash and acquires an asset, whether that asset is a server and a CD full of software, the right to access a system over a network, etc.  But this money-for-assets exchange is only surface level activity.  The real phenomenon of interest is the attempt to acquire an IT-based capability, just like advertising is an attempt to build a brand and R&D is an attempt to innovate.  Each of these attempts requires sustained management attention, not just a periodic bakeoff among business cases in which the highest ROI figure wins.

SAP’s Thomas Otter, in a comment on my original post, asked an excellent question:

My MBA students who have experience trying to buy or sell corporate IT ask the same question.  They’ve seen that the ROI-based business case is the current tool of choice, and ask me what it can or should be replaced with.  I counsel them to put together a business case that has three main elements:

1. Costs and timelines.  The cost portion of the cost/benefits analysis can and should be calculated with all due precision.  As I wrote before, the cost breakdowns of most types of IT effort are pretty well understood by now, and should be laid out in advance.  So should the best initial guess about how long the whole effort will take, how it will be segmented, and what milestones will be reached along the way.  When doing this, it’s important and smart to acknowledge the great uncertainty inherent in both anticipating costs and timing, especially for large and complex projects.  I’ve been working for some time now with a large utility that’s putting in several new enterprise systems.  The leader of this project is a respected senior non-IT executive.  When he first presented the project to his peers, the CEO, and the board he told them to expect that some of his future reports to them would include notifications of delays and requests for more funds.  Sure enough, they did.  The combination of his reputation, his initial honesty, and the fact that the project was clearly making progress ensured that news of additional costs and delays was taken in stride, rather than providing an occasion for a freakout.  
2. Capabilities anticipated.  I describe enterprise IT’s capabilities as monitoring, standardization, and process design, network IT’s as collaboration, judgment, and emergence, and function IT’s as experimentation and precision (I have an article coming out in the November issue of Harvard Business Review describing these technology families and their capabilities in more detail.).  Capabilities are not as low-level as feature sets, but not as high-level as some of the promised results from IT like ‘organizational transformation’ and ‘customer intimacy.’  They provide a foundation for a concrete discussion of IT outcomes that doesn’t rely on knowledge of any specific vendor’s offerings.
3. Technology footprint.  A technology’s footprint is its geographic, divisional, and/or functional reach.  It’s a description of how much territory a piece of IT is intended to cover.  Network technologies tend to have large footprints (how much territory does email cover?) and ones that are easy to expand.  Function technologies tend to have fairly small ones; a CAD system isn’t that useful outside the engineering department.  Enterprise technologies like ERP and CRM can have small footprints, or very large ones.  Their complexity, and hence cost, goes up geometrically with footprint, so their borders should be set carefully.  

 Cost, capability, and footprint are, in most cases, sufficient information to allow business leaders to make IT decisions.   They also provide a basis for prioritizing IT initiatives, something many companies struggle with.  Is it more important for customer interaction processes to be standardized across all business units, or for vendor interaction processes to be?  Is it more important to change how engineers collaborate, or to give them better tools for experimentation?  These are not easy questions, but they are important and appropriate ones for leadership to discuss.

Walking away from ROI-based business cases does not mean walking away from careful thinking or analytical rigor.  It doesn’t mean spending like a drunken sailor on IT.  And it doesn’t mean abandoning any important management duties.  It instead entails acknowledging that IT is a lot more like R&D than like a new machine tool, and that reliance on big ROI numbers is both a shortcut and a dangerous addiction.

It is, however, a pretty deeply entrenched practice.  If you’d like to move your colleagues and your companies away from it, I’d suggest starting by having people read Kaplan and Norton’s Strategy Maps.  And perhaps a couple blog posts…