This post is based on our recent webinar “Tailing Microsoft Teams for Maximum Productivity.” Watch the full session here!
Let’s face it. Departments have a different number of users, deal with different sensitivity of the information, and are overseen by different industry regulations—shouldn’t they have different policies for their Microsoft Teams?
A “one size fits all” approach typically results in departments handling more sensitive information relegated to email. Or conversely, other departments where time to market is crucial are hampered by the strict policies of the most rigorous department and may even resort to shadow IT.
PixelMill’s Eric Overfield and AvePoint’s John Peluso sat down to discuss how to overcome this barrier while also explaining how to create Team templates that can be cloned during their “Tailoring Microsoft Teams for Maximum Productivity” webinar. Read on for some of the highlights!
How to Create Pre-Configured Teams
Microsoft Teams templates are starting points for Teams. They define what tabs exist in each channel, what channels exist in each tab, and what apps may be associated.
As it stands, these “base templates” are created by Microsoft, aren’t extensible, and can’t be created by users. From this base, however, users can programmatically add and configure channels, apps, and tabs to meet your specific needs (though this requires an experienced coder or someone who’s experienced with PowerShell).
“Cloning” a Team
The other option for creating a pre-configured Team is “cloning” a Team. This means starting from an existing reference Team and building a new one that has the same channels, tabs, settings, apps, etc.
Since copying a Team can be done by a user or programmatically, this makes it much more agile an option than using a Teams template. However, the tabs and apps don’t copy their configurations; some scripting will still be required in-app.
So, where do I start?
Key 1: Get Informed
First, it’s important to stay in the loop of what Microsoft has planned for Microsoft Teams as a whole going forward. We recommend following their roadmap to see where they’re taking the product and how it relates back to what you’re using specifically.
You then want to look into what can be templated and automated to see how efficiently you might be able to stand up Teams in your environment. Finally, it’s critical to know what your organizational limitations are. How much time do you have to spend on this? How many resources? How much technical expertise do you have access to? Answering all of these questions is critical before starting on your Microsoft Teams journey.
Key 2: Planning–Set Up for Success
The planning process starts with talking to your users. This can be via interviewing, sending out surveys, holding focus groups, and so on. The key here isn’t just to ask them what they need, but to uncover that naturally by asking what they typically do day-to-day and finding out what their pain points are.
As you’re talking to your users, you’re going to want to select a few specific groups and Teams that you can use as pilots before rolling Teams out to the entire organization. Find the tech enthusiasts at your organization who are interested in like what Teams has to offer, and ask them to join early. Listen to their feedback, see what they need to succeed, and evaluate the time and budget that might be needed to make it happen at scale.
Key 3: Prototyping
Next, you’ll want to start prototyping the solutions you can build. You’ll start with a blank canvas of a Team, add the aforementioned pilot users to it, and see what channels, apps, tabs, and so on they all need to work at their best.
While going through this prototyping process, consider what is and isn’t possible to templatize. Are there certain governance requirements to keep in mind? Are certain apps you want to add unable to work as part of a template? Make sure you know the answer before extending this template to your entire organization.
As you go through this prototyping phase, start to steadily refine what your ideal Teams will look like. When refining and gaining feedback from your early adopters, take into account:
Naming Conventions: Think long-term about how to make what each Team is about easily understandable from a glance. Don’t try to incorporate what each Team maps back to and what each Team’s sensitivity level is in the name; it’ll be all pre-fixes and suffixes before you know it. It’s also important to standardize whatever convention you decide on across the board so each Team matches another.
Static Channels: Instead of building a channel for each weekly update of a major project (leaving dozens of channels deserted as time goes on), consider making a channel dedicated to that project with the weekly updates as threads inside. In short, try to create channels with long-term usage in mind.
Surface Data Tabs: Surfacing applications and documents as their own tabs will be much more efficient for anyone planning to immerse themselves in a Team. Including this in the prototype will show management how much time he/she will be able to save at a glance.
For further in-depth recommendations on templatization, testing, QA, and evolving your Microsoft Teams tenant, watch the full webinar for free here!