Microsoft Teams is fast becoming the go-to application for managing communication and information flow within organizations. We wrote HERE about how Teams will be supplanting email for internal communication in the near future. Many organizations don't plan their technology deployments and this is a big mistake. Just because you can "turn on" Teams and start using it doesn't mean you should!
Most organizations start with Teams as a simple chat client. Then they start randomly creating teams to see what that's all about. They are not realizing each team that is created also makes a SharePoint site, OneNote notebook, Exchange mailbox, and a shared calendar. All of these resources are now deployed and typically underutilized or overlooked. Fast forward a couple of months and some departments use Teams, while the rest of the organization is not aware it even exists. This leads to a LOSS of productivity as users are not sure where information is being shared from, and there is no uniform standard for how to utilize this great new application.
Here are three suggestions to make your Microsoft Teams rollout go smoothly:
1. Hire or utilize an outside partner that has EXPERIENCE rolling out Teams.
This may seem like overkill, but it's critical to engage with a partner that has experience mapping all the functionality of Teams into your organization's workflows. Simply flipping the switch and creating a bunch of teams is a recipe for confusion and low user adoption. Not what we are looking for.
A qualified partner should be able to understand your business processes and workflows and clearly map those into a Teams framework. Are most of your users in department-centric groups that rarely work outside of this area? Are almost all your users working in a cross-departmental fashion with a customer or project being the focus? Do you collaborate often with users OUTSIDE your organization?
Understanding how the organization currently functions is a key step in a successful Teams implementation. An outside partner will bring perspectives on how to do this efficiently and often will result in workflow IMPROVEMENTS that are hard to discover if you are "part of the problem".
2. Dedicate internal group admins for Teams
The flexibility of Teams can be a blessing or a curse. At initial roll-out we want to restrict end users ability to create new teams, and have those requests flow to designated group admins. These admins may be internal or external depending on how your IT is supported. The difference between needing a team, a channel, or group chat can often be lost on end users when they are first starting with Teams. Suddenly, there are three teams created for handling the same customer or project, and end users become frustrated.
Once Teams has been successfully rolled out, removing this restriction may make sense, but we have found most end users appreciate the insight the admins provide them. Often it can lead to not needing a new team, creation of a channel, or a named group chat. Team admins become very valuable workflow experts!
3. Create a Teams usage charter
Create a Teams charter to outline how teams, channels, and chat will be used across the organization. This also should clearly show when and how Teams should be used in place of email. We often find that end users will send an email, follow-up in a direct Teams chat and then post a note on the channel all asking for the same information. This is NOT what we are going for!
Clearly laying out how the different components of Teams map to existing workflows is helpful for end users. For instance, rather than sending an email and CC'ing everyone in the department about a customer issue, you would now start a new thread in the customer support channel and @ notify the appropriate users. Being clear about how end users should utilize the different components of Teams drastically improves adoption and productivity!
Microsoft Teams is going to be the de-facto communications hub for organizations over the next five years. It brings together all the components needed in a simple, intuitive interface, that end users are familiar with. That doesn't mean that it should be "turned on" with no planning or oversight!