04-03-2017 11:05 AM - edited 05-06-2017 03:51 PM
04-03-2017 11:05 AM - edited 05-06-2017 03:51 PM
This April, we're putting the focus on conversations in the Driving Adoption community. We kick off the discussion with insights from Microsoft research we conducted on IT Pros.
Where Does End-User Adoption Start?
End-user adoption is clearly top of mind. In our research last year, 87% of IT Pros said that driving Office 365 end-user adoption was a priority initiative in the next two years. But “adoption” refers to a wide-range of actions – some of which occur before you even deploy a new product. We asked IT Pros what adoption actions either their organizations or they, as individuals, were involved in.
High-maturity cloud companies (companies with 6+ products in the cloud) were more likely to engage in pre-deployment adoption activities.
Already deployed? There are still plenty of actions you can take now!
In April, we’ll be discussing end-user adoption best practices, success stories, sharing resources, and answering your questions. We’ll elaborate on the actions we listed above and open the conversation to discuss any challenges/questions you have on the community!
What adoption actions do you or your organization take? When did the conversation around end-user adoption start?
Read these other posts featured during 'End User Adoption' month:
04-03-2017 05:06 PM
04-04-2017 01:50 AMSolution
Too many organisations fail to fully understand where they and their employees are at when they decide to move to Office 365 in terms of how they work. The first point in pre deployment is so important. But from experience it is often overlooked. Too often it is seen as a project with a start and end date. That's why the post deployment elements usually end too quickly. The training sessions are over, the training materials produced and gathering dust and so on. But adoption doesn't stop. It's ongoing. So organisations need to plan and cost for that over an extended period of time.
Migration is also not treated as a major change management exercise. It changes significantly how people work. What tools they currently use and have to learn to use. They are expected to change their habits just because you have given them a new set of tools. That's hard to do.
As all organisations are different and depending on size it gets more and more difficult, it's important to understand how people work and what tools they use and indeed what their work day habits are. You could do this by surveys, focus groups/meetings. Then this will give you a picture of what Office 365 can bring or problems it can solve. Focus on the problems it can solve first. Show people how the tools and ways of working can solve those problems. Office 365 can't be all things to everyone. You have to focus on the little battles, the quick wins, the simpler problems. Get those right and you will be on your way.
After deployment you can assess whether those problems have been 'fixed' for people. If not you have to go back and see what went wrong. If they have then move to the next set of problems.
As Office 365 continues to change and offer new features you have to aware of any problems that can be fixed but also problems that may arise from a change or new feature (bug!!). That is where the ongoing adoption process comes in. It's why Office 365 adoption and migration is not a project, it's a journey with bumpy roads....
04-05-2017 07:57 AM - edited 04-05-2017 07:57 AM
That's a great question Benjamin - we found that it has a lot to do with ownership. Those companies can thank their IT Decision Makers (ITDMs) and IT Implementers (ITIs) - they are more likely to take ownership of Office 365. At low cloud maturity companies there is no primary owner.
ITDMs at high cloud maturity companites are twice as likely to have been involved in deployment, likely an indicator of what enabled early cloud success. ITIs assume ownership as the company matures. ITIs are more likely to be primarily responsible as ITDMs pass off ownership and move on to new initiatives.
04-05-2017 10:08 PM
Thanks for these insights @Anna Chu You are telling a story that is dear to my heart. In too many cases change and adoption is seen as a task to begin in the last stage of deployment. However, to have an effective deployment organisations need to engage all stakeholders from users to senior executives from the inception. Given cloud projects often have rapid deployment early engagement of all stakeholders in change and adoption is essential.
That approach gives them the greatest chance of deploying to use cases and communities that are receptive and actually want what is being deployed. A corporate objective that makes no sense to users is unlikely to win much adoption. Equally a user solution that has no corporate objective will not last long. Balancing both of these and supporting adoption bottom up and top down through the life of the project is key to success.
04-10-2017 12:00 PM
I've found that any end-user that has control of a process can cause greater adoption of tools as they integrate them into any process changes. Other end-users are likely to follow procedures given to them, even if tools they don't understand or generally use are included. It's a great way to open the door to discussions and illustrating the value of tools and applications.
04-10-2017 12:07 PM
If pre-deployment there isn't any thought given to potential process changes and execution of those changes in post-deployment by any end-user owning a process, then the new tools won't be used as they should.
04-10-2017 12:23 PM
Couldn't agree more with Simon! It's so crucial to take the time to find out both what matters to the organization and to the user regarding Office 365.
I think most organizations struggle with this because they've chosen either an organizational-focused adoption strategy or a user-focused one. True success with Office 365 is only found when you bring both of those together and your adoption efforts are committed to creating wins for both groups.
04-11-2017 11:36 AM
I do think many company's assume that because they've already deployed the software, that it's too late to drive adoption...or they assume their first push was all they really needed to do. Then, when they look at their usage metrics, they are shocked that their software usage looks like a barren waste land.
Anytime a user is given new software, the first question they usually ask is, "how do I still do my job?" We need to start by helping the user feel less resistant to the change. Too often, adoption efforts only focus on returning the user to the status quo. Why did we buy the software if our plan is to just use it the exact same way we used our previous software?
It's best to start early, before deployment, but it's never too late to start the process of educating your users. Introduce how the products will not only help them do their job they way they did before, but faster, more efficiently, and with higher quality outputs. Once they've mastered the essential concepts, then we need to raise their sights to new ideas. There is always a better way, users just don't know those better ways exist. We find that continually reinforcing ideas and sharing new ways to get more out of your software will drive lasting change.
04-27-2017 08:39 AM
Some really good points made by all in this thread.
I also want to reiterate the point that a few of you made: adoption is an ongoing process. It doesn't stop after an event like deployment. If you don't nurture the commitment to the platform and to your people, the initiatives will wither way. No doubt.
A while back I was compelled to write an article from my own experiences around SharePoint specific adoption activities. Would love some feedback on it:
04-28-2017 03:45 PM
I think everyone is in an agreement that Adoption never stops and that is an on going process.
But it is intersting that the title of this post is "When Does End-User Adoption Start?"
In the technology and services industry we typically see cases arrise that have a "Need" that we immediately try to fill with "new technology" before we understand the User-Base completely.
A User Base is typically composed of Primary, Secondary and Tiertiary Users. That if done incorrectly become to "non-specfic". How many times doe we hear "oh my user base is between 18-65, they are male and female, and they are tech savvy and not tech savvy..." The key take away is that this example User-Base is too grey to understand what "Adoption" even looks like to know if has started.
A good way of understanding your User-Bases are to build somehwhat granular or more accurate micro Personas, these help to identify what expectations are set for Adoption. As soon as you know what to look for, it helps to understand the driving motivations that "kick-start" Adoption, and to identify it when its happening.
This is how good Adoption "Starts"
a month ago