Stephanie Kahlam
Microsoft has offers many guides that identify important items to consider and discuss before you roll out Teams to your organization. Plan for Teams Governance
My personal “Best Practice” item to consider is deciding who can create Teams.
This is an important consideration and one that should be discussed early in the planning stages.
What?
By default anyone who is a member of the organization can create a Team. Depending on how big your organization is this default setting could turn into an Administrative nightmare. Without any governance in place the ability for anyone to create a Team could lead to what is known as ‘Teams Sprawl’ or ‘Content Sprawl’.
So What?
In order to answer So What? We first need to understand what happens when a user creates a Team.
When a Team is created the following process takes place:
- First a M365 Group is created and all the associated services that come with it
- A shared Outlook inbox
- A shared calendar
- A SharePoint Site
- A Planner
- A OneNote notebook
- Power BI
- The SharePoint site is provisioned during this process
- The Team is configured and group services are extended to it
In the end when one user creates a Team they actually create
- An M365 Group
- A SharePoint site
- A Team
So consider that if your organization had 100 users and each user created only one Team apiece the Team Sprawl would look like this
- 100 random M365 Groups
- 100 associated SharePoint sites
- 100 random Teams
In reality the numbers would be much higher cause if you can push a button and get a Team users will do this more than once.
Locking down the ability to create Teams to specific people or departments etc. is an important consideration and decision to make. And one that needs to implemented before Teams is rolled out to an organization.
Now What?
To prevent Team Sprawl you need to lock down who can create a Team and this is done by restricting who can create M365 Groups.
Perhaps there might be hesitation in doing this because the responsibility of creating Teams will fall to a group of people or department. This is an understandable concern if the volume of Teams creation requests will be large. This is where an organization might consider “automating” the Teams creation requests.
- Locking M365 Group Creation down will reduce Administrative clean up.
- Employing a user driven Teams request process will empower the user while maintaining organization requirements for how Teams will be created.
In this scenario all the necessary governance around how a Team is created would be configured first so that the end result is a Team that meets all the business requirements:
- Naming convention
- Whether Guests are allowed or not allowed
- Custom Channels if desired
- Members added
- Security configurations for members and guests
- SP site customizations
- and more depending on the business needs…
This model can be configured with an approval process upon user submission to ensure requests meet valid criteria for creating a new Team. This process will also help to:
- Eliminate the possibility of Team Sprawl
- Provide business required configurations for new Teams
- Include security practices and governance to protect the organization
- Empower users to take part in the process and reduce Administrative overhead
In Conclusion
If you are thinking about deploying Teams in your organization give you and your project team ample time to consider what will be needed. Plan out what types of governance will be required and how it will be configured to meet the needs of the business. Locking down who can create a Team is a very good first step and followed up with automating the Teams creation process will ensure those governance practices are in place. Happy users and happy Admins!