Five things I would check before trying to fix poor Dynamics 365 adoption

When people are not using Dynamics 365 as expected, it is easy to conclude that you have an adoption problem.

The usual responses often follow. More training. More communications. More encouragement from managers. Perhaps another round of system changes.

Sometimes those things are needed. But before doing any of them, I would want to understand why people are not using the system in the first place.

In my experience, what looks like an adoption problem can sometimes be something else entirely. It could be a requirements problem, a process problem, a configuration problem or simply a system that makes someone's job harder than the process it replaced.

So if I were asked to look at poor Dynamics 365 adoption, these are five things I would check first.

1. What business problem was Dynamics 365 supposed to solve?

I would start here because it is surprisingly easy to lose sight of the original reason a system was introduced. What was the organisation trying to improve?

Was the objective to create a better view of customers? Improve case management? Replace spreadsheets? Standardise a sales process? Improve reporting? Reduce manual work? And, just as importantly, was that objective clearly understood by the people who would eventually use the system?

If the purpose is unclear, adoption becomes difficult to judge. A login rate can tell you whether someone accessed Dynamics 365. It cannot tell you whether the system is helping them achieve what the organisation originally intended.

Before trying to increase usage, I would therefore go back to the business case, objectives and requirements and ask a fairly basic question: what did we expect Dynamics 365 to make better? If there is no clear answer, I would address that before talking about adoption.

2. Does the system fit how people actually need to work?

A process can look perfectly reasonable on a diagram and still be frustrating for the person who has to follow it every day. That is why I would spend time understanding what users actually do.

• Where are they leaving Dynamics 365 and going back to Excel?
• Are they maintaining information somewhere else?
• Are they creating their own workarounds?
• Are they entering information purely because the system requires it, without seeing any value from doing so?
• Are there unnecessary fields, approvals or steps?

I find workarounds particularly interesting because they often tell us something. If several people independently find another way to complete the same task, I would not immediately assume they are resistant to change. I would want to understand why their alternative feels easier.

Sometimes the problem is behaviour. Sometimes the process no longer makes sense. Sometimes the system has been configured around an assumed process rather than the way the work actually happens. You cannot diagnose that from usage statistics alone. You have to talk to the people doing the work.

3. Were users genuinely involved?

There is a difference between showing users a system and involving them in designing how it will support their work. I would look back at the implementation.

• Who helped define the requirements?
• Who represented the different user groups?
• Were frontline users involved, or mainly managers and project stakeholders?
• How was User Acceptance Testing carried out? Did UAT test realistic business scenarios, or did it mainly confirm that individual functions worked?
• And what happened to the feedback users provided?

This matters because users often understand operational details that are difficult to capture from process documentation alone. They know the exceptions. They know which information is available at which point in the process. They know where delays occur. They know which shortcuts exist and why.

Good business analysis should bring that knowledge into the design. If it did not happen during implementation, I would bring users into the conversation now before deciding what needs to change.

4. Was adoption treated as more than training?

Training matters, but training and adoption are not the same thing. Someone can know exactly which button to press and still choose not to use the system. I would therefore look beyond the training records.

• Do people understand why the process changed?
• Do managers reinforce the new way of working?
• Are old processes and tools still available, making it easier to avoid Dynamics 365?
• Do users know where to get help?
• Are recurring frustrations being captured and addressed?
• Are new starters being introduced to the system properly?
• Has the organisation continued supporting adoption since go-live, or did the change activity effectively end when the project closed?

Adoption develops over time. People build confidence through repeated use, useful support and seeing that the system genuinely helps them do their job. A training session can contribute to that. It cannot create it on its own.

5. What evidence tells us adoption is actually poor?

Finally, I would challenge the diagnosis itself. What do we mean by "poor adoption"?

• Low login numbers?
• Incomplete records?
• Users maintaining spreadsheets?
• Poor data quality?
• Processes being completed outside Dynamics 365?
• Managers complaining that people are not using the system?

These are different problems and may have different causes. I would want to combine system data with what users and managers are telling us. For example, we might look at usage patterns, completion of important fields, process progression, duplicate or incomplete records, activities taking place outside the system, support requests and recurring user feedback.

The measures should relate to the business outcome we are trying to achieve. If the objective was better visibility of customer interactions, for example, the important question is not simply how many people logged in. It is whether Dynamics 365 is providing the organisation with a more complete and useful view of those interactions. That is a much more meaningful measure of adoption.

Before trying to fix adoption, understand what is causing it

None of this means training, communications, leadership support or system improvements are unimportant. They can all matter. But I would be cautious about prescribing them before understanding the problem.

If people are avoiding Dynamics 365 because the process is unnecessarily complicated, more training on that process may not solve much. If the original requirements were incomplete, another communications campaign will not fix them. And if nobody can clearly explain what business outcome the system was meant to improve, increasing login numbers may simply give you more activity rather than more value.

This is why I see adoption as a business transformation question, not simply a technology or change-management question. It sits at the point where people, processes and technology meet.

So before trying to fix poor Dynamics 365 adoption, I would start by asking: what problem are we actually trying to solve? Sometimes the adoption problem is somewhere else entirely.

---

If poor Dynamics 365 adoption is costing you, the first step is understanding what is really causing it. That is a conversation we are happy to have.

Talk to us   More insights