In Microsoft 365 for example, we get new tools and new improvements regularly. Some people immediately get excited and start using them. But when we try to help innocent users to adopt the tools, we sometimes see challenges and obstacles that have nothing to do with the tool as such. So we will not overcome them by fixing the tool, and we need to stay aware of that. Here are some examples I encountered recently, when we organized a series of training sessions to introduce a new tool.
“Why didn’t we hear anything about this sooner?”
The IT department had set up SharePoint, to replace an old document management system that was falling apart. They did try to get buy-in from the main stakeholders in the business, but it was difficult to get any traction. So IT went ahead and implemented the new toolkit, before the old one died…
But most people in the organization did not know what was happening, why it was happening, what it would mean for them, how they would benefit et cetera. And when we started talking to them in the context of the training sessions that had been initiated, we got a lot of disgruntled response along the line of “why didn’t we know about this?”
So it is important to communicate early and often about developments. Not everyone will be interested, but they people who are interested will at least know about it. And then maybe you can get them onboard as key users or champions.
This is not about the tool, but about communication and engagement.
“You can’t ask us to join a training session when you haven’t finished the new environment”
The timing of when you communicate what, and when you train who, is delicate. One the one hand, you have people who want to learn soon what’s new and what’s hot. But on the other hand, you have plenty of people who do not want to be bothered by new stuff until it works perfectly and is completely finished.
The problem with waiting with your training initiatives until everything is finished, is that nowadays we have a continuously evolving environment. It is never finished. And it if you want to switch off the old system, the people have at least to be empowered to actually get their jobs done using the new system.
So it is key that you explain that they can already get serious benefits from the new system, even if it is not “finished”. And that they can really learn something useful in the training that you propose. They won’t learn everything in that session, but they will learn something worth their time.
This is not about the tool, but about encouraging people to be flexible and accept ongoing change. And about showing respect for the value of their time: don’t waste it.
“You did not involve me, so I won’t cooperate”
One of the teams was experiencing issues: they could not find files that were migrated from the old system into SharePoint. So they told IT about their problem and gave some nicely specific examples. Then IT started to investigate the problem and look for a solution: improving the search center, maybe the metadata need to be migrated in a different way. But they did not keep in touch with the team lead who provided the feedback about their progress and how to deal with the fact that some of the issues are .
As a result, when that team was scheduled to get some SharePoint training, they assumed that all of their problems would be addressed and solved in that session. Because otherwise, why invite them for training now? Unfortunately, that was not the case. The team lead did not actually say “you did not involve me, so I won’t cooperate”, but you could almost hear him think it… He wanted to cancel the training and stop everything. Fortunately, when we had a meeting with him and discussed with him what would be best for that team at this time, we determined together that it would be best to do the training session about the aspects that did already work.
So: go for the personal touch. Talk to people. Get them involved at an early stage or at least offer them the opportunity to get involved. Don’t just push a schedule at them. And don’t hide in your tech cave when you investigate someone’s issue, but keep in touch. Personal touch.
This is not about the tool, but about conversations.
“That is not applicable to us at all!”
We proposed training sessions to all teams in a certain business unit. We had created demo scenarios and exercises using examples from the main field that the business unit is working in. So we optimistically asked the team lead from the ‘minority domain’, if it would be ok to use those existing examples for their training too. The explanation would basically be the same after all. But it was absolutely out of the question to use the examples from the other domain! We saw a similar reaction from other departments: “we are different and the stuff that you did with the others does not apply to us”.
So: you do need to make communication and training as specific as you can. The people need see how it applies to their situation, or they will assume it is not applicable for them and stop paying attention. It does take more time to find examples and tips for every team, but it improves the adoption.
This is not about the tool, but about approaching people in their world. It is also about politics, and respecting the sense of ‘self’ of business units and departments that don’t want to be seen as just part of the ‘One Company’.
“Who will answer our questions after this session? I never get answers!”
People will have questions about any system, especially a new one. And they need to be able to get answers to those questions. They need to know who or how to ask their questions, and then there has to be someone who is actually willing and able to answer them. In most organization, this does not just “happen”. And unfortunately, in too many organizations I’ve seen that the follow-up after implementation of a new system is lacking.
So: make sure you have a proper support system in place. For example, key users in the business, and an accessible and competent helpdesk. Plus clear procedures and “buttons” to contact them. You really cannot skip this.
This is not about the tool, but about your support organization.
So yes, the tool should work properly of course. And preferably it should work excellently for the users. But it is not enough to offer a great tool. You really also need the rest.
