When it comes to organizing a SharePoint Online environment, one of the choices that you need to make is what among your content will go where. In certain cases this is a relatively straightforward decision, but in others it can substantially affect the visibility and the flexibility of the content. Nowhere is this more true than in Teams, where content is frequently and dynamically interacted with by team members, all of whom have an investment in the progress of one or more projects that involve this content.
Many are familiar with Teams primarily for its conversation features:
- a real-time chat between team members that allows them to dictate responsibilities and keep in touch about the updates and nuances of any ongoing project.
- Video and phone conferencing backed by more person-to-person collaboration features
On top of this, however, Teams is a prime storage solution, and the content that is shared and stored there will be affected by the dynamics of that specific solution.
As we’ve discussed before, Teams lends itself to fast-moving, to-the-minute collaboration, and–as a result of multiple end users constantly sharing new files and suggesting edits, content can often get buried. As such, it’s important to select only the content that is most relevant to the Teams environment, because content that isn’t frequently interacted with is more likely to disappear in the shuffle of collaboration.
Accordingly, the content that is best suited to the solution is the most relevant and collaborative content for a given team or project, content which users will regularly be editing and speaking on with one another. Content that doesn’t bear that relevancy is liable to either clog the flow of collaboration or simply get buried. This doesn’t mean that other content isn’t relevant to a given project or group of users, but rather that there are better places to store it.
While the Teams environment might be the best place for the content on which people will be most intensively collaborating, additional content related to the project (such as contacts, resources, or schedules) might be better suited to a SharePoint Group site. Using the schedule as an example, were that to be posted in Teams, it’s possible that the very important information within the schedule or calendar wouldn’t actually be seen by team members who should be seeing it. Rather, in the deluge of comments and edits, and basic conversation, that schedule would be swept away.
At the same time, the content that is naturally suited to the Teams environment might not fare as well in a standalone SharePoint site. If an end user posts a document for which they need immediate edits to that site, it’s likely that their colleagues won’t get to it as promptly as they could, or that they’ll be unaware of the changes and comments that have been made. As such, the content that demands the most collaborative attention will ultimately become less valuable to the team, stashed with the folders or files at which they look less frequently.
This is all pretty understandable when laid out, but these important decisions still demand that end users recognize what exactly constitutes highly collaborative content. The examples provided in the previous paragraphs make the distinction between collaborative and non-collaborative content pretty clear, but it won’t always be that way. In certain cases, a team leader will have, say, a calendar–but they need their colleagues to enter when they’re free into that calendar in order to set up meetings, or something of the sort. Where should something like this go?
Well, it depends. Is the calendar covering the entire year or simply a short immediate interval referring to the ongoing project? How do you think people will be interacting with the calendar? How frequently? If the calendar covers the entire year, it’s more beneficial to put it in the SharePoint site, where it’ll have a more permanent central location. If it’s for an immediate project, placing it in Teams will likely be more useful, as this will allow users to discuss availability and plan in concert for the upcoming due dates and appointments.
This may seem like an example obviously designed to frustrate, but it gets at the heart of why it’s so important to understand what collaborative content is. While you can rely on a basic definition–content on which people are collaborating or content that is going to be edited as time goes by–the key to discerning what constitutes collaborative content is understanding the nature of your team, and your users’ behaviors. It requires asking not simply what the piece of content is, but how you expect users to interact with it.
Like with any storage strategy, making decisions about what belongs in Microsoft Teams boils down to considering how your organization works, and how your team specifically is functioning at any given moment. Luckily, there are ways to discern this without relying on guesswork.
Prior to migration, analytics provides a powerful window into what content is best suited for what type of site. With analytics, your IT team will be able to identify content (often folders, specifically) and get a sense of their characteristics. For instance, if a folder has numerous collaborators attached, that’s likely a piece of content that belongs in teams. If the content was created a while ago, that is more likely to belong in a SharePoint site, as it might be important but not urgent or current. Finally, folders that seem especially large might contain content suited to both, allowing your IT team to migrate aspects of that folder into the separate locations.
Teams uniquely provides a hub for you and your colleagues to collaborate in real-time, and its flexibility makes it uniquely suited to ongoing, large-scale collaboration. The other side of that coin is that, due to this design, the content that you put in Teams should go there because it is suited to the collaboration process of the team in question.
With SharePoint Online, the possibilities for collaboration and content management are endless, and Teams is a sterling example of this. Mastering Teams can seem daunting at first–especially as one of many different solutions within a SharePoint environment–but once users understand both the strengths and limitations of the tool, it will provide every single user working within it a dynamic and efficient means by which to work on complex projects, that would otherwise be stymied by lethargic communication via less appropriate channels.
The content suited to Teams–that powerful collaborative content–will thrive there, and you along with it.