CRM: Building the Business Case

Customer Relationship Management (CRM) seems to have a somewhat checkered history of delivering the expected value.  Sometimes, the reasons for failure are the same as those for other IT projects – project management, budget issues, etc…  The issue I’d like to address here is expectations as it relates to the results of a CRM initiative. 

Early in the project, the sales or internal support team will begin to formulate a selling proposition (internal teams need to be good sales people too), which will include a business case for the project.  Often, either the business case is weak (“You will experience 5-10% improvement in operations”), or it is overly-optimistic (“You will have a 15% increase in passenger traffic on your airline”).  Both lack credibility.  Being credible requires a clear line between the expected benefits and project-linked improvements.

So, here are some suggestions that will help create stronger business cases that are compelling and set the foundation for success.

• Numbers.  The most believable aspects of a business case are always the numbers.  “Improving” and “improving by 7%” are very different.  Anyone can put a number on a PowerPoint slide, but fewer can back those numbers up with a detailed analysis. 


• Story.  The story associated with the numbers are probably more important than the numbers themselves.  Mark Twain said, "Figures don't lie, but liars figure."  That truth is not lost on clients, so the story must be credible.  What makes a story credible?  Read on.


• Integrity.  At some point, you’ve gotten good data to create a credible set of numbers, and you’ve put together a story about those numbers.  It now comes down to you – are you credible?  You must believe your own story, and you must be fluent with its presentation.  That flows from your own integrity.

These steps are not linear but rather occur simultaneously.  Your story will guide your search for relevant statistics, and those same statistic will guide the development of your story.  The project itself will put you in a box (e.g. project constraints), which in turn influences the set of numbers required.

For example, in a given customer engagement, I needed to put together a cost-savings business case based on an application change.  The first choice was deciding how to explain the business case.  Do you try doing a comparative analysis between the incumbent and new software solutions?  The problem with that approach is fans of either package start to compete with each other and it blunts focus.  Thus, the first rule is: keep the story simple.  I chose to focus on the relative development and operational costs.

Next, gather as much relevant data as possible.  Especially early in the cycle, getting reliable data is often difficult.  Clean data is great but often hard to produce.  Get as much clean data as possible. 

How many points of value should you create in your narrative?  The answer brings us to the second rule: compelling is better than exhaustive.  Demonstrating 80% of the value create is not 100%, but if telling the story with 80% only requires five value points, versus 25 for 100%, I’ll take the five every time.  The story becomes compelling when it becomes easily comprehensible. 

Finally, sequence the story as a series of reveals and get to your point quickly.  While you still have to step through the story, don’t take a long time to get there.  If you’re using PowerPoint, a few slides should be sufficient. 

There are a lot of “it depends” factors in this analysis: size of the investment required, audience, criticality of the benefits, etc…  Getting the numbers, crafting and presenting the story, and then acting with integrity are key to being believable and setting a realistic expectation early in the project.  If the project starts well, it will end well.  By the way, in case you were wondering, the story I told earlier resulted in the proposed solution displacing a good incumbent provider.  That outcome was achieved because the client believed the business case.