All requirements are not created equal.  Using our standard prioritization process we grouped the requirements by CRM area and rated each requirement for importance.  Grouping requirements by area helps ensure you do not miss critical needs.  Importance ratings can be simple.  In this case the three levels were: Must Have, Important, Nice to Have.  Keeping it simple helps non-technical key users stay focused on requirements, not the rating system. 
 
Each key user rated all requirements across all CRM areas in a simple spreadsheet format.  Even for areas where the key user does not work, they often have valuable insight.  We then combined individual ratings into a single consolidated spreadsheet and the group met to discuss and arrive at a consensus rating for each requirement.  Key users seeing where their ratings differed from others and working together to reach a consensus is a powerful tool for building the buy-in that is critical for long-term adoption and success of the CRM.
 
Identifying CRM systems that would meet the requirements started with considering the existing ERP system, since any new CRM system needed to work hand in hand with it.  The ERP system was an on-premises system, using a Windows environment and a SQL backend.  The ERP vendor has a CRM module, and was pushing hard for the company to buy it, saying “it’ll be plug and play!” 
 
Sounds like a no-brainer – right?  Why didn’t the company just do that in the first place and not spend time on requirements and evaluations?  Well, not so fast.  It might very well turn out to not be the right solution, and knowing other options helps make an informed decision.  We have seen too many companies try to use a tool just because they already had it, only to find out it was a very expensive mistake.  Just because you own a hammer doesn’t mean you should use it to drive screws.
 
Options fell into several types: the ERP system’s CRM module, other on-premise 3rd party CRM systems, and cloud-based 3rd party CRM systems (like Salesforce).  Both on-premise and cloud 3rd party systems would require integration.  The long-term IT strategy included three goals that applied to this project: (1) move applications to the cloud to reduce in-house infrastructure costs and reduce the skillset depth needed to support on-premise systems, (2) use the current ERP system for at least the next 3-5 years, and (3) except when it would provide a competitive advantage, use standard functionality in application and stay away from extensive customizations.  The decision was made to focus the evaluation on two options, the ERP system’s CRM module and Salesforce.
 
We evaluated the two options similar to how we prioritized the requirements.  Each key user rated each option on all the requirements using a five-step scale:

1. Std = Standard Functionality (works how we need it already)
2. Mod = Modification (changes needed just for us)
3. Enh = Enhancement (will be included in a future version)
4. 3rd = Third Party (someone else's software bolts on to do this)
5. NS = Not Supported (they don't do this and don't plan to)

We then combined individual ratings into a single consolidated spreadsheet and the group met to discuss and arrive at a consensus rating for each requirement.
 
Evaluating the two options led to some interesting discoveries.  Overall, both were generally strong solutions for this company’s needs, and could be made to work.  The vendor’s CRM was already a module of the overall ERP system so no integration would be required.  Salesforce would require an integration, although there was a standard integration available (if it truly integrated all necessary data).  Salesforce did a better job of connecting with email for capturing inbound and outbound emails; the vendor’s CRM would require a customization to meet the company’s requirement (this would have been missed without doing the requirements definition).  Neither would add significantly to internal IT’s support burden, although being an additional supplier, Saleforce would add an additional possible point of failure (and finger-pointing).  Salesforce had more flexibility especially in workflow management, although coming at the price of additional customization.  Interestingly, price did not turn out to be a significant factor.
 
In the final analysis, the vendor’s CRM module was chosen.  Keys to the decision were the seamless integration, single user interface, and speed to results.  The company was very satisfied with the process and results of the project, and we were chosen to help lead the implementation of the CRM module.  Of course, that will be another case study – stay tuned!  (or call us and we will tell you all about it…)
 
Key Takeaways:

1. Understand your requirements before looking at potential solutions
2. Involve your key users in a structured evaluation process
3. Start building buy-in early
4. Using objective criteria results in strong decisions

 

To learn more about Software Selection, Implementation, and Project Management services, contact us today! – (206) 876-9229 or Click Here