A common scenario I have encountered with customers recently is the new capabilities within Office 365 pertaining to Groups and Teams. Microsoft has put a significant push to have customers use these (even as to go so far as to say "use it first, understand it later"), but if you are like me and many of the companies I have worked with, you're not too eager to jump blindly into the abyss.
There are numerous articles and posts out there that explain what Office 365 Groups are and what Teams are, so I am not going to reiterate what has already been well documented. Instead, I hope to provide a little guidance on when to use a Group over a Team and visa versa.
It's About Collaboration
This one is obvious... The whole purpose for Groups and Teams (and Office 365 in general) is to improve productivity through improved collaboration. The challenge here is that not everyone wants to collaborate the same way, so using a specific technology may feel natural to some, while it will feel forced to others.
We all have become familiar with the Office 365 core tools (Exchange Online, SharePoint Online, Skype for Business Online) as most of us started out when these were all on-premises tools... granted it was Office Communications Server and Lync before it became Skype for Business Online.
Whenever there is a need to collaborate, typically this means spinning up a SharePoint team site so there was a common place to post updates and announcements as well as store and share documents. This also typically means creating an Exchange email distribution list or a shared email mailbox for communications. And sometimes this means setting up other shared resources, such as a shared calendar or task list to help manage activities that are being collaborated on.
Completing all these preparations just to start collaborating often required numerous support requests to systems administrators to provision resources, security requests to create the necessary permissions and access, and sometimes even hardware requests to support the all these necessary workloads (should you still be on-premises).
Office 365 Groups and Teams address this by providing "automated provisioning" of all the necessary resources needed for collaboration to occur.
Of course this does present the concern that Groups and Teams are an "all or nothing" approach when it comes to the specific resources in Office 365 that are provisioned, but that is a whole other discussion with user management, licensing, and compliance that is far out of scope for this post.
When looking at everything that can be provisioned, it is very confusing as Teams is listed as part of Groups... so one would think if you are using a Group, you are using a Team. Technically this is correct as Teams builds upon what Groups offers, it is simply a shift in how we look at collaboration.
Without going into all the fine details, let me summarize the main difference between using Groups and Teams is in how they focus on communication. Groups put more emphasis on traditional communications via email and social media style posting, both of which are not considered to be immediate or real-time. Teams emphasizes communications using Skype with individual and persistent chats and audio/video conferencing that are more immediate and demand members to be more responsive.
Group or Team?
So, when should you use a Group and when should you use a Team? Unfortunately the answer is, "it depends."
There are two factors I would recommend taking into consideration when choosing between a Team and a Group:
Audience
Timeline
Based on how communications are emphasized both with Groups and Teams, there is a generalization we can make based on the size of the audience (or membership) of the Group or Team.
With the more immediate nature of communications and the demand for responsiveness from members, Teams tend to be more effective for smaller, common focused workers. With less focus on email and more focus on chat, Teams work great for smaller groups of employees that have a common task in front of them that is faster-paced and always in motion. For example, this could be a project team that is tasked with implementing a new ERP solution. The Team for this project may include workers across multiple departments, such as developers in IT, accountants in Finance, and even warehouse managers in Operations.
With persistent chat being at the center of a Team, this helps the team be in constant communication as if they were in an ongoing conversation that may span several topics all related to the Team's common goal.
Groups on the other hand tend to be more effective for larger collectives of employees that may share a common interest but do not demand immediate responsiveness among all members. I tend to think of Groups as being more social network based where members can chime in when they want to share ideas or need help from non-specific members of the group. The shared email mailbox provides a "traditional" way of organizing conversations in individual threads while preserving that history to enable new members to easily catch up on current activities within the Group.
This leads into the timeline when determining to use a Group or a Team.
Going back to the ERP project team example, Teams tend to work better for shorter duration initiatives. Shared content created by the Team during the evaluation and implementation of a new ERP solution may be stored in the Team, but typically this content is relevant only to the short-term initiative of deploying the solution.
Groups work better for long-term initiatives. For example, the business users or even outside vendors that may use the newly implemented ERP solution may be part of a dedicated Group. This Group would contain the user guides and company practices content that lives on past the initial implementation of that ERP solution. Members of the Group still can collaborate by recommending changes in procedures or planning training events on new capabilities within the shared calendar and Yammer postings within the Group.
In Conclusion...
So, when do you use a Group and when do you use a Team? There still is no definitive answer. Considering the audience (membership) and the timeline of the purpose for collaboration should be a good starting point, but chances are there will be many other factors you will need to take into consideration.
With so many similarities between the two, you will really need to dig deep into the minor differences and even still, that may not point you in one direction or the other. How employees in your company collaborate will be another factor...
With all hesitation to agreeing to what I've heard Microsoft tell its customers "use it first, understand it later", actually getting your hands on experience using both may be the best way to determine what will work best for your organization... just proceed with caution.
Comments