I’ve wrestled with this issue for a few decades now, through the Strassmann and Carr arguments and a whole slew in between. And sometimes it feels a bit like The Emperor’s New Clothes. It’s just not done (in polite circles) to point out the guy’s not wearing any.
When I look back over the years, I find that my arguments came down to this:
1. Costs are easy-ish to measure, benefits aren’t.
2. Even if costs are easy-ish to measure, allocating them is often a major headache.
3. And if allocating costs is hard, try “allocating” benefits. Just try it.
4. Quite often the decision is already made, by people with the authority to make the decision, so where’s the value in post-facto bureaucracy?
5. The process of trying to define, measure and crystallise benefits is itself so amorphous that it lends itself to arbitrage; more projects “fail” as a result of benefit-arbitrage politics than is commonly known or accepted. It’s along the lines of “When you can’t deliver the benefits, get your defence in first. Attack the project.”
So I spent time looking at Andrew Abbott’s The System Of Professions and the Searls/Brand Because Of Rather than With, spent time looking at democratised innovation and its implications, trying to figure out how best to deal with the issue.
I never questioned the need to have a real and communicable plan, a routemap, an expected cost and an expected timescale. I never questioned the need to ensure that the decision-maker(s) were empowered to make the decision(s). I never questioned the need to have good feedback loops and monitoring processes. What I questioned was the process by which the benefits were “created” and then used as an opportunity for arbitraging the rest of the project, and how much time and money was spent arguing about them prior to project initiation in comparison with post-implementation-benefits-analysis.
So it was with considerable interest that I read Andrew McAfee’s recent post on The Case Against The Business Case. I was particularly intrigued to see the comments made by Bob Kaplan on the topic; I will now go and read Strategy Maps, I’d bought the book and not got around to reading it.
Thanks, Andrew! Much food for thought.
Sometimes the “benefits” are forced on you. There’s a good example in http://www.cio.com/archive/021502/security.html looking at ROI for security – in this case, use of fire sprinklers in cotton mills.
In summary (but please read the paper!) mill-owners could not justify the ROI themselves to install fire sprinklers. After the inventor gave a demonstration, insurance companies offered discounts to people who bought sprinklers, and raised premiums for owners who didn’t. Result was that everyone eventually bought them.
Now whether the industry-wide cost really resulted in an overall benefit, or whether it just became the cost of doing business, is not tackled by that article. In a world where regulation is imposing increasing costs, we need more people to ask that question.
I agree with the comments re IT ROIs are very difficult to calculate. Having used, ABC, activity-based-costing, and strategy maps in previous consulting assignments I slightly disagree that these two offer a magical solution.
If we are to design a 5 star hotel, should we be formulating the ROI or ABC analysis of extending the pool bar menu to cover exotic cocktails ? Should we let the contractor to make the decisions on what type of roof insulation to use? I guess the point I am trying to make is we are busy asking wrong questions to wrong people and missing the point. IT departments are left with technology decisions and seeking answers to similar questions in technology space.
I would like to reemphasize the importance of business strategy and experimentation. Rather than spending time justifying the cost of using a specific technology, I prefer understanding how a certain technology fits into my business strategy, its’ limitations and cost of switching. This, in my view, is the sole driver of the decision making process. On the implementation side, experimentation helps avoid costly assumptions. All strategic technology decisions need to be experimented/piloted in very small scales to ensure minimal pain in actual implementation. Only after this experimentation phase relatively more reliable cost estimation can be made.
Experimentation for better forecasting + a technology architecture that offers low switching costs = decision making with relatively higher certainty and minimal pain.