How to Conduct a Successful CRM Project?

Too many people and organisations embark on a CRM implementation project with little or no understanding of how to conduct a successful CRM project. This approach is not unlike driving a car with little (or no) visibility - like the car here.

Would you drive a car like this?

Is this how you drive your CRM implementation projects?

I have seen a car similar to the one illustrated above, being driven onto the freeway!! - when I worked in the United States in 1991.  However, I have seen many CRM projects, in countries all round the world, being conducted with a lack of visibility, similar to, or worse than, this.

In this article I cover three points:

1. The importance of understanding CRM project success
2. How to identify an expert - and a charlatan
3. How to use understanding to ensure your CRM success

The lack of understanding that causes the project failure may be any of:

• A failure to grasp the project objectives
• Not understanding how to do an implementation project, and particularly the importance of change management in the success
• Lack of knowledge of the technology being implemented
• Not knowing the value or detail of the data that needs to come into the solution

These four types of issues are seen in various ways in most of the less-than-successful CRM projects – both in those where I am invited in to assist in the recovery or the improvement and in others that I only hear about.

The Microsoft Dynamics 365 family is complex, and businesses need to have experienced professionals with deep understanding in their team to help them ensure success and maximize the return on their investment.

Last year a study by Faye Business Systems identified 25 reasons why CRM projects fail. I discuss these reasons and distil them down into these few overarching groups, then show you how to avoid them, in my presentation ‘All Roads Lead to Rome - Understanding is Key in Successful CRM’.

Bringing in an ‘expert’ from outside, perhaps from an advisory firm, superficially sounds like an easy solution, even if it may be expensive. However, how do you identify an expert in a subject domain about which you and your colleagues have little knowledge?  This is a challenge faced by many people from CEOs and CIOs down to managers in organisations who have decided to implement CRM or a similar line-of-business solution.

I am helping a client at the moment who brought in a major consulting firm to lead their Microsoft Dynamics 365 deployment. It later transpired that the solution architect allocated to the project had never been involved in a Dynamics 365 project previously.

When the project was two years late, I was asked to give a second opinion. My conclusion was that to achieve any of the originally stated, very reasonable aims (using ClickDimensions and basic reporting) would require a complete redeployment – which we have now almost completely accomplished by returning to out-of-the-box Microsoft Dynamics 365 in less than six months.  However, we now face a challenging data migration project to bring data from the original solution to the new solution.

As well as a completely novice solution architect, it has also transpired that the only previous Dynamics 365 experience within the entire expert consulting team was with the offshore technical resource – and they were not able to overrule the solution architect, largely for cultural reasons!

While this example is probably the worst example of project failure caused by non-expert ‘experts’ that I have seen, it is certainly not the only example.

However, had my now-client been able to ask questions to identify the solution architect’s experience, knowledge of the domain, accreditation and other attributes of an expert, they would have quickly identified him as a charlatan and saved themselves a lot of time and a huge amount of stress and misery.

When using any larger firm, it is essential to confirm not that the firm has the appropriate experience, but the people on your project have the appropriate skills and experience; and that new people joining the project also have the appropriate skills and experience.

So, what is the solution?

Understanding is the solution

Just as you would be unlikely to allow anyone to drive your car – even without snow completely impeding the vision – without confirming that they had a valid licence and suitable experience, you should not embark on a project of this nature without confirming that within your organisation you possess the necessary understanding.

This understanding is your insurance against project failure

Just as you trust that you will never need most of the insurance that you carry personally, you hope that you do not find yourself in an implementation project where your insurance gets you out of big trouble. But, if you do end up in big trouble, without the insurance you really regret it.  That is why you spend the money on the insurance.

Having the understanding internally of the organisation, protects you from needing your insurance in several ways:

• You can recognise a charlatan
• You can identify the low-hanging fruit or quick wins within the project
• You can support your team as the project progresses

I am not saying that you should not use external resources - far from it.  Most projects of this nature require external resources.  However, understanding the difference between an expert who can make decisions and then guide other team members, and someone who can just provide labour on the project under guidance or an expert, is essential. This difference is also frequently not made clear by suppliers - which makes it more important for you, the client, to confirm what you are getting for your money.

A 'CRM Developer' is a great example.  A CRM developer may be someone with 20plus years of technical experience working across different technologies and different versions of those technologies for a wide range of organisations and holding several certifications.  Or they may be just starting out in their career.  While I rant about "The Curse of the CRM Developer" a "Functional Consultant" or a Solution Architect is similar.  Within whatever time they have worked in the domain, they may be very specialised, or they may have a wide range of less deep experience.  If someone claims five years of experience, do they have five years, or six months of experience repeated ten times!

Do you have the understanding to differentiate between these types of people?

As a person learns more about CRM, or any other area of expertise, they move up the 'expertise ladder' from novice to expert.  

In parallel with the increase in simple technical competence, there is also an increase in the ability to see actions in terms of longer terms goals and an aptitude to see the situation more holistically.

Many organisations who supply people onto projects appear to deliberately 'muddy the waters' by reducing everyone to consultants, or perhaps technical consultants and functional consultants. A consultant is an advisor.  Most of the people sold as 'consultants' are anything but advisors - they are do-ers. And this muddying is not limited to CRM Developers!  

During your project you will likely need people who can

• configure the technology,
• write code for when configuration does not go far enough
• data migration people
• test your solution
• train your team members

and more.

Some people on the eventual team may only have one of these necessary skills, while others will have several necessary skills.

However, although you need to have experienced professionals with a deep understanding - functional, technical and methodology - in your team, by providing high-quality education to team members, you move everyone up the expertise ladder.  By moving people up this ladder you achieve many benefits, including increasing the internal skills and the ability to recognise someone who perhaps does not have the skills that they claim.

In turn, this means that your CRM project will be driven with wide visibility, towards the ultimate destination of CRM success.