Making the CM Business Case: Part 2 - The Simple Stuff

Okay, where was I? Last time I pointed out that you are not going to convince anyone to introduce configuration management if you just present a business case. There's much more to it than that. This time I'm going to discuss what goes into a business case.

Hang on! Hold the phone! Didn't I just say that the business case was not going to swing the deal? Sure I did, but I also said you have to have a good business case because sooner or later you're going to need it. Besides, if you can't make a business case why are you so convinced CM is a good idea?

That's the point isn't it? You're all gung-ho for CM, but why? If you're waving the flag you better know why and you'd best be able to justify your reasons.

People often get caught up in the emotion of a new idea. "Configuration management is an essential part of effective IT development", we are told, and so we start telling everyone that CM is a good thing and sooner or later someone says, "why?"

"What?"

"Why is it a good thing?"

"Urm. Because it is part of ITIL. And CoBit. And, erm, CMMI. It MUST be a good thing for all of these to have it."

"But why are any of those good for out situation?"

"Erm"

Believing that configuration management is a good thing means you know nothing. Knowing why configuration management is a good thing is better (hopefully you already know why CM is a good idea, if not then we need to talk some more - maybe another series of posts :) ). Knowing why configuration management is a good thing for your situation is better still. Being able to justify all of this with a solid rationale backed by defensible data, is a business case.

A business case is a formal presentation of a cost to benefit comparison to justify an action that affects your business. In short, how much are we going to save or profit by doing this?

I should note at this point that, in the course of preparing a business case you might discover that there is no saving or profit to be made in taking the proposed action. Your research may even demonstrate that the action would result in a loss. Business cases that reveal loses don't make it past the research stage. That is the value of preparing a proper business case.

What goes into a business case?

Each organisation will have their own layout for a business case, but they all amount to the same thing:

• What do you want to do?
• When do you want to do it?
• How much is it going to cost?
• How risky is it?
• What happens if it fails?
• How are you going to mitigate those risks?
• How much will we save or profit if it works?

That's basically it.

Who is going to read your masterpiece when it's done?

Again, the specifics are down to the individual organisation but in general you know that the business case will be reviewed by the stakeholders. Stakeholders will certainly include:

• The decision maker. The person who is ultimately responsible for giving the go ahead.
• A business sponsor who will take responsibility for the action on behalf of the business.
• The implementers - all the people who will actually have to make the proposed action work.
• The users - who will have to live with the consequences of the action.

All, or some, of these roles may be the same person or group.

As with any document it is vital that you understand your audience if you want them to make a decision in your favour. Your business case is the last piece in your sales pitch, it can also be a deal breaker if it is not what your audience wants (but we will have prepared them to want it, so hopefully writing the business case will be the easy part).

If you want to know why I keep emphasising the need to prepare your audience, consider the following example.

Back in March 2003 the UK government decided to join the US in a waging a war in Iraq. This decision was made by 412 MP's who voted to go to war based on what was believed at the time to be good evidence that Saddam Hussain had access to so called weapons of mass destruction (WMD's). It should be noted the 149 MPs voted against going to war and no less than 139 of the Prime Minister's own party voted for an amendment saying the case for war was not yet proven. The evidence supporting the vote was presented in a dossier that the Prime Minister, Tony Blair, presented to parliament. It was later revealed that those rebels who wanted more evidence were right to do so. The dossier's content had been 'sexed up' to make the evidence appear stronger than it actually was. Even in this 'sexed up' state the data was, at best, questionable. So, why did 412 apparently reasonable human beings decide that they should go to war on the basis of this proposal? Obviously individual motives will never be known fully, but it can be observed that at the time this dossier was prepared and presented everyone in the country had been subjected to a torrent of media hyperbole on the subject. Add to this the authority with which the PM assured the house of the seriousness and quality of the intelligence (which was available to only a select few first hand), and no doubt political pressure both within the House and from MP's own constituencies, and one can understand how people made a decision that in hindsight many believe to be wrong. It was not the data in the document that was compelling but the emotional investment, manipulation and careful presentation of this by a few in power that resulting in the decision being made. Not only was the decision made, but many who made it were adamant of its correctness (as shown through media interviews at the time). This despite the paucity of evidence in their possession.

In what order should you present the information?

Assuming you are not forced to follow a specific template, here is my suggested order for presenting the information in a business case.

Firstly, consider your audience. The main audience for a business case is the decision maker. The decision maker will be a busy person (usually quite senior and your business case may be one of dozens they are asked to consider), so you must present the best case possible as quickly as possible.

Provide an executive summary. This should be no more than one page, and should preferably consist of only one or two paragraphs. The executive summary must summarise the business case for configuration management in language accessible to the decision maker. If the decision maker is a business person you must be careful to use business language when presenting your business case, and most especially when writing the executive summary. The executive summary should be the last thing that you write and should be put on the front of the business case, before any title page or content. (I often simply attache the executive summary on the front like a covering letter. That way the person reviewing the business case does not even have to open the document.)

The main body of the business case is similarly focussed. Present the essential detail first, then the supporting information, and relegate the raw data to the appendices.

• Summary
  • Benefits
  • Costs, including risks
  • Deliveries
• Supporting case
  • Benefits detail
  • Cost and risk details
  • Plan
• Appendices
  • Raw data

The precise details and content of each major section will vary, but the broad outline should present the information in the order shown above.

The reason you present the business case like this is simple. You are asking someone to make a decision. A busy person wants to know four things; what am I getting, how much is it going to cost, how long will it take, what are the risks? The summary must contain all of this information. The entire summary should be presented in bullet points and take nor more than one, perhaps two, pages (but try hard for one!). If the decision maker feels that this summary does not provide sufficient detail to make the decision then they will look into the main body of the business case.

Experience shows that even fairly major decisions are often taken on the basis of the executive summary or the business case summary. Why? Because the decision maker will have canvassed opinion from trusted subordinates beforehand. They will quickly assess the business case finally presented based on the summary, but the decision will already have been substantially made based on discussions with subordinates.

What about these 'trusted subordinates'? These are the people at whom the main supporting case is aimed. These are the people who will need to be convinced of the business case and will need to pass on their confidence to the decision maker. It is to these people we shall return in the next article in this series.

Subversion Information

Interested in Subversion? Want to get more out of it? Need some help? Got questions?

I've recently started aFrequently Answered Questions (FAQ) for Subversion on my main site.

Also, if you have a question that's not on the FAQ, feel free tocontact me. I can't promise to answer all your questions, but I'll try to answer as many as I can on the FAQ.

Also, keep an eye on theSubversion Guru training course. Progressing slowly, but there's loads of great stuff packed into the course so far and I'm putting more in every week!

Simple, complex and difficult

IT system lifecycle management (the discipline to which this blog is dedicated) is simple, complex and difficult.

ITSLM is simple in the sense that its principles can be explained easily.

ITSLM is a collection of techniques for identifying and controlling the development and operation of all the component parts of an IT system. This includes the entire lifecycle from conception through to retirement, and covers all aspects of the system including its documentation, software, hardware, infrastructure and all the processes and procedures necessary to ensure their efficient management.

ISTLM is complex because IT systems are growing larger and more complex in their make-up.

Individual services are made up from multiple systems, provided through multiple channels, to geographically and demographically divers users, through infrastructure that may be controlled by your organisation and others. Not only are systems increasingly complex but the method by which they are developed and operated are increasingly complex. Some services are supported by in-house developed and operated systems, others by systems developed in-house but operated by a service provided, others are supported by remove provisioning ('cloud' computing - a terrible catch-all phrase), and all manner of other combinations. These all result in highly complex systems with both technical interdependencies and contractual entanglements.

ITSLM is difficult in part because of the complexity, but mainly because many different people and organisations are involved.

People, and organisations, have their own motivations and agenda. ITSLM is often a discipline of mediation between differing, and sometimes conflicting, motives and agenda.

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).

CMDB and Configuration Management Process, Software Tools...

Title: CMDB and Configuration Management Process, Software Tools Creation and Maintenance, Planning, Implementation Guide
Author: Gerard Blokdijk
Publisher: Unknown
Year: 2008
Amazon: UK, US

Review in a Nutshell

No.

Review in detail

This is a travesty. Described under the product description as:

Learn Configuration and CMDB management the right way with this unique, thoroughly modern guide to today's Configuration Management challenges and opportunities. Written by an in-the-trenches practitioner, this book goes beyond concepts and definitions to challenge prevalent thinking about the field and provide a step-by-step guide to implementing a successful CMDB strategy. Discover how to move beyond mainstream analysis, why qualitative data should be your focus, and more insights and techniques that will help you develop a customer-centric mindset without sacrificing your company's bottom line. You have more information at hand about your Configuration and its business environment than ever before. But are you using it to "out-think" your rivals? If not, you may be missing out on a potent competitive tool.

This, and I use the term loosely, book is little more than a set of Powerpoint slides with some annotations. There are some extended notes in the second half of the book, but these do little more than reiterate ITIL v3. This is, without doubt, the worst book I have read to date (not just the worst book on the CMDB, the worst period). At £15 ($30) this book is massively overpriced.

This book looks to me as if it has been written as an accompaniment to a training course, not as a standalone book.

Where to start?

I have been considering my options as to what to put on this blog. It's tougher than I thought because almost every topic I considered could be written about for many, many pages and the danger of writing only a series of short blog post is that the reader - that's you - could easily take away an incomplete message if the whole series of posts were not read together.

Then I thought, "You're being unfair to your readers. They're smart people. So long as you make it clear posts are part of a series they'll get it." So, I'm going to post that way, some short posts but plenty of themed series.

I can hear you all now thinking "but what themes Mark? What pearls of wisdom do you have to cast?" Many my children, many. :) Here are a few thoughts that I will be investigating in this blog.

• Simplicity in organisational process and how organisations get this horribly wrong, and why, and how to fix it.
• Version control; especially version control trees and a language for describing them. How directed acyclic graphs (DAGs) are useful. How the mathematics of DAGs might help. Where DAGs break down in software configuration management (SCM) and what you might be able to do about it.
• Why ITIL, CoBIT, CMMII and their ilk are both a blessing and a curse.
• How to make the business case for IT systems management, including; configuration, change, release, build, problem, and defect management.
• How to create a powerful and flexible build farm using virtual appliances. The advantages of a virtual build farm. How to automate builds.
• SCM; where people go wrong. How to avoid being one of those people.
• Changing culture; one of the biggest problems faced by anyone trying to introduce systems management into an organisation is cultural inertia. How can you overcome this tendency to 'keep doing the same thing', especially when you have direct authority over the people who need to change?

Well, that's just a few random topics that spring to mind. I'll be adding others as they come up, in the meanwhile I'll be trying to write at least one post a week. I will try to keep these blog post short(ish) and informal. When I find time I will be adding supporting information, or more formal presentation, at http://www.principia-it.co.uk and linking there from this blog.

Good luck with your own efforts.

Writing about the WEBDAV standard as supported by Subversion