Why do so many CRM implementations fail?

Dynamics 365/CRM is an extremely powerful platform to create amazing Business Apps. So why do so many projects go wrong? Well, for many of the same reasons many Movies fail at the box-office (around 60% according to the 2016 figures) . First of all, everyone involved in making the Movie needs to be top-notch, from the script-writer, to the director, the actors, the camera crew and a whole lot of other people involved in it. If you don’t have sufficient budget, it is very hard to make a great Movie as all these “experts” cost loads of money. And even then, there is no guarantee the resultant outcome will be a success with the end-customer (the spectator). Because it is hard to predict spectator expectation.

Over-complicating the story is another reason for flops. People like Movies they can understand. Make it too complicated and the viewer loses interest quickly.

But how can the movie-making process be improved for higher success rate?

What if the film script was not “hard-coded”? What if it could be a simple idea at the beginning and a Short was made of it vey quickly and put in front of the spectator and the feedback was taken into account to change and extend the Movie? What if this could be done over and over again iteratively until all the best ideas were incorporated and the spectator was involved from the beginning and throughout the whole “making” process.

So why do they not make Movies this way?

Because it would cost too much and it would take too long. Though technology nowadays, allows some experimentation to see which scene works best before including it in the Movie, it is still not flexible enough to allow the film makers to control where the Movie is going.

How does all this relate to CRM implementation projects?

Well, many of these projects have only a few (if any) experts involved in them. The users (spectators) are asked what they want in the project at the beginning and some user requirements are similar to spectacular Movie scenes that are extremely hard to create and still they get into the specs  even though a simpler alternative scene would have had the same effect. Everyone then goes off to develop the project from the “hard-coded” Requirements Document (the script) with little space for maneuvering.  However when the project is ready to go on air, the users mostly do not find what they were expecting.  Therefore, either it is not adopted or lots of changes (re-makes) are asked for, making times and costs soar beyond plans and budgets.

Also, many of the requirements force the team to over-customize the CRM system, albeit using supported mechanisms. These over-customizations are fragile. Too many moving parts and too complex to maintain, slowing down, and sometimes stopping, the solution from evolving.

Evolving is the key: CRM projects need to Evolve

A finished Movie cannot be changed. You can do a remake or a Part II at great cost, but you cannot change the original Movie. But CRM implementations need to change, since Business Requirements are always changing.  Whilst you are writing the specs down, they have already changed!

Change is real and required, so no point fighting it. We just need to be able to cater for it. And cater for it at the speed change occurs, otherwise we are always lagging behind.

What does AgileXRM bring to the table to help Dynamics 365/CRM projects succeed?

Short Answer:

• Faster Turnarounds
• Less Dependency on Experts
• No need to Over-Customize
• Allows an Iterative “Creation” Process
• Same model throughout: Design, Runtime, Monitoring

Long Answer:

FAST IS GOOD

Projects need inertia and nothing dampens inertia more than slowness. If users need to wait for something to arrive for too long, they get bored. If you can keep a fast pace in the project the inertia is intact and pushes the project forward.

A partner of ours did a study to see how much time was saved in their projects using OOTB Dynamics 365/CRM versus with AgileXRM Add-On. Well, they found a whopping 50% time-saving, or in another words, it doubles the productivity.

NOT EVERYONE NEEDS TO BE A GURU

There is a profound shortage of Dynamics 365/CRM experts out there. You are lucky if you have one in your team. Developing performant Workflows or designing BPFs and coding Plugins or UI JavaScript, integration, modelling relationships and implementing security, etc. all require skill and lots of it. So projects are either waiting for the expert to do his/her bits or there is no expert, and the brave team members soldier on, doing their best and searching for expert advice on the internet.

AgileXRM lowers the resource skill requirements. Being Low-Code means less specialized abilities are needed to achieve higher results. Being homogenous means no need to decipher which bit of the requirement goes where (WF vs Plugins vs Actions vs BPF vs Custom Activities vs JavaScript versus Business Rules – and recently – vs Flow vs LogicApps vs PowerApps). In AgileXRM everything is done through configuration of basic blocks in the same way (with the occasional simple JavaScript for certain specific UI requirements).

For example, some junior consultants in some of our clients, build, manage and maintain very complex Dynamics 365/CRM AgileXRM-aided solutions out there. We are talking cross-departamental and/or cross-organization, cross-system and high-volume core-business processes with hundreds of steps and rules within them. Not the kind of thing you would throw at a junior! But they go deliver with the help of AgileXRM.

This doesn’t mean you don’t need experts anymore! No way! Somebody still needs to define the overall architecture and design of the solution, and overlook the project as it evolves, but much less hands-on and much less of the expert’s time is required.

K.I.S.S.

Why does over-customization occur in the first place? Sometimes because the Project Team doesn’t filter the requirements and lets the user design the system, but more often, it is because real business requirements tend to be very complex in the first place. And by the time you implement such requirements, you find you have tons of customizations all over the place, all interdependent and no one person in the team able to understand all the bits. Complex requirements should not imply complex solutions. If the complex requirement could be broken down to manageable chunks, then the solution could become simply elegant.  This is what AgileXRM provides. A way to break down these complex requirements to understandable blocks, simple pieces that can be quickly assembled and also maintained over time.

For example, we arrived on the scene in one client, nearly 2.5 years after their project had started. They had gone live for a year but user adoption was so low that the whole project was about to be scrapped. The SI contacted us, and their principal consultant, single-handedly managed to implement those very complex requirements with AgileXRM in 3 months the way the users wanted. And he did it without prior knowledge of our Add-on. But don’t wait to fail before resorting to AgileXRM. The earlier you use it the better the results and the simpler the solution.  Keep It So Simple!

GO ROUND IN CIRCLES

No one knows all the requirements upfront. It arrives in trickles. When you ask, users express all they know, mostly about the happy-path, but when they see the resultant solution, they remember all the other cases they forgot to mention. Usually this is a “problem” as changing things already developed is not easy, and is even more complicated if the solution is out there running in production.

With AgileXRM, asking for change is always welcomed! It thrives on it! This is how the solutions is iteratively improved. In a Banking client, the full Credit Cards Claims Process (a 120-page comprehensive analysis doc) was modeled, configured and published to UAT in 9 days (by two consultants). In the following 2 weeks, users getting to use the system, asked for 33 additional changes to the process that were not contemplated in the original specs. These changes were added daily, until one month after starting the modelling, the users had the real Business Process up and running in PRO, not the theoretical one in the docs.

So the circle is: Hear what user wants–>Configure and deploy it quickly so user sees it working–>Hear what user wants, and so on. Iterate Quickly!

W.Y.S.I.W.Y.G.

Seeing is Believing. So if the users can see they are part of the solution creation process then half of your problems are solved: No User Adoption issues; No bad surprises; No Them versus Us. To be able to involve them properly the creation process should be visual and lasting. If you model the business processes visually then the user never sees the model again in runtime, the disconnect gap grows, because you have implemented your interpretation of the model which well may be different to the user’s interpretation. If user sees the same model in execution, then it is a different story.

With AgileXRM the same business process model that is designed is the same one users see at runtime. What you model is what you execute and monitor.

This also helps greatly to detect where processes can be improved. The business process is not buried underneath lots of disparate bits, but is explicit and in front of everyone. This is what the term “Let’s read of the same page” means.

Conclusions

Implementing Dynamics 365/CRM should not be like making a Movie, but rather more like making a TV Show series where the producers deliver episodes frequently and take all the spectator feedback into account for the next episode. It is like a series created by the spectators for the spectators, with the supervision of the producers to make sure common sense is not lost on the way.

This all sounds very much like the Agile Manifesto. And it is not a coincidence that the product name has the word Agile in it: AgileXRM.

Bring Agility to your Dynamics 365/CRM projects with AgileXRM and Happy Implementing!