Making a Business Case for Configuration Management

This is the first in a series of, fairly informal, posts about making a business case for Configuration Management.

Before I get stuck in to the topic I would like to make clear that much of what I am about to discuss applies to making a business case for anything, not just Configuration Management. So, why not have the title "Making a Business Case"? Well, two reasons spring to mind; firstly, this series was originally provoked by a direct question posed on the CM Crossroads forum about convincing an organisation to implement configuration management (here we are in 2009 and people still need convincing! Go figure) and secondly, having a specific business case in mind allows me to illustrate points in a more concrete way.

General Observations on Business Cases

As a freelance consultant I get to see my fair share of business cases. I am still surprised at what passes for a business case in many organisations. They range from barely coherent requests to poorly presented financial statements. The information presented in them is often barely defensible and frequently looks like the work of an accountant who really wants to be the next Stephen King - creative works of fantasy with a serious horror twist. I have seen some excellent business case, but these are a significant minority. (My impression is that perhaps one out of every thirty business cases I have read in the past twenty years where actually useful in making a decision.)

Why are they so bad? Part of the problem is that the organisation's processes demand that a business case be presented, but the people asked to present them are seldom trained in how to create a business case. Added to which most people reading a business case have become used to seeing whatever passes for a business case in their organisation, they do not demand more. Consequently, over time it becomes accepted that a business case is just a hurdle that must be overcome. Fill in the template with anything that looks like a justification for us to do the project and get on with it.

This leads me to my first point. Most business cases are nothing more than a rationalisation for a decision that has already been made.

In many organisations the process goes something like this.

Bill Wannado (thinks): We need to implement the Whizz-bang application. I saw ti at the trade fair last month. It looked cool and could replace most of the facilities of applications A and B.

Bill knows he will need John Budgetholder's help to get the Whizz-bang application into the organisation, so he 'has a chat' with John over coffee. John is not overly keen, after all this is going to cost a lot of money.

Undeterred Bill arranges for a demonstration of the Whizz-bang application and invites John along. Following the demonstration John is much more keen to get Whizz-bang in. He asks Bill to present the idea to Frank Ceo.

Bill arranges a second demo, this time inviting Frank and making sure John also comes along. Frank loves the presentation. The presenter made is quite clear that the Whizz-bang application was all-singing-all-dancing and could easily replace applications A and B, "why only last week we replace them at you competitors site and they love Whizz-bang, it's faster and cheaper. Why would you pay for two applications when you could pay for just one?"

Frank, and now John, are enthusiastic about the Whizz-bang application so Frank asks Bill to put together a (you guessed it) business case.

If the presentations had gone badly Bill's job would have been more difficult. It Frank and John were not emotionally engaged by the sales presentations then the business case would never have been requested and Bill would need to consider other strategies to get the Whizz-bang application he so desperately wants.

Suppose the events had played differently. What if Bill had put together an unsolicited business case. John might have read it, and he might have been convinced about the economic case (assuming one were even made). He may even have prompted Frank to read the business case. However, in my experience, an unsolicited business case faces several serious problems.

The main problem is that preparing a business case before you have emotional buy-in exposes your project to objections very early on. If, for example, Bill had written into the business case that new licenses for the Whizz-bang application would cost £1M, followed by annual renewal costs of 15%. This is compared to the current license renewal charges for applications A and B at £175K. The renewals are attractive at £25K less per year but to recover the original license cost of £1M will take (assuming no other benefits accrue) 33 years. This makes rejecting the business case very easy. Even if Bill manages to make a better case by included other accrued benefits such as increased productivity, additional functionality and so on, making the financial case for these benefits is more difficult and more easily challenged.

We all want to believe we make good, rational business decisions. Sadly the evidence does not support this position at all. Business decisions are made on 'gut feel', intuition, 'business sense', experience, and a plethora of other intangible, difficult to account for methods.

In truth rational, hard-nosed business justifications like business cases are used, not to make the decision, but to justify it after the fact. At best, a business case is used to verify that the decision is not going to generate a loss (on paper at least).