Governance quick start for Microsoft Teams
The following activities will happen simultaneously, and they may involve all or part of your key team. As a best practice, defer large-scale governance and security conversations for after you have completed your initial experimentation with Teams. This will simplify the decisions you will need to make at that later date. For this phase there are some decisions that need to be made. To successfully make them you will 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?
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 will allow your early adopters to create additional teams if needed. Monitoring this behavior will give you key information for your broad deployment.
Decision 2: Teams naming conventions
You will 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 will give 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 will appear 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 your Teams implementation by using the appropriate tenant controls.
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.
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. We recommend including video chats and VoIP meetings in your experimentation to gain more value from your Teams implementation.
Decision 6: 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 or Office 365. You may need to coordinate this work with your technical team because Microsoft 365 or Office 365 administrator rights are required to complete this work.
Decision 7: 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