MICROSOFT 365 CLOUD ADOPTION PRINCIPLES
Author: Jonathan Stuckey
Avoiding the adoption disasters with Microsoft 365
(or any Software-as-a-service offering)
At Spoke we spend our entire working lives enabling customers to take on and adopt Office and Microsoft 365 platform. Over the (many) years we come to see that there are a few basic principles which apply to these, and almost all other cloud software-as-a-service offerings.
The following are a summary of core-principles we apply when designing solutions on Office 365, so that organisations can adopt them more readily, with a minimum of re-factoring and user-impact:
Use the services and functionality as designed
Sounds ridiculous right? Its surprising how often we need to help people with this after they've paid for the services.
Remember you bought it "as-a-service" - that means its not a kit-bag or DIY project.
Do not over-ride core functionality, and
building widgets is a last resort with SaaS offerings
Consistency of user experience
User experience carries equal weight to information security - if something is too-hard, people will work-around you and you'll end-up back where you started with shadow-IT.
these services are design to be available anywhere, from any device. Explore what they do/not do
customizing the user-experience and code-development should be kept to a minimum
Let the project establish the capability for the organisation
Don’t look to deliver 1-shot 'Training' during the hand-over. It never works well...
identify key future roles and skills upfront
create improvement mechanisms (multi-layered)
establish baseline education programme
The mantra should be:
educate users as a first-principle
monitor the behaviors and reinforce with communication
restrict access and features as a last resort
Business users are accountable for their actions
the project is responsible for educating users, not policing them.
functional evaluation and adoption has to be part of business-as-usual behaviors for your users
Start small, and extend
create a baseline
try, and hen apply these principles with new functionality
build a process for scoping, trialing, and extending functionality
Establish a rolling-roadmap
Think: Bend, buy, build - not build, build, build
understand what is usable right-now vs. in the future (evergreen releases)
capture needs and requirements, and see if map to out-of-the-box capability in other services
the built-in app-store will often have something that matches
find the right vendor or teams which actually understand the platform *and* your environment
What about Office 365 services specifically?
Not everything will work on Office 365
Office 365 is good, but it’s not Magic. Somethings just do not belong here.
prove what you need to do before you move anything
start small, with rapid incremental steps
build-up a process for harvesting practices and solutions
Admit if something just doesn’t fit and identify where it should go
OneDrive and SharePoint Online are not the same as a shared-drive
just moving things is not acceptable and often will not work as simply as a file-share
clean-out of unnecessary content before you move to new environment
communicate to the business - ultimately they are responsible for their content
Content is King.
Search is not magic – it needs feeding and watering.
Sorry, but all that boring old leg-work people used do to understand what they've got, who needs to use it, how and when.. is still critical.
If you want to find things easily, you will need
to do a spring clean of content before migrating
apply content standards and naming convention(s)
get into the habit of tagging (metadata)
Want to deploy and adopt Microsoft 365 services successfully?
Its not rocket-science. Its people-science... using principles and some rigorous practices.
Microsoft has done a great-job commoditizing the technical setup and deployment of a lot of inter-
connected services. If you want the best from them, you need to do a great-job of enabling your people.
Want to know what we know? Give us a call
If you want to talk about adoption of Office and Microsoft 365, drop us a line: email@example.com
About the author: Jonathan Stuckey