10 Tips for Success designing solutions for Dynamics CRM

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

2. FIT-GAP

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:

·         Ability to list all companies showing name and address of company

·         Ability to edit company information from several different computers with different user logins

And so on.

Imagine trying to define all features of Dynamics CRM this way. Horrible.

It is much easier to start with let’s say Dynamics CRM 2015 and then have requirements such as:

·         New field for storing Company Credit Level on account in the following levels AAA, AA, A, B, B-

·         Only specific group of users are to be allowed to change Company Credit Level on account.

It becomes a lot more to the point.

3. CRM Functional Knowledge

Know what Dynamics CRM does from a functional perspective out of the box.

-          What is Sales Force Automation?

-          How does customer service work?

-          What is customer centricity/360 degree customer perspective?

-          How do you manage a campaign in CRM?

These are things that the people involved in implementing the CRM system need to know. I have seen many implementations where this skill is lacking, it can usually result in existing features being recreated with code, increasing total cost of ownership for the solution. It may also reduce the ability to install addons as these usually are based on the built in features being used.

4. CRM Technical Knowledge

Technical knowledge of the platform is also a vital skill when implementing CRM. These skills include;

-          Configuring CRM

-          Developing CRM

-          Installing CRM On-Prem

-          Setting up CRM-Online

-          What are supported customizations

-          How to minimize TCO of customizations/developments

-          Peculiarities of CRM

o   Native vs manual N:N relationships

o   Date only limitations of multi time zones

o   Visible data model

-          Best practices of developing in CRM

o   Using solutions and publishers

o   Application Lifecycle management (ALM) with Dynamics CRM

o   Solution framework limitations and deployment strategies

As these skills range from high level solution architecture, system architecture to developer and application specialist, it can be hard to find people to fill all these skills.

Due to this reason, it is not uncommon that companies employ technical people without specific Dynamics CRM skills. This often results in data models that are suboptimal with too high level of abstraction, which can be a good idea in a classic code-db application where the data model can be hidden, however, in CRM where the data model becomes very visible, this is not a very good idea.

Another common problem I see is that application specialist with too shallow technical skills are charged with designing data models. This can result in data models that store data in the wrong places, for example account information on contacts due to not truly understanding how where information belongs. These people often also lack the skills of designing more complex data models required for complex problems, which cannot be solved with a too simplistic data model.

5. Business Knowledge

How does the customer’s business work? Sad to say so, but someone actually has to know this when implementing the CRM system. It seems obvious to most of you I hope, but trust me, I have seen and heard the weirdest things, like “oh, you want to book meetings with a customer several times, well, you should have said so”. Some things are so self evident that most people would never think to put them into a requirement.

This skill cannot only be on the customer side, people with some technical skills have to have some business skills as well. Common examples can be that an organization that are moving from an old CRM-system to a new are using sub-optimal business processes due to the fact that the old system limited what they could do, or they might have grown or transitioned. When challenging the business processes that are put into the requirements, it might soon become evident that the best action might actually be to reengineer the business processes to make them leaner and better fit the new organization and also what the new system actually can do. The benefits of this can be many, like faster processes involving fewer steps, higher level of automation and higher quality control abilities to mention a few. However, it is important to understand that it is also scary for an organization that thought they might just start Dynamics CRM Online to get some boost in their sales who start to realize that they might need to undergo a larger organizational change management effort, whatever the potential long term benefits of these are, as not all organizations have the luxury of being able to act in a long term fashion. Hence approaching this subject carefully, is probably advisable.

It is also essential to have a clear high level vision for what role the system is to play, what is its purpose? Sometimes this vision is either non-existent or very blury resulting which makes it complicated to prioritize and focus the implementation on what is important. A simple verison might be to make sure to never drop a single lead and follow up on every quote in a timely manner. Then that vision can guide prioritization of requirements during the implementation.

I have seen this lacking often in several different ways. Sometimes it is simply that a customer explains how they work and then that is implemented, even if the underlying processes that the system is to support are obviously sub optimal, without any discussion with the customer. Many customers I work with, appreciate it when I ask why they want to implement something a certain way, why they work a specific way and what the business goals they are trying to support with the process are.

Another common error I see is that when Dynamics CRM is to be implemented, the requirement is “It is to work and look as much as the old system as possible, but with all the cool features of Dynamics CRM”. This implicitly means that all the old processes are to be used, nothing is to be rethought or reengineered despite the investment in the new system. These implementations very seldom become a hit, and the TCO of maintaining them are usually a nightmare since a lot of code and weird customizations are required to make the system act and look like the old. And the fact is that it never will, especially if the old system was a tailor made, since those systems will always have specific areas which will have an edge on an off-the-shelf system like Dynamics CRM. The benefits of a system like Dynamics CRM are that you will get so much more bang for the buck in OOB features, investments and maintenance that it will be worth it every day of the week, as long as you are can stay within the bounds of what the application supports.

6. Business Goals and requirements

 

The picture above shows the typical process of how functional and non-functional requirements are based on business goals and then technical requirements are based on functional requirements.

What I have often experienced is that customers come to us directly with a technical requirement, for example “Please put a dropdown with the values X, Y, Z” on the account form.” Without actually describing the functional background to it or even less the business goal behind that.

The other common scenario, typical in large tenders, like public tenders, are that the different parts are handled by different people and you are handed a list (in excel typically), with a list of technical or sometimes functional, requirements to which you are to respond to if you and your proposed solution can meet to a different defined degrees. Sad to say, but these lists often set me off laughing, but I guess I should be crying since it is sad, as it is a very sad way of trying to handle requirements.

The people trying to describe these requirements, if they are technical requirements would need very high level of expertise in Dynamics CRM to be able write the requirement properly, and hence almost already have designed the system, pulling out the mat from under the feet from the supplier as this is typically what you would expect them to do.

Hence the arrows underneath pointing back, which indicate what I recommend, that is to never accept a technical requirement without understanding the functional/non-functional requirement behind it and also the business goal behind that and making sure that the technical requirement is actually the best way of solving that part of the business goal and functional requirement. Perhaps both the functional requirement and the technical requirement should be re-written to give a better fit to the system. To some of you, who are used to working in what is called fit-gap perspective, this is a more natural way of working, where you start with the vanilla system and see what is missing from there.

If done properly, and with the trust of the customer, this can greatly reduce the costs of implementation and maintenance. For example, implementing a technical requirement a specific way might require creating or purchasing a third party editable grid, as the technical requirement describes that changes are to be able to be done directly in the grid. However, when the business goals are examined, this might not at all be so critical, it might just be that it the person who wrote the technical requirement didn’t know that this is hard to implement, and by changing this so that changes are done using a standard form, the implementation can be greatly simplified.

The hard part of trying to understand the entire process, from business goals through functional requirements to technical requirements and how these fit Dynamics CRM and then being able to reverse the process

7. User centric

Make it productive and they will use it! Business managers are naturally the people setting the requirements for a CRM system but it is important to remember that it is the normal end users that are the ones that most often will use the system. When working with sales force automation, I often say that it is important to make a sales automation system, not a sales manager automation system. It is sometimes better to have a system with 95% or 98% of all customer records up to date but with only a few fields than 60% of the all customer records with all fields you could fathom.

As far as I have understood it, during the late 1990:ies a lot of CRM-implementations failed and for a few years the entire industry had a down period. Microsoft, when envisioning Dynamics CRM, looked at what the reasons were for the failures of these old systems and found that carrots and sticks had typically been the only motivators used, which had a very limited success rate. Based on this, they decided that a better approach would be to focus Dynamics CRM on personal productivity. Or in other words, making the system so usable for each individual in their own work that they choose to use Dynamics CRM instead of other alternative programs. Despite the fact that Dynamics CRM is based on this principle, it is also very versatile and has many customization options, so this vision for individual business productivity, can easily be broken by an implementor not adhering to this concept.

Consideration also has to be taken on what will happen if your system is not engaging enough, if users do not find it useful enough, my typical answer is that they would probably use Excel to keep track of their personal items. Excel is a hugely versatile tool, especially for 1 or only a few users on the same file. Hence, your mindset should always be to be a lot better, for each individual user, than Excel.

There has been a lot of research on the subject on how to motivate people and what does not motivate them. The interesting thing with this is that it shows that monetary motivators only work for manual labor, not for more creative or more cognitive work. Hence it is also important to align the system with this. If you want to see more on the subject, here is a YouTube clip showing it in a popularized version: https://www.youtube.com/watch?v=u6XAPnuFjJc. 

8. CRM System is just a system

Microsoft Dynamics CRM is just a system after all, and it will not fix broken processes or broken organizations. For this you need good management and perhaps even the aid of good management consultants (note the word “good”, not just any management consultant will do here…).

Sometimes people call me and ask me to install Dynamics CRM so that they can get their sales sorted out. Or they call me say that they just installed or activated CRM Online and want some training. This rings some warning bells in my head and I hope it does so in yours as well.

Sometimes happy salespeople, working both with Dynamics CRM and with competing software, promise the world with the CRM system. “Just start using the system and everything will sort it self out! You’ll see!” – well, I’ve been in a couple of implementations (somewhere between 50 and 100) and that’s not what I’ve seen.

If the organization already is using a CRM system and you replace that with Dynamics CRM, then your chance of success, is of course higher, as the company culture already includes working in aligned processes in the CRM system. However, if it doesn’t and the organization is just implementing CRM from scratch, which is where you have the most to gain, you also have the most to do as people are usually not aligned in harmonized processes but work as the like in their own separate ways and trying to force a CRM system on top of that will just not work.

9. Align with release cadence

So, you have designed a great solution, 230 new entities, approximately 2 M lines of code ontop of Dynamics CRM Online, customer is buying, sales guy is getting a huge bonus and your manger is happier than ever. Looks like you are set for life.

And then Microsoft rolls out a new version of CRM Online every half year and you never manage to finish your project as more and more development effort is put into maintaining the code for every new release. Customer is not so happy any more, sales guy has quit and moved to another company, and your manager is wondering what to do if the customer actually will sue, as they threatened to do, as you broken deliver plan after deliver plan. You seriously consider changing jobs but wouldn’t it be nice to have finished this properly?

Not sure if the story above is true, but it wouldn’t surprise me. Microsoft have decided on an aggressive release cadence to be able to bring new features to the market in time. Independently of if your CRM is in CRM Online or on-premise you need to establish a strategy for how to handle upgrades. With CRM Online, there is not that much lee room but with CRM on-premise you can for instance have a strategy of upgrading every other version half a year after the release. That will make it a lot easier to plan for it.

If you are not aware of it, the release plan from Microsoft are that the major versions are release late in Q4 and the minor version (only online) are release in Q2.

10. Addons

There are a lot of addons available to Dynamics CRM and these can bring great value to you system at a low cost. However, you do need to think about the kind of addon you are installing. I like to do the following classification of addons:

1.       CfMD

2.       Dedicated product company

3.       Other CRM Specialist

4.       External Addon supplier

5.       Open Source

Note that these are not in any falling order. I will try to elaborate a bit more on each of these.

CfMD – Certified for Microsoft Dynamics

A product for Dynamics CRM (and the other Dynamics products) can get the CfMD – certification by going through a process which is rather bureaucratic and at the time of writing this post, broken. However, to get you product certified you have to jump to quite a few hoops which is costly and requires that the product has been on the market for some time as one of the hoops is that it has to have some customer references.

Dedicated product Company

Most of the companies suppling CfMD products are dedicated product companies. This means that their entire existence is based on selling products and support of their products. Hence they are very keen to keep up with Microsoft’s release cadence and have a well-functioning support organization.

Other CRM Specialist

These companies are typically system integrators, consultancies, value added resellers and similar. Their focus lies more in one-offs, understanding the customer’s needs, adapting Dynamics CRM to those needs. Some of these companies have decided to try to make products out of what they have learnt from several project. These might be horizontal solutions, such an integration product to a credit service, or a vertical like a financial services solution. The upside of this is that these companies usually have a deep understanding of CRM and the product they make is usually technically sound. However, the downside is that they are at core not a product company, they sell services. This usually surfaces in two manners. One is when the software needs an upgrade. In this case, a normal product company will have thought of this, in their normal product roadmap which of course is in harmony with the Microsoft cadence. Hence the license cost at a dedicated product company covers the upgrade cost. However, the service based companies typically do not have this mindset. They think more in trying to sell hours and will therefore try to get a customer to pay for the upgrade project, which sometimes succeeds due to good salespeople.

The other time it surfaces is in support. Dedicated product companies usually have support included in the subscription fee/license fee but service companies sell services by the hour and if you call a consultant, you will be charged by the hour.

Do note, that these are generalizations and there are of course exceptions to these, but my general recommendation when looking at addons is to look just as much at the company supplying the addon as on the addon itself. You will probably be entering a relationship for some time so it had better be a good company.

External Addon supplier

These are tricky, typically a company with a particular product seeing Dynamics CRM:s position in the market and wanting to integrated with it so they make their own integration, for CRM 2011 and then they don’t keep track of time and cadence. As an example anyway. Can be CTI integration to a VoIP phone, even certain verticals. I have just as recent as last week gotten a request from a customer for a training for CRM 2011 due to a addon not being upgraded. I have also had requests from new customers saying that they would like CRM 2011 Online as they want this and that addon and it only supports CRM 2011 Online. In Sweden we have a company supplying company credit and financial information which had an integration made, and not upgraded.

Open Source

There are many open source projects for Dynamics CRM. Many people love open source and it can sometimes be nice but you need to be very careful about it as you have no control of if the people developing the product will continue doing so or not. Also there is typically no support to get. However there are some great indispensible open source projects for Dynamics CRM, most namely xrmToolBox, by Tanguy Touzard which included a ton of nice tools.

+ Be part of the community

Number 11, I just couldn’t leave this one out. Of course you should use the great Dynamics CRM community. There are tons of great blogs and stuff on forums. So if you goog… Binged your questions a couple of times too many, don’t be afraid to ask. And you don’t have to be best in the world in a subject to share. Remember that everyone has always been a beginner, and might want to learn from your road to greatness. So, start your CRM blog today. It is never too late, and never too late to take it up again if you stopped.

 

Gustaf Westerlund
MVP, Founder and CTO at CRM-konsulterna AB
www.crmkonsulterna.se