How to Maximize the Return on Invesment (ROI) from your planned CRM System Deployment

Setting the Scene

A recent study indicated that the deployment of Microsoft Dynamics CRM delivers an average ROI of 243%.  Details of the support study can be found here:  http://www.microsoft.com/en-us/news/presskits/dynamics/docs/mstei.pdf. 

Speaking from an experience with more then 200 deployments of Dynamics CRM, this writer has seen some deployments achieve much more than the desired ROI and more than this quoted study and some that have achieved less.  Based on these experiences there are definitely some things that those who are looking to undertake a CRM deployment can do to maximize the Return on Investment (ROI) from their Dynamics CRM or whatever other CRM solution or Business Application they choose to deploy.

What to consider and plan for before you start any CRM Deployment

An old University Professor used to say to me that half of solving a problem is know what the problem is in the first place.  Put another way, if you have a good plan then you are a large part of the way there in terms of driving a successful project and achieving the desired ROI. 

It's surprising but the number of customers I talk to day in and day out who can't articulate what their process is going to be to select a CRM solution or Business Application and to then to deploy it is quite high.  Often they come to me with a simple problem statement and a time frame within which they want it fixed and that's it with no further thought around these questions. 

Development of successful plans can be found by answering these basic questions ...

Your Plan for the Software Selection

1. What's the software selection process?
2. Who needs to be involved?
3. Who will write the Business Case?
4. Who will write the Functionality Requirements derived from the Business Case?
5. How will you compare the software you are looking at against those requirements (through and RFT, through Demonstrations, or both)?
6. Who will approve the selection?

Plan for the Software Implementation

1. Who will be involved?
2. How many phases?  How long will the phases be?
3. Which department will go first?  Which department will go last?
4. What tasks are you going to do internally?  What are you asking a Systems Integrator to do?
5. Have you included Business Process Analysis and Design and User Acceptance Testing in your Plan?  Who will do the training?  Who will be responsible for these?
6. How will you manage the process change?

Speaking as a systems integrator customers who have an initial view of all of these are much easier to deal with because it means they at least thought things through.  Now having a plan doesn't mean a plan can't change.  By definition most plans are out of day as soon as you write them and if you are smart you will take inputs from your vendor/ systems integrator on all of the above questions and your plan will adapt as your project changes.  They've done this a lot before and so will have good advise.  But at least going into the process with an initial view on all of the above questions you'll have a much better chance of achieving the ROI you are looking for. 

Setting Good Objectives and Targets for your Business Applications Deployment

Often the goals and objectives of your CRM deployment can become muddled and confused during the design process.  Various interest groups and interested parties within an organization can steer a project in a direction that was never really intended by the projects sponsors.  One easy tool to keep your project on track and to ensure that the focus is on the problems you intended to solve in the first place is by developing a "Conditions of Satisfaction" statement at the beginning of the project. 

The process for developing Conditions of Satisfaction is fairly simply.  A relatively simple process, this involves sitting down with the project sponsor, having a brief conversation and asking him/ her what are the type 4 or 5 things that they want to achieve out of the project.  Another way of asking the question is to say "If we achieve these 4 or 5 things you will be happy correct?"  Hence why they are called Conditions of Satisfaction.  Properly formatted Conditions of Satisfaction should be in bullet point form, should be no longer than one or two sentences each and should consider both the "What" and the "How" of the project.  Where possible they should be SMART objectives (i.e. Specific, Measurable, Achievable and Time Specific).  They are not intended to be functional specifications or detailed functional requirements so be careful of becoming to detailed. 

Essentially these Conditions of Satisfaction become the high level Vision for the project.  Once agreed to they should be attached to the bottom of every project status report to remind the project team of this collective vision.  When the functional scope of the project is being developed usually with the people more junior in the organization, any requirements or subsequent scope change requests should be measured against those Conditions of Satisfaction.  If a requirement doesn't directly address any of these points then the project team should seriously consider dropping it from the project scope.  In this way then a Conditions of Satisfaction Statement is used to aligned the project sponsor, with the project team and with other interested parties within the organization. 

Your chances then of achieving you desired ROI in the specific areas you are concerned with will increase dramatically if you establish the Conditions of Satisfaction early on for each project. 

Why use a Project Management Methodology

Project Management has evolved considerably over the last 20 years with certain well known methodologies like those espoused by the Project Management Institute (PMI) becoming prevalent.  This in itself indicates the benefit of having a well defined methodology for your project. 

A recent survey by PWC (http://www.pwc.com/es_CL/cl/publicaciones/assets/insighttrends.pdf) indicated that the 69% of respondents who use a Project Management Methodology consistently reported a  much lower project failure rate than those who didn't.  A corollary of this is the ROI from a project will improve if a consistent, proven methodology is used to deliver a project. 

In the case of Microsoft Dynamics, Microsoft has spent a lot of time developing a methodology and set of tools specifically for the deployment of Dynamics CRM projects.  This methodology is based on the methodology developed by the PMI but then extends it out with tools and templates specific for Microsoft Dynamics CRM.   The methodology is available and free to use for Microsoft Customers and Partners and can be found online at: https://mbs2.microsoft.com/Surestep/default.aspx

Increased Solution Adaptability and Usability with Effective Change Management

For those who go down the path of purchasing a new business application often what can get forgotten in the deployment is the human being to technology interface.  Often people refer to the triangle of People, Process and Technology.  All three have to work together for you to get a good end result. 

My favourite way of illustrating this is to give an example of a customer I once had.  That customer had a CRM deployed by another company but they were very unhappy.  They invited my organization in to look at the system and help them either "redeploy" the technology or throw it out and look for something new.  In this case they were using the CRM system for Sales Force Automation.  The system they had designed required the sales people to complete no less than 15 individual screens to complete the process of entering in a new opportunity.  In addition relatively little training had been conducted with the users and they had no venues through which to ask questions or get help.  As a result the system was largely unused and as a result the customer was getting no benefits or return on investment. 

The solution to the problem was relatively easy, simplify the system, redesign the business processes with the users in mind, provide them with some effective training (business process specific and in bite sized chunks) and they were off and running gaining all kinds of benefits. 

You can have the best technology in the world but if you don't consider the processes and the people and effectively manage the change they are going through you are not going to get the result you are looking for. 

When and how to revisit the Original Business case How to evaluate the Results of your Investment

One of the interesting things I've found about CRM projects and Business Application projects in general is that often the Business Case is generated at the beginning of the project but typically is never looked at again once the project is approved.  My view is that the Business Case should be looked at repeatedly through the project, definitely during the software selection and definitely at the end once the deployment has happened. 

During the software selection is very important to constantly refer back to the business case as you evaluate the solutions.  Refer to my comments later on about software selection. 

At the end of the project you should compare the business case against what was actually achieved.  If those targets haven't been achieved then certainly you can look at a phase 2 where you tweak the CRM system to achieve those benefits.  Or if the numbers forecast were unrealistic then adjust your business case process such that next time your forecasts/ predictions are much more realistic.  Point being that successful IT organizations are learning organizations where over the course of time they learn from their experiences and thereby improve how they select and how they deliver IT projects. 

Either referring back to your Business Case regularly is an important facet of achieving the ROI you are looking for. 

Maximize ROI by selecting the Right CRM Product in the First Place - Common Mistakes in CRM Selection

So whilst much of this article has focused on achieving the desired ROI with your already chosen CRM product.  One of the more important ways to achieve a good ROI is to select the right software for your business need in the first place.  I could do a whole presentation just on this topic and have done so in the past.  But here in are the highlights of the things to consider in doing an effective software selection...

1. Too Much Focus on Functional Fit - Pareto's Rule applies in Business Application deployments in that 20% of the requirements can create 80% of the effort in service costs for the deployment.  Two different applications can have the same degree of fit but vastly different costs to achieve that last 20%.  So the more important question to ask which comparing two applications is not how many features and functions does the solution have out of the box but rather how much will it cost to build those features and functions it doesn't have and that you will need to build.
   
2. Costs Estimates based on Limited Information - Many times throughout my career I've been presented with an RFT or some other document from a customer and asked to provide a services quote based on it.  Rarely has the information provided been sufficient to provide an accurate estimates.  Clients need to understand that services organizations (both internal or external) will substitute a lack of information with gross assumptions and increase contingency to compensate.  If you take the time to provide more information a better quality services estimate and the software selection decisions it impacts will result.
   
3. Comparing Apples and Oranges - Not all vendor proposals are done on the same or right set of assumptions.  Factors that may affect quoted by your vendor or systems integrator include when the project will start and finish, the number of phases in the delivery, how much the client plans to do for themselves and the level of documentation that is expect.  You need to make sure all these things are clear in the quotes you receive back.  Otherwise you may get a surprise when the actual costs of the project exceed your original quote from the vendor. 
   
4. References but for what? - Often clients seek references showing that the vendor has worked on similar deployments of a like solution.  What they fail to recognise is that the reference demonstrates that the company has done it before but not necessarily the consultant being proposed to work on your specific project.  Unless a consultancy can demonstrate multiple deployments of a similar solution in the same geographical area using some of the same consultants than the reference is meaningless.
5. The forgone conclusion - Psychologists describe the principal of Closure whereby the subject tries to complete the picture put before them seeking supporting facts or ideas.  Organizations often form an opinion about what is the preferred solution early on in the selection process and then seek facts to support the decision.  This can limit the effectiveness of the selection process.
6. Not understanding the Business Case before selecting a solution - Also known as the Shinny Hubcap Syndrome this refers to a favourite tactic by IT sales people to show the prospect features and functions that "they didn't know they need".  If you are an aficionado of Targeted Account Selling this would be referred to as a Flanking or Fragmenting Strategy.  Essentially you try to get the customer to forget about all the previous requirements they've identified and either focus just on a subset of those requirements (Fragmenting) or to change the requirements all together to better suit your solution (Flanking).  Hence why it is important for customers to remember their original Business Case for purchasing a solution and why they are out in market in the first place.   
   

Conclusions

So for those of you who have purchased a new Business Application or CRM Solution congratulations! There are huge opportunities that await you.  But there are also risks. If you've purchased Dynamics CRM then the ROI for your project could be over 200%.  But if you are going to get that ROI then you need to pay heed to my previous pieces of advice...

1. Pick the Right Solution by having an effective Software Selection Process;
2. Have a good Business Case and revisit it throughout the project;
3. It's not about the software it's about the People Process and Technology.  Don't forget the first two;
4. Use a proven Software Deployment Methodology and follow it;
5. Establish your "Conditions of Satisfaction" up front at the beginning of the project; and
6. Recognise that half of solving a problem is know what it is in the first place.  Develop a good plan and stick to it. 

... you do all of the above and that 200% ROI is within your grasp!



David Goad is the Managing Director for eSavvy – Microsoft Dynamics CRM Gold Certified Partner. eSavvy is an award winning Microsoft Dynamics CRM Partner staffed by some of the most experienced solution and technical architects in the Microsoft partner channel. We build and deliver relationship management solutions based on the Microsoft Dynamics CRM platform for large enterprises as well small and midsize businesses in Australia