Daniel Anderson(@sharepointfocus) asked this "innocent" question on a peaceful Sunday:
And the question and answers trigger me to reflect on my experiences from using M365 to support projects.
So, the most important question is of course what do we mean by "project"?
Based on about 25 years of experience in the field, the term project is a continuum from the very basic to highly advanced, even within the same organization.
If we only use the Project to store a few key documents related to the project, the requirements are hugely different from if our definition contains collaboration (internal & external), task management, meetings and perhaps even some portfolio management.
The answer to Daniels question therefor is "it depends" 😊
Most likely each organization will have several templates for projects, and the architecture will often differ from template to template.
Channel types
A Team can have three types of channels
Standard channels, every member or owner of the Teams can see these (in blue below)
Private channels (light blue below), a subset of the users in the Teams can have access to these. A private channel has its own SharePoint site.
Shared channels (purple below), a subset of the users in the Teams AND External participants (not guests) can have access to these. A shared channel has its own SharePoint site.
Channel per project approach
Pro
Ease of use, every member or owner can add a new channel
Fewer Teams, if Teams sprawl is an issue in your org, then channel per project will reduce this
Ability to search across projects. As each project is a channel within the same Team, search automatically will cover each project.
Chanels can be archived soon. According to the roadmap Microsoft will start rolling out the option to archive a Teams channel in February 2024 . From a governance perspective this is essential when using the channel per project.
Con
for Shared Channels only
Shared channels require that Azure B2B Direct Connect is enabled in both tenants in order to collaborate with external users.
for Shared and Private Channels
Stream, Planner and Forms Apps are not supported.
Custom Apps, Bots, Connectors and Messaging Extensions are not supported.
for Private Channels
A Team can contain a maximum of 30 (including deleted) Private channels.
For all types of channels
You can't subdivide the channel into sub channels for project specific entities (disciplines or phases) except by using folders.
Team per project approach
Pro
Most governance features such as Conditional Access, Archiving and DLP are designed to work on the Group/Team level.
External collaboration (guests) can be enabled on a Team
You have the ability to reassign a project to a new Customer by assigning the Team/SharePoint site collection to a new Hub Site.
Each project can use Planner/Project4Web or similar tools
Con
For Search to work across projects you will have to ensure that associated projects are members of the same Hub Site.
A Team per project approach will clutter the overview in Teams and count towards the 500.000 limit on Teams per tenant.
Recommendations
While the channel per project approach in my opinion has some serious shortcomings compared to the Team per project approach, it might be just the right solution for you, if your project requirements doesn't require any of the features provided by Groups/Teams.
However, while the Team per project approach might look like overkill in some cases, we often see projects requirements changing during the execution, and the Team per project can accommodate this change while the channel per project can't.
So, the takeaway from this is to use the Team per project approach in most cases, as this allows the complexity of the project to grow without painting yourself into a corner.
Yorumlar