Governance quick start for Microsoft Teams
The following activities happen simultaneously, and they might involve all or part of your key team. As a best practice, defer large-scale governance and security conversations for after you complete your initial experimentation with Teams. It's important to understand how governance decisions might impact the end-user experience and will simplify the decisions you need to make at that later date. For this phase there are some decisions that need to be made. To successfully make them you first need to answer the following questions:
- Which stakeholder from your earlier assessment is a good candidate to participate in this limited business onboarding?
- Has this individual (or group of individuals) suggested use cases that would be good candidates for this phase?
- Do they have enough interest from employees in their organization to be early adopters and give you meaningful and regular feedback?
To learn more, read Plan for governance in Teams and Plan for lifecycle management in Teams.
Decisions
Make the following decisions (at this point, these decisions apply only to Phase 2):
Decision 1: Who can create teams
For the purposes of this phase you can restrict who is able to create teams to the early adopter population in addition to your core project team. This allows your early adopters to create other teams if needed. Monitoring this behavior gives you the key information for your broad deployment.
Decision 2: Teams naming conventions
You'll likely want to implement some naming conventions for your broad deployment of Teams, and check for duplicate names. In Phase 2 we suggest that you implement a manual naming convention for your initial projects only. The best practice for this is to conduct an interactive onboarding with the early adopter project team and allow them to select their own name. This gives you insight into how employees think about their work and will be essential in creating a larger scale naming convention at a later time. (Additional information on the elements of an interactive onboarding appears later in this guide.)
Decision 3: Guest access
Depending on the scope and type of your project and the nature of your industry, enabling secure collaboration with partners or vendors may be an essential capability you want to test. You can limit who can add guests to teams by using the appropriate tenant controls, and limit which teams are open to guests by using sensitivity labels. You can additionally ensure that guests adhere to organizational security requirements such as the use of Multi-Factor Authentication (MFA).
Decision 4: Approved apps
The best case use of Teams includes the integration of other apps into the experience. At a minimum your technical team should enable the first party and featured apps in your Teams experience. Depending on your use case and other apps used in your organization, you may opt to include additional apps as a part of your controlled experiment. Be sure to vet any third party apps to ensure they adhere to your organization’s security and compliance requirements.
Decision 5: Are meetings included in your test?
The Teams meeting experience is high quality, supports video chatting, and brings your employees together to be more effective. Consult with your technical team to make sure that your environment is ready to include simple VoIP meetings. Enabling audio conferencing or voice services would normally be excluded from this phase of your experimentation; however, that depends on your core project team, your technical readiness, and the state of other voice/meeting services in your organization. Technical readiness should include things such as meeting room equipment, end-user devices and accessories, and the network. We recommend including video chats and VoIP meetings in your experimentation to gain more value from your Teams implementation.
Decision 6: Content management and structure
Teams works best when users work end-to-end within the platform - instead of requiring them to continually switch back to legacy systems and services - and offers new ways of working that differ from how users are accustomed. As part of your experiment, work with your participants to consider team structures and channels that embrace the multi-modal ways of collaborating within Teams, and avoid simply replicating existing folder and storage structures. Additionally, consider any compliance requirements for content stored outside of existing supported systems such as records management or backup systems.
Decision 7: Data security
In preparation for your broad deployment you may opt to use security labels to classify the types of teams in your environment. For the purposes of this experiment we recommend that you refer to Plan for Governance in Teams and ensure that a basic retention policy has been set on Teams data in your Microsoft 365. You may need to coordinate this work with your technical team because Microsoft 365 administrator rights are required to complete this work.
Decision 8: Length of your experiment
A successful Teams implementation proceeds at a healthy pace to ensure appropriate momentum, focus, and learnings. We recommend that this phase of your project be 60 days in length to ensure that your early adopters complete sufficient business cycles. Extending experimentation for too lengthy a time increases the risk of a failed change program; however, this time will vary for every organization.
Next: Define usage scenarios