In November 2011, I wrote a blog post called SharePoint User Adoption Strategy: Team Member “Service Level Agreement.” In that post, I talked about how important it is to start off any project with a shared agreement about how the team is going to work together, including how to organize, tag, and name files in the SharePoint team site. With today’s exciting announcement of the general availability of Microsoft Teams, I offer some updates to that post to ensure that your organization gets the most value out of Microsoft Teams.
Microsoft Teams provides a great way for teams who want a chat experience to connect. If you have been using Slack or another chat tool, you will really love Teams and will probably find some new capabilities that will make your teamwork even more productive. (Here's how Teams stacks up against some of its rivals.)
But if you have been successfully using SharePoint for team collaboration in the past, you may have to do a little adjusting to figure out how to best take advantage of Teams. That’s what I hope to provide with these tips.
The user interface for interacting with Files in the Teams app is different from the document library experience in SharePoint. It’s not a bad experience; it’s just different. And this means now, more than ever, each team needs to establish some norms and conventions for file organization at the start of each project (or establishment of each Team) and each organization needs to establish some ground rules to ensure that your Teams don’t become the wild, wild west.
Here’s a summary of the tips, each of which are explained in more detail below. They are loosely organized based on audience. The first four tips address general Teams planning for the entire organization. The remaining tips are primarily for Team owners.
- Look before you leap: Before you create a new Microsoft Team or Office 365 Group, see if one already exists.
- A rose by any other name: Think about naming conventions for Groups and Teams.
- A Team is a Team and it’s also a Group: If you have an existing Group and want to leverage Teams, be sure to connect the Team and Group at set up.
- Don’t cross the streams: Create a new Team for each project.
- Plan a little but not too much: Do a little up front planning with your team to identify some initial channels—but don’t go overboard.
- Hands off Shared Documents: Try to avoid customizing the default Documents (i.e. Shared%20Documents) library in your Team-connected SharePoint site.
- Files vs. Files: Understand the different user experiences for interacting with files in the Teams vs. SharePoint interfaces—and plan accordingly.
- Tab it! Determine your “go to” user experience for files, but make it easy see the big picture.
- Make the connection two-way: Create a link to your Team from SharePoint.
- Don’t keep it to yourself! Share your tips, ideas, and questions in the Microsoft Tech Community
Tip 1. Look before you leap: Before you create a new Microsoft Team or Office 365 Group, see if one already exists.
I’m going to cheat a bit here and offer a Tip 0: One of the first decisions your organization will wrestle with, if you haven’t already, is whether to allow self-service creation of Teams and Groups. There is no right answer to this question - it involves a trade-off between potentially creating a governance nightmare for IT and getting out of the way of allowing business to move at the speed of … well, business!
If you decide to support self-service creation of Microsoft Teams and Office 365 Groups, provide guidance that reminds all staff that before you create a new Team or Group, you should search to see if a Team or Group for that purpose already exists. The Microsoft Teams app doesn’t currently do any duplicate checking for names – so you can easily create, for example, two Marketing Teams. Behind the scenes, the two Teams will have different Group IDs even if they have the same name – but you can see how confusing this could be for “open” (Public) groups.
An option for dealing with the potential for multiple Teams for the same purpose is to allow anyone to create a new Team or Group but review the new Groups or Teams created each day after they are created. Provide all new Team owners with training resources and to ensure they have verified that there wasn’t an existing Team or Group that could have been used. If you have a reasonably short SLA for reviewing the creation of new Teams, there shouldn’t be too much re-work for the team members if it turns out that there was already an existing Team or Group they should join.
It is also a good governance practice is to set a period (somewhere between 3 and 12 months) where you ask every Team owner to “re-certify” that the Team, the associated Group, and the SharePoint team site are still needed.
Tip 2. A rose by any other name: Think about naming conventions for Groups and Teams.
As my friend Marc Anderson points out, naming conventions for Groups (and Teams) makes a lot of sense. Unfortunately, naming conventions are not easy to enforce if you allow self-service creation of Teams and Groups. Coming up with the naming conventions might not be hard – but ensuring compliance with them can be! One of my clients operates in multiple countries. They are currently launching Office 365, and we plan to use a two-letter country prefix for each Team and Group that is specific to a country. For example, US-Marketing for the US, FR-Marketing for France, and DE-Marketing for Germany.
We’re still trying to figure out whether we should be using a prefix or a suffix to distinguish (and find) “department” Teams versus “project” teams versus “community of practice” teams. We’ve been talking about a code like PRJ or DEPT or COP, but we need to think about whether these should be prefixes or suffixes since scanning a list of names on mobile devices becomes more challenging with limited real estate. And you thought this would be easy?
You may want to create a naming policy using the distribution name policy used by Exchange security groups. You can specify that a prefix, a suffix, or both be applied to all distribution group names. You can also block certain words from being used in the names. Prefixes and suffixes can be a string, an attribute, or a combination of both. Microsoft has some guidance on how to Create a Distribution Group Naming Policy but this is written for your Exchange Admin. You will probably need to plan to bring a team of people to have this conversation and don’t forget to include business users to ensure that your naming policies are friendly to “regular” people and not just your Exchange admins! Note that automated policies must be based on an attribute in Exchange, so you probably won’t be able to create a naming policy that allows you to distinguish between Project and Community groups using this approach. Moreover, this approach will only work for Groups created from the Office 365 Admin Center and in the Mail or People view in Office 365 – it won’t work for Groups created from Teams or SharePoint or Planner, so any naming conventions for Teams will need to rely heavily on communications to your users.
My request for a future enhancement: I’d love to see way to create a taxonomy for Groups and Teams that would provide a way to organize them in a meaningful way—both from an exploration perspective and a governance perspective. (TyGraph has a new tool for just this purpose.) For now, we need to rely on naming—and if everyone can create their own, which is both a benefit (adoption) and a curse (governance), collisions and overlap are inevitable.
Tip 3. A Team is a Team, and it’s also a Group: If you have an existing Group and want to leverage Teams, be sure to connect the Team and Group at set up.
I like to explain the relationship between Teams, Groups, and team sites in the following way: Office 365 Groups are the “Oprah” of membership in Office 365: You get a group and you get a group and you get a group! Any time you need a group of people to be collected together as an entity, the Groups service provides that membership construct. If you are creating a Team, you are going to get an Office 365 Group from Oprah because she’s giving away (not a car, sorry) all membership in Office 365. Create a Team and you will automatically get a Group—for free!
Similarly, SharePoint is the Oprah of Files. Why? Because any time you see a file in Office 365, that file is going to be served up by a file service provided by SharePoint. SharePoint is awesome at managing files!
OK, so how do Oprah and Teams and Groups relate to Tip #3? As I said, creating a Team automatically creates a Group (and all the Group’s associated services). However, you If you are the owner of an existing Group and you want to leverage the Teams user experience, you need to connect the Team to your existing Group when you create the Team. If you don’t connect a new Team to your existing Group, you will create another Group with the same name as an existing Group but with a different Group ID. Fortunately, Teams makes this almost impossible to screw up! When you are in the Teams app and try to create a new Team, Teams recognizes if you are the Owner of a Group and will ask you if you want to add Microsoft Teams to an existing Office 365 group as shown in the image below. This won’t help much if you are not the admin/owner of an existing group—but it’s a start!