This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
As organizations deploy Microsoft Teams and end-users realize the powerful collaboration benefits, there is often an explosion of new teams being created - especially when self-service team creation is enabled. The creation of a lot of teams can present challenges for organizations, including end-user confusion, and each Teams user being a members of too many teams to actively engage with them.
At Microsoft Ignite 2019, Office Apps & Services MVP Steven Collier talked about this challenge and how organizations can address this challenge in his session "Maintain order while enabling self-service in Microsoft Teams" (THR2063).
Steven suggests a two pronged approach : create a high level teams structure, and use policies to govern their usage.
"If you Don't Give Them a Structure, They Don't Know Where to Start"
Steven's first approach is unique one that I had never seen before, and admittedly took some time to fully appreciate it. He suggested taking a step back and asking "What should and shouldn't be a team in my organization?" The answer to this question will identify big collaboration pillars in your organization such as Projects, Teams, Functions, and Relationships between them, which will allow Administrators and Team owners to build up a root structure that makes it easier for end-users to find the right team, and provide guidance on where to create new teams. If many teams exist, it is best to find the ones that are the largest (by membership) and used the most, and promote them up into a larger team.
Once the larger teams are identified and created, a 'Master' team can be created which acts as convenient end-user Rolodex to the other 'sub-ordinate' teams. The master team uses channels and associated tabs as convenient directory listings of other teams used for Departments, Projects, or other larger Organizational team collaboration initiatives.
Steven highlighted 3 methods that can be used to format the directory listing of teams available in the organization. In addition to richly formatted information about the team, the listing can also include a 'link' in the master team directory so that end-users can navigate to the team they need with one click.
1) Leverage the "Wiki" tab
- The Wiki can be used to format a directory listing of teams with rich meta data (such as purpose, background, etc..), and links to those teams.
2) Use a SharePoint List
- A SharePoint list can be highly customized and added as a tab
- It can be used to trigger flows or embed PowerApps for more functionality or automation such as implementing an approval workflow for teams creation
3) Use a Custom Tab
- Similar to the first two options, a custom tab can host a web site or web app that is formatted in way that best meets describes the teams in the organization, and can be used for integration into other applications
The screenshot shows an example of a logical organizational teams structure for a fictious Shopping Mall operation. There is a root 'Master' team named "Starcourt Mall" that acts as a richly formatted directory with links to other subordinate teams by using channels and formatted tabs. In this example, the right hand pane is using SharePoint List to provide the customized directory listing.
A side benefit to making teams and the associated information more easy to find is that it creates an environment where people feel they don't have to create even more teams.
Use Policies to Automatically Govern the Herd
The second pillar Steven highlighted to meet the challenge of team sprawl is to use several Azure Active Directory (Azure AD) features and policies and to automatically govern some aspects of the creation and life-cycle of teams. Four capabilities were highlighted:
1) Using an Azure AD Security Group to limit Who can Create a team
Organizations can natively enabled or disable self-service team creation which either allows all end-users to create a team, or no end-users to create a team. One feature of the Azure AD P1 license (which comes with EMS license) is the ability to restrict the ability to create team to the membership of a an Azure AD security group.
The membership could be a group of people such as a senior support personnel, department or project leaders, or members of the IT staff.
2) Azure AD Office 365 Expiration Policies
Azure AD group expiration policies are an effective method to clean up teams that are not being used. Administrators create and apply an expiration policy to Office 365 groups associated with teams. A policy expiration period is set, and at the end of that period, group owners are sent an email to renew the Office 365 group. If they do not, the group and associated team and resources will be deleted. The group and team can be recovered up to the first 30 days.
A recent improvement to this policy is that any groups that are being actively used are automatically renewed. Activity is defined by specific actions in the applications that use the associated group. See Office 365 Group Expiration Policy for more information.
3) Azure AD Naming Policies
When a Teams deployment has a large number of teams, a good naming policy can make finding individual teams easier, and can also prevent team names that violate corporate standards. Naming policies are an Azure AD P1 license feature which allow Administrators to enforce a naming policy on Office 365 groups that can either add a Prefix or Suffix based on the value of an AD attribute to the group name, or block certain key words (for example, “CEO, Payroll, HR”).
The policy is applied to the Office 365 group associated with the team and enforces the same rules on the team name in the Teams client.
Steven highlighted a common scenario which is prefixing the group name with the department from the person who created the team.
See Enforce a naming policy on Office 365 groups in Azure Active Directory for more information on Azure AD naming policies.
4) Classification
Classification labels can be created and applied to individual teams. The classification labels are created with the Azure AD PowerShell module, and then assigned to individual teams by team owners. The classification information then appear as extra information for that team in the Teams client, and can help end-users and administrators understand why a team exists, and what it should be used for.
Summary
This was a valuable 20 minute session Steven delivered. With the rapid growth of Teams usage, it is more important then ever to put some order and guard rails before too many teams becomes a real usability issue for organizations.
More helpful articles can be found on Steven's blog at https://regarding365.com/@smcollier.