Microsoft Teams Governance: the basics

We cringe when we hear that word, let alone make a plan for it! Many of us are in a position to quickly roll out Microsoft Teams to accommodate the rapid move to work from home in early 2020. It can be overwhelming trying to wrap governance around a tool as popular as Teams in a way that doesn’t disrupt current workflows.

Regardless of where you are in your journey with Microsoft Teams, it’s not too late to make basic decisions to evaluate for Teams and create common sense for the organization.

1. Who should be able to create teams?

It’s common to limit the ability to create teams to a small, trained group in the early stages of Microsoft Teams deployment. This is accomplished by using a policy to restrict the creation of Microsoft 365 groups by anyone in a particular AAD group.

This requires a premium AAD license for those in that group.

Control who can create Microsoft 365 groups | Microsoft Docs

If creation remains limited after the Teams rollout, I recommend creating an application process for creating and quickly creating new teams.

Also consider not limiting this group to just IT personnel. By training people from different departments to fulfill the requests, you ensure that the request goes to someone who is familiar with how that department or functional area works and who is who. It also ensures that IT does not become a bottleneck and slows the progress of the collaboration.

2. Should there be naming conventions?

Teams naming conventions can be as simple as recommended guidelines communicated to the organization and taught in training sessions, lunch and learning or tutorials. They can also be enforced through M365 Group Policy.

Usually, naming conventions consist of a prefix or suffix added to a team’s name to indicate a project code, team type, department, location, or division.

Naming conventions can complicate the creation process and cause confusion if the need and meaning are not clear to business users.

Examples of Microsoft’s M365 Group naming policies include:

• Prefix suffix naming policy
• You can use prefixes or suffixes to define group naming (for example: “US_My Group_Engineering”). The prefixes/suffixes can be fixed strings or user-defined attributes such as[Afdeling] that are replaced based on the user who creates the group.
• Custom blocked words
  You can upload a set of blocked words specific to your organization that would be blocked for groups created by users. (Example: “CEO, Payroll, HR”).
• Blocked words would prevent well-meaning companies from creating Teams (and sites and M365 groups) with names that mimic the more official workspaces in the organization.

3. Shall we allow guest access?

Seinfeld Newman GuestShould certain teams in your organization be allowed to invite gusts from other organizations into Teams? It’s important to note that guests are given permissions very similar to members. They can add, delete and edit content in channel files tabs and participate in team chat.

By using tenant controls, you can limit which teams can have guests. Once a team has guests, team owners can decide what those guests are allowed to do within the team, such as creating and editing channels.

4. Approved Applications

Microsoft has positioned Teams as a platform for delivering service applications. Not only does it streamline communication and collaboration, but it further reduces context switching by providing easy access to the applications we use day in and day out throughout the organization.

You may decide to allow only the Microsoft apps at first and have discovery conversations with your business departments to discover which third-party apps are in use.

5. Content management and structure

Microsoft Teams makes it possible to bring department, project and functional area collaboration and communication in one application. It also approaches file management and even security differently than users are used to.

Teams (and SharePoint) content management and structures are best used in flat structures. The files tab in teams is really a folder in the documents library of the connected SharePoint team site. This should be the degree of depth in document structures. Additional channels should be created for organizing content, rather than going deeper with nested folders in Files.

Roles have been democratized in Teams. When you’re on the team, you’re on the team. Team members and guests are active participants and contributors to the conversations and content stored in a team’s default channels.

Read-only access to documents can be granted using the SharePoint team site permissions features.

IT departments must work with departments to discover how content is accessed and used within traditional security scenarios. Teams must be built according to the permissions. This could mean that what was once one site with many granularly secure folders, libraries, and subsites is now splitting into multiple teams and team sites.

6. Data Security

As you approach your Teams deployment, consider the sensitivity of data accessed in Teams. Security labels can be used to classify teams that contain sensitive data. It is recommended to have a basic retention policy for Teams. This can be built on as your organization matures in the use of Microsoft Teams.

Yes, there are big decisions to be made that can have a major impact on our business users and data security. Start with the basics and start simple. Build on complexity as needed. Contact departments and functional groups to see what works, what doesn’t, how they work with their content and collaborators. Use this information to create governance that works with them.

Source: pait group