Best Practices for Welcoming Users to Office 365

I have seen many implementations of SharePoint and Office 365. The most common mistakes include shallow understanding of this powerful CMS app, insufficient planning, and just dumping it on employees without proper training. I cannot emphasize enough how important your initial design and configuration of a site is. It will make all your future growth and changes easy or difficult due to unforeseen limitations.

First, 99% of you need to accept that you probably do not understand even 10% of what this powerful attempt at an all-encompassing content management system can do. So let’s do the first step – envisioning how it would fit our needs.

Do you need content management that minimizes folders, automates processing, requires assigned power users as admins for sites, pages and lists\libraries?
Do you have a fair idea of the access rights you want each group\user to have?
Do you understand how to inherit groups, rights, etc. from Active Directory?
Do you know how to use Azure (AD, calculations, etc.)
Do you know how to identify and activate proper features at the site collection and subsite levels? (turning on a feature like publishing has irreversible consequences)
Do you know the multiple ways to create pull down menus?
Are you ready to pay a designer\developer to build the branding and custom processing you want to see included? (Caveat w\this CMS – It is NOT easily customizable unless you know HTML, CSS, JavaScript and maybe Designer).
Do you understand web parts?
1. How to create and place a web part not yet in the content library?
2. Including JQuery?
3. How to utilize a hidden Content Editor Web Part (CEWP)?
Do you understand how to share content?
1. Excel spreadsheets, docs, etc.?
2. Calendars?
3. Site content? (for multiple subsites\lists\libraries where you change once and it updates everywhere used)
Do you understand List\Library views? (instead of folders or worse, multiple myriad of lists\libraries).

There are more (a lot more!), but I think you get the idea. Architecting your site properly with lots of planning is CRITICAL! Good error handling pages and processes are also critical to how the system will be accepted. No one likes being dumped to an anonymous error like “505 error”. It should have a sorry message and links to get back to work and perhaps notify an administrator or the help desk.

Next and probably equally important, is how to get your users onboard. Let’s face it, change is challenging and while resistance might be futile, it is also inevitable. Convincing your team the new system is good for both productivity and to ease their jobs is a challenge and to be considered carefully. Of course, you included user input on the design and features, right? After all, who knows what would make a process better than those who use it the most?

For architecting a new solution, it is my preference to include stakeholder(s) who work with the process daily (or will). This might include the users inputting the forms, those receiving the form through the workflow, how long to wait for them to act before sending reminders to them and a manager or the submitter. Then what to do for rejected forms requiring changes or how to archive a rejected application.

A new hire can set off a request to IT to add a new user either automatically or manually with proper rights, an announcement be posted on the site, a regimen of steps for the new employee to follow (and be tracked and manager/HR updated on each step), proper filings, etc. The same in reverse when a user leaves the firm with the addition of assigning all files owned\assigned to said user being reassigned to avoid error conditions.

Bringing Users Onboard a new system

Step 1: An introductory email noting advantages of the new system and training steps.

Step 2: Face-to-face introductory training in a classroom or webinar.

Step 3: Online Q&A sessions for issues, problems, and the inevitable questions.

Step 4: Online “instant” help via either Skype for Business or a Help Desk process.

Step 5: Follow up newsletters, notifications of changes, new features, Q&A section, etc. with “brown bag” Q&A sessions with your resident CMS guru (who obviously values that users USE this system and do not need to be experts in workarounds.

The introductions can be done in small groups or companywide depending on how many questions you expect to handle (a panel of experts can handle a lot of questions). The expert in charge of the onboarding should make rounds asking for questions, encouraging the system’s use, and generally making themselves available. The onsite stage should last at least 3 days. If you are bringing in departments in phases, he\she should be onsite for each group for 3 days.

Then the expert should be available via Skype for Business (or through the help desk) where users can all see him\her as available (green status) for instant questions, screen-sharing walkthroughs, demos, etc. This person should be “instantly” available most of the time. The faster he\she can move from onsite to online support will provide warm, fuzzy comfort to users trying to master the new system.

There should also be a process to submit requests for changes, also with a quick response time. Users who know their questions and issues will be very quickly resolved is critical to acceptance. They should be able to focus on their jobs, not becoming an IT expert. Those who want to learn more can do so as “power users” or even some kind of administrator (lists, libraries, pages and subsites all should have an assigned administrator and their name noted with a link to send them a request\question).

How long should the onboarding expert be made available? That depends on your help desk. 6 months to one year if there is a good help desk (trained by this expert). Demand for assistance will decline but never completely disappear. A well-trained help desk can take over at some point.

Conclusion

For a well-planned, architected, built and user trained conversion to Office 365 or any other CMS, the process sets the tone for future acceptance and use of the system. If it is done right, it becomes an integral part of your process. Like all things Microsoft, you can control whether it is more a “love it” than “hate it” relationship. Consideration of user onboarding makes everyone more likely to lean toward the former than the latter. And that makes everyone happy.