How To Avoid Chaos By Following An Office 365 Governance Plan

Office 365 has over 30 different applications. While you may not use all of them, failure to implement some level of governance for your critical and frequently used applications and lead to chaos — and a lot of trouble to unwind down the road.  The following are just some of the pain points that are likely to arise when you don’t follow a governance plan:

• Symptom 1: Users can’t find information, use outdated materials, and don’t know where to put company documentation and materials.
• Symptom 2: You can’t get anyone to use the tools, or you don’t know what they’re using
• Symptom 3: You stumble on data that is being shared with unknown outside accounts
• Symptom 4: You get a lot of phishing emails, and are very concerned about private data escaping
• Symptom 5: When the IT person who managed your Intranet left the company, everything just stopped getting used
• Symptom 6: You don’t know what these tools are good for within your organization
• Symptom 7: The features are always changing and you’re not sure when and how to stay on top of it
• Symptom 8: You struggle with Shadow IT

Have you encountered any of the above issues?

These problems arise when you have organic growth and use.  Content, data collections, teams, sites, folders, permissions, etc. are created, used, and shared at the discretion of most or all end users.  Little to no information architecture has been completed.  Business users lack awareness in the capabilities, so they only use a small fraction of the features or none at all.  There’s a strong need for alignment.

Establishing and executing a governance strategy enables organizations to:

• Understand and close the gap on corporate policies relative to the technology available that can break or help follow those policies
• Align the configuring and security of the technology and tools to align with corporate policies
• Provide guidance to the organization regarding how these tools can help solve real-world business problems in an IT-supported manner
• Bring a group of people together to help define and follow objectives that marry the technology to the needs of the business
• Define specific training opportunities and requirements
• Understand the type of internal support needed for these tools
• Maintain a process to continuous improvement by meeting regularly to discuss how to adjust to the changing needs of the business along with the changing capabilities of the tools that serve it.
• Remove IT as a single point of failure and single “owner” of the technology.

What do you ACTUALLY need to Govern?

Not everything needs governance, some tools are pretty specific and relatively independent.  It certainly depends on how your organization runs culturally, but the following are the common tools and applications that are often cross-used enough to require governance:

• Microsoft Teams
• Intranet (not an application, but common use of the tools)
• SharePoint
• Planner
• OneDrive
• OneNote

It’s important to keep in mind that one of the main goals of governance is to drive user adoption, predictable usage, and trust in the IT department to serve the business.  These factors will drastically help cut down on Shadow IT and the unsanctioned and unsupported use of external tools and sharing of organizational IP.

Microsoft Teams

Teams is new on the scene but is being adopted faster than any other new Microsoft product I’ve ever seen. This is good and bad news for those of us trying to help ensure proper long-term use of such applications.  The tendency for early sprawl is very high, and without a history of experience to rely on, it makes proactive governance more difficult for this type of application.

However, there are governance plans that will help with Teams.  The process is generally the same as the other tools or applications, but you need to understand what Teams is capable of offering so that you can understand what questions to ask to ensure proper guidance.

Teams governance should conclude with an understanding of how you agree your organization will start using Teams, but not necessarily how they will be using it down the road.  You want to understand configuration, naming conventions, permissions, content, lifecycles, sharing, training, support, guidance, and administration.  You also want to know which folks on your team(s) will be responsible for helping to support this plan tactically.

Intranet

Your intranet is your place to disseminate important company information in an organized and “findable” manner.  It makes sense to understand the needs of different departments, ensure they have the training and understanding to follow the process, and the diligence to follow-through on the plan.  Having an agreement and guidance on the type and location of content from multiple stakeholders, and plan to ensure the intranet does not become stale is critical to its long-term success.

Intranets tend to be a cultural phenomenon as opposed to a technical masterpiece.  User Adoption is the primary goal of this type of application.  Keep that in mind as you envision your organization’s needs over time.  The best intranets are the ones where people need to use them to find information.  If you don’t really need one, consider using Microsoft Teams as a quasi-Intranet instead.  Any movement away from using Email as storage mechanism for corporate knowledge and data is a good thing.

SharePoint

SharePoint has had a bad rap over the years because it’s essentially just a platform and set of services.  It doesn’t solve a whole bunch of problems by itself.  It’s not the dining room table and chairs, it’s a pile of lumber and set of nice power tools.  Most people hammer together a couple of 2x4s and then say “SharePoint sucks”, I should have just bought a table and chairs.  Having worked on this platform for over 12 years, I completely understand.  I will offer the counter-point with a Governance spin:

The beauty of SharePoint is that the pile of lumber and tools can make almost anything, but we need to think about what we really need, can build, use, and support.  It’s generally our own fault when our SharePoint implementation fails.  The key is to understand what clearly identified and agreed upon problem is being solved, before planning the build out, use, and support for it.

Governance forces us to ask for what we intend to use technology, and how we plan to use and maintain it.  If we want to use SharePoint for project management, we would create a strategy for naming conventions, permissions, templates, data contained within these sites, their lifecycle and archival plan, ownership, and more.  Most importantly, the governance team would agree to monitor, adjust, and enforce decisions that drive the guided user adoption as intended.

Planner / OneDrive / OneNote

I bundle these three together not because they don’t deserve their own attention, but because of the somewhat more fluid and individual nature of their use.  Planner could definitely have a more guided strategy if teams have expectations around how a board is built and used, but there is a lot of freedom in these particular applications.

Governance around these tools is generally kept at the policy, security, sharing, and training level because restricting how someone takes notes is not the control we want to achieve.  However, guidance for the type of data stored in OneDrive versus a Team or SharePoint site makes a lot of sense.  Knowing that a OneDrive repository will eventually be deleted after an employee departs means that data stored there needs to be user-based, not team-owned.

OneNote can be used as an agreed upon source for certain collaboration tasks within Teams and Sites, with a predictable format of naming conventions for notebooks, sections, and pages, but also allowing for the individual/personal use of these tools in whatever manner suits the employees.

Each application has some elements that can and should be governed while opening up the other aspects for freedom of use.  The key is awareness and training to help business users understand what the tools can do for them.

Build It And They Will Come

Governance does not have to be a multi-month, drawn-out project. In these cases, most organizations will abandon the effort before the go-live date.

Instead, Governance should involve some initial up-front effort, and then a small and consistent (habit-forming) commitment to making minor modifications moving forward. Just like anything else, once the system is built for ongoing success and is well understood, the torch can be passed to other folks on the team to continue the process.

Start small, don’t worry too much about backing yourselves into a corner. Meeting on a regular basis with your governance committee and other stakeholders to discuss the usage and guidance will allow you to make course corrections based on critical feedback from your user base.

Instead of building something without the user in mind, a governance plan allows the process to be intentional and deliberate, as it reinforces to those users that you are there for long-haul to continue the digital transformation journey.