The Seven Deadly Sins (when implementing your CRM software)15 min read

What particular risks might a small or medium-sized business encounter while undertaking a Customer Relationship Management (CRM) project?

In over a decade of helping businesses implement Microsoft’s Dynamics 365 CRM system, we’ve seen most of the challenges you could conceivably imagine threatening the smooth delivery of a project.

We like to be prepared – so we always have the common risks that might face you in your project at the back of our minds. And because we subscribe fully to the idea of heading off problems before they arise, we wanted to share those with you now, before you embark on your next technology project. So, without further ado, here are the seven project risks your business might face.

RISK #1: THE PROJECT MANAGER LEAVES YOUR BUSINESS

There are several issues here. Firstly, in all relationships between people in teams, there’s a “Forming, Storming and Norming” period when, before the Norming phase, the project is going to run less efficiently or effectively. Changing a project manager puts in a renewed Forming and Storming impact when it might not be wanted or productive.

Secondly, there is a risk that the outgoing project manager leaves with many important elements of the plan hidden inside their head, rather than committed to the electronic page, and when they leave they take that knowledge with them.

This could relate to a process, approach, or agreement and if it isn’t fully documented it can be lost. For all the documentation that does exist, there might still be a lot of ‘metadata’ in the outgoing Project Manager’s head, and it disappears. That often has to be re-engineered by the replacement Project Manager.

The result is often a delay because it takes time for the new Project Manager to get up to speed. If the new Project Manager is not an incumbent to the company they may take time to get up to speed with the key stakeholders and processes.

MITIGATION

One way to mitigate the risks associated with a change of Project Manager during a project, is to ensure project scope and plans, risks and assumptions are detailed, captured, referenced, and communicated throughout the project lifetime. This provides ‘One Version of the Truth’, to the benefit of all involved in the project, but it is particularly invaluable for a handover and smoother transition in the event that there is any change to stakeholders.

You have both steerers and joiners in a project and often joiners will be engaged in the project when it is already in flight, meaning that they need to get up to speed quickly to be effective in – and to add value to – the delivery of the project. Having a clearly documented plan, updated progress reports, key milestones and an understanding of project desirables is key to the success of the project when joiners are introduced.

Another option is to provide a bonus incentive for Project Managers, provided upon completion of the project in full, on time and within scope. This encourages project managers to see the project through from conception to completion and within the boundaries of project expectations.

A third option is to have a more junior Project Managers support in place, an individual who understands the project plan, desirables and expectations to implement the required next steps. This will ensure there is always additional resource to use in such a scenario.

RISK #2: KEY STAKEHOLDER LEAVES YOUR BUSINESS

Key Stakeholders are often directors of sales, marketing or operations who are senior champions of the project in your company. When a Key Stakeholder leaves, perhaps even the project sponsor, the driving rationale can change.

A new Key Stakeholder may not have the same appetite for the project – sometimes it can be more, sometimes less. If they have more appetite, this can result in delay because they have new ideas or demands that can impact scope, resource and cost, particularly if new change requests or more functionality is added to the project.

Less appetite, on the other hand, can impact the project timeline, resulting in delay or the project stalling or halting and not being delivered as per original expectations delaying an ultimate ROI.

“When a new stakeholder comes in, they often have a different view of what the project should entail and, of course, different doesn’t always mean less.

Through the life of the project, many decisions would have been made to change small elements. Projects usually start as detailed set of requirements but no project ends up delivering exactly those elements – there are features that change along the way. And the decision as to why and how and what to change is usually in the head of the original stakeholder. So, that metadata is lost.”

(Jim Alsop, Principle Consultant, Cloud9 Insight)

MITIGATION

If you consider that your business may have a change in key stakeholders during the life cycle of the project, consider delaying the project, or keeping the scope smaller for a phase 1.

In the event that you do have an unexpected change of project stakeholder or sponsor, give priority where possible to complete the planned phase as scoped, unless there is a significant change in company direction.

The planned project is often a great starting point to make future enhancements that should always have been planned anyway.

The project gives a foundation of understanding of the capabilities of Microsoft Dynamics 365 to support generation of ideas for how the solution will further support the business success.

RISK #3: A LACK OF RESOURCE

It is crucial to plan for the resources needed to carry out effective testing and preparation or cleansing of data and their time is freed up to be involved. Resources assigned need to have the right level of experience.

Very often, if resource planning is not managed effectively things can go wrong causing project delays. It’s essential that decisions are turned around quickly and that all stakeholders required to attend training understand the importance of doing so.

It is also critical for clients to appoint their own Project Manager to co-ordinate internal resources including having the right people attend key project meetings to aid quick decision making.

“If testing isn’t done properly, it’s the small things then that get missed, like usability – the UX, rather than just the functionality. The other thing that often happens is that there’s a change management loss insofar as people are not bought into the newly implemented system.

They know that they didn’t fully test it when it was being built because they were too busy doing other stuff and then they complain about it when it doesn’t work. In the worst cases, people begin to wash their hands of the new CRM.”

(Jim Alsop, Principle Consultant, Cloud9 Insight)

MITIGATION

It should be the Client Project Manager’s responsibility to organise User Acceptance Testing (UAT). However, the Key Stakeholder is accountable for ensuring both the availability and attendance of the relevant parties to test the system.

Cloud9 Insight have time allocated to train the testers but sometimes when undertaking the training, two or three of the intended six trainees are missing – and that is a recipe for failure. The testing is not just done to understand whether something that’s built has errors, or is missing elements.

Testing is a validation that the original requirements can support and are aligned to current business needs. What we want to get out of testing is not just confidence that we know about any errors but that the implementation will succeed in the real working world to ensure highest levels of user adoption.

RISK #4: LITTLE OUTPUT FROM USER ACCEPTANCE TESTING (UAT)

This is a related risk to Risk #3, though it happens not when there is a lack of people testing – but when they’re not giving much feedback. This can happen because they did not feel empowered to speak up, did not quite understand what their role was, or did not have enough time so they rushed-tested the system.

It could also have been that the client culture stopped them feeling free to report their concerns. If we don’t get the feedback, you can end up with problems like missed errors. The reality is that people have a day job and their CRM project can be treated as a side thought.

We deal with companies of the size where if you don’t dedicate people to the project – with colleagues engaging in their spare time – this can lead to problems further down the track.

MITIGATION

Flag up every issue and, moreover, do it in a detailed way. It’s not just volume that’s important but also quality. For example, somebody might send feedback that consists of: “I found it really difficult”.

However, what works much better is: “I was doing x, in y part of the system and when I tried to do z, it was really difficult.”

RISK #5: SCOPE CREEP

The project scope is defined during the planning phase and should be clearly understood and accessible for reference throughout the project. Any changes to the original scope should be raised as a ‘change request’, and should be agreed and signed off by both parties to ensure consistency and to identify the impact of the change which could be related to time, cost or quality of the project.

Project deliverables are not always known at the start of a project and time and resource must be allowed to provide a contingency plan for any additional requirements. This is about understanding whether a feature is critical for a first phase.

Just because it is a feature that will make the system work a little better, it might not be critical to get to Go Live. Every time you try to add a feature, you’re going to delay that Go Live.

Sometimes it’s worth putting some elements of your project into a second phase, say two or three weeks later, than to delay the whole project to try and make it perfect.

MITIGATION

You shouldn’t plan for a perfect project; you should plan for one that gets the business done.

Ensure the scope is documented and understood by the project team and any changes to the original plan are agreed, implemented, and highlighted. The project scope should be clear, devoid of ambiguity and agreed by both parties.

The project team should be kept informed, at all times, to avoid any potential misunderstandings.

RISK #6: LACK OF CHANGE MANAGEMENT EXPERTISE

There is often a lack of understanding of what is good practice in implementing a new operating system or piece of software. It’s easy simply to create content for training, and then go live. But it might not be enough.

The fear of change caused by an innovation, or the mistrust in the differences it will bring, can lead to a number of undesirable outcomes that can hamper or kill a project. This element of risk is as complex as it is important to grasp.

So we felt the topic deserved an article to itself setting out what can go wrong and how you can use good Change Management practice to head-off any mishaps (see the article in our eBook ‘Renewal, Risk and Resistance – the Three Rs of Change Management’.

But to give you flavour of the suite of risks associated with change, and to help you understand why you need to have at least a basic understanding of how to manage change, we’ll focus on just one risk here: poor communication that squanders adoption or buy-in of the innovation(s) driving the change.

To be specific, there’s often a lack of understanding of how much the change will cause a challenge to other people. Sometimes management assume the new innovation or system will work just because it’s there.

In reality, those on the ‘shop floor’ using the system, for example a new CRM, are not consulted or given the opportunity to provide feedback on the challenges they might be experiencing.

A full communications plan, keeping affected colleagues informed and able to comment on the project is essential. This could even take the form of an internal marketing plan that builds excitement about the change and explains the benefits clearly.

“Change needs to be marketed just like any product, service, innovation or idea. By way of analogy, the pop star Adele’s songs are brilliant. In fact, she could launch an album and it would sell tomorrow.

But her management knew they could do even better than that with her new album, “30”. So they started putting up marketing materials featuring the number “30” all over the world.

Then they changed the colours on her website and adopted other guerilla marketing tactics.

They were effectively producing change management materials to create a vibe. That sort of thinking, even if it may not be appropriate to every organisation, is worth bearing in mind when you’re bringing in changes.”

(Jim Alsop, Principle Consultant, Cloud9 Insight)

MITIGATION

Please see our eBook for Danielle Wibling’s thoughts on Change Management.

RISK #7: DATA CLEANSING

A key reason why clients are implementing CRMs like Microsoft Dynamics 365 is that they have disparate data, which usually means data of variable quality, and sometimes the same data held in different places.

You have to make tough decisions sometimes about what data should be migrated into the new system and from where. Cleansing is time-consuming and is hated by users, which might be why it was never cleansed in the first place – nobody was looking at it.

This is not as important when you don’t have a CRM system but when you have implemented a solution, the quality of the data becomes crucial. Cleansing takes time and people leave it to the last minute or farm it out to the set person who owns that record.

Inevitably, that person then rushes the job. So, the risks are around delay, quality, and not being able to use the system or the system features. There can also be a risk of wasting time.

For example, a director might tell everybody in a business to clean all their contact records and people might spend hours doing so. But if they don’t have a way of keeping all those contacts in one place, that data might have to be cleansed again and maybe even a third time, making that director unpopular.

In CRMs such as Microsoft Dynamics 365, there are a number of key data records, such as contacts and customer records and, depending on the business, elements like open leads and open opportunities.

Those basic data records are only as good in the system as the quality of the original data entry.

EXAMPLE

We’ve known of several organisations that planned to take advantage of a lot of the marketing capabilities of their CRM, including automated emails.

But they found the emails were being addressed to incorrect names because nobody had put their first name in the first name field. Many of the outstanding features of Dynamics will fail if the data that feeds them is poor.

Another company we knew was allowed to key in town names in their new system and they had more than a dozen names for a single city, including versions with different county names attached and some with postcodes.

“There’s an expression common among data engineers: ‘Put rubbish in; get rubbish out.” If you input suboptimal data, you might end up with a system that’s exactly the same as what you had before – or worse.

There’s also a misunderstanding of the right time to do data cleansing. One consideration is whether to do the cleansing just before the data is transferred. If your data is suboptimal, you should start making a decision on what to cleanse today.

This involves deciding whether to even bring in some data in, because there might be some that you will never need to look at again. Why invest all the time cleansing the information in these cases? It’s about cleansing the right data early enough.”

(Jim Alsop, Principle Consultant, Cloud9 Insight)

MITIGATION

Unfortunately, data cleansing is a very manual process, which is why you should prioritise and plan, very early on, what data you are going to cleanse and what data you are going to set aside.

There’s no loss in investing time cleansing data very early on, especially the data that’s important, because actually it helps with the day job today. So make sure your data is good now.

A good CRM partner will show their client early on the data structure and the templates that will be used to import it. That then that gives that client a tool with which they can question whether their data fits the new system.

If it doesn’t, then they can go and fix it before it becomes a major headache.

FINAL THOUGHT…

I believe the biggest project risk is trying to get a CRM, like Microsoft Dynamics 365, to do something it shouldn’t and that another system would be better placed to cover. Think of the Microsoft Office suite, for example, as a knife and fork and a spoon.

You wouldn’t try and consume soup with a fork. So don’t try and make Dynamics do something that another product is more suited to doing. Diary management is a good example. Actually, you should be using Outlook as the diary management tool and synchronising it with Dynamics.

Another example is order management fulfillment, which is really better managed by an Enterprise Resource Planning (ERP) system. There are often better products into which we can integrate Dynamics that would do a better job.

Sometimes, people say they want a system built because they want all their features and functions in one place when, actually, they’re not better all being together in one piece of technology.

It’s common to believe a business can run on a single piece of software, when the reality is they never will. What you will often need is one view of what’s going on with your customers, not one tool that you that colleagues use for everything.