Is Microsoft 365 adoption a project or a service?

Historically, many of our waterfall IT implementation projects classified training as part of the project rollout effort. End-user communications were done in broad waves (usually via mass employee e-mails or non-personalized intranet news articles), and training efforts were limited to a phase of the project rollout schedule. With our move to agile, many organizations have expanded training in an effort to drive sustained user adoption. But the critical question still remains: Should Microsoft 365 adoption be treated as part of your rollout project or as an ongoing service?

In most cases, the answer is dictated by funding. Organizations with a fixed-dollar approach to implementing Microsoft 365 tend to view end-user training and adoption as a part of the implementation project (regardless of whether they’re running in waterfall or agile). Organizations with a more fluid funding model or a cultural drive for ongoing employee education may invest in resources to support ongoing Microsoft 365 user adoption efforts.

How do project-based and service-based adoption efforts differ?
Project-based user adoption is temporary, with a defined start and end date. If you’re running adoption as a service, you’ll be investing in user adoption on a continuous basis. You may be staffing virtual or in-person office hours, leading training classes, hosting user group meetings, coaching employees on how to use Microsoft 365, etc.

As I’ve mentioned in previous posts, user adoption isn’t a temporary effort. There is no magic formula for success and adoption doesn’t have an end date. If you want successful adoption of Microsoft 365, you’ll need to build, evolve, and drive adoption from now until the day you stop leveraging the platform. Even the most successful adoption programs will die without dedicated attention and fresh ideas.

What does an agile adoption service look like?
Agile Microsoft 365 adoption services will vary by organization and industry. There is no one-size-fits-most approach to building a successful adoption service – you will need to figure out what works for your users.

A few key things to take into consideration as you design your adoption service:

• Ongoing resource availability. Adoption requires time. You can run successful adoption programs with employee volunteers, but it is always beneficial to have staff dedicated to driving Microsoft 365 adoption. Dedicated staff give you access to time and resources on an ongoing basis, along with the ability to track adoption goals as part of employee performance.
• Focus on the outcomes. User adoption isn’t an exact science. A user adoption best-practice that has worked amazingly well in one organization will completely fail at another. Your users and your company culture have an immense impact on the success or failure of your adoption initiatives. I recommend taking an iterative, outcome-based approach to user adoption. Try out new ideas with an adaptable mindset. See what works and what doesn’t, and don’t get attached to ideas until you know they work for your organization.
• Be creative. When you run a long-term adoption service, you run the risk of users tuning out your message. You’ll need to evolve your approach and messaging to be noticed. Don’t be afraid to be creative and think outside the box!