A few weeks ago I was in Reno, attending the CRM User Group Summit as a presenter and of course CRM UG Medic. My most visited presentation with more around 80 participants, was on 10 tips for success designing CRM Solutions.
The general idea is when designing solutions for Dynamics CRM there are some things that you have to take special care for and that I often see people missing, so it is partly in the positive, ie DO this, but also in the negative, DON’T DO this.
1. Most important issues first
Make sure to focus on what is really important for the business when implementing CRM. Too often focus is put on technical details instead of the issues that really make differences for the business. Like making sure to never miss a quote, never miss following up a lead and how the system is to support this.
Sadly often a lot of effort is instead put into making more or less perfect solutions, especially when working in more classical waterfall project methods when it is not uncommon that an improportial amount of effort is put into fixing rather insignificant features and features of high business impact are almost over looked as “trivial”.
Base your requirements on Microsoft CRM. Not on a blank sheet of paper. Some organizations start off with trying to set requirements in a very general which might be useful if you do not know if it is a CRM system that you are choosing. However, the market is changing and more and more customers are becoming more and more aware and have come further in their decision process prior to contacting a partner or setting down any requirements. This usually results in the fact that many organizations buying CRM already have chosen a CRM system when contacting a partner, and hence defining requirements from the bottom up is not very useful, it is a lot better to start from the system that has been selected and based on this, look at what is missing.
Other beneficial aspects of this can be that when defining requirements without the context of a system, it is easy to get fixed on a certain way of solving a problem. If instead, starting with a particular CRM system, it is much easier to define what is missing or what needs to be changed in order for this system to work for us, without being locked down by previous conceptions of how a particular problem should be solved that were agreed upon during the requirement gathering/analysis phase.
The most typical non-fit-gap requirements I have seen are public procurements. In these cases the procuring entity believes that it is more objective to not decide on a system before hand and hence define the entire CRM system in the requirements. It is not uncommon in these requirements to see requirements such as: