“Project Channels” in a Team is a bad idea

I don’t know how many times I’ve seen people create a new team channel for a new project. I can understand that you do it because you quickly get started with creating and saving files and having dialogue via posts in the “project channel”. The idea and ambition are good, but I believe it is wrong to use Teams in this way. Below in this post, I’ll show you some of my arguments for why I think it’s wrong and finally, finish with a tip on what you should do instead.

Some of the disadvantages

Below I have listed some of the disadvantages (there are more) of having a Team where you create a new channel for each new project.

1. You create Information chaos

With only one channel for a project, you are guaranteed to get a deep comprehensive folder structure where you quickly lose track of where your files are located. Since you can’t create “subchannels” to a Team channel, you only have these folders to work with to create a reasonable structure for the project’s files. Being able to create a reasonably organized folder structure then only applies to Files, when it comes to channel posts, all posts will be in a soooo long row in “Posts” and you almost immediately lose an overview of which theme each post has to do with. You have already created information chaos in the project. Both files and posts MUST be placed (and be found) in an intuitive context.

2. You stress each other out by spamming posts

Posts will be made in the “General” channel instead of in the project’s channel. Stress and/or ignorance will cause people to post in the General channel when these posts actually belong in the project’s channel. Not only does this create unnecessary and irrelevant notices to all members of the team (even those not related to a single project channel). If you do it this way and not all team members have configured their notification settings to include only what is relevant to them (which I can guarantee not everyone has done, or knows how to do) then the annoyance is already a fact. You can certainly limit the possibility so that only team owners can post in the General channel, but you would like to be able to use the General channel for just general posts and files.

3. You create Access rights chaos

If the Project Team is not Private, all employees in your organization have read and write rights to all files that you have in the Team. Sharing culture in all its glory, but complete openness is rarely desirable, especially not when the project may contain information that is classified as Sensitive or secret to one degree or another.
You cannot set access rights on a regular channel. If you are a member (also Guest) of a team, you have read and write rights to all channels and their content as default rights.
If you have a project where you wish to involve an external user, you must first invite this person as a guest to the Team and the moment you do so, this guest has access to all channels in the Team.

Of course, you can solve this challenge by using Private or shared channels, but then the next challenge appears. You can currently have a maximum of 30 private channels in a Team. Not only that you may quickly reach the limit if you have to manage many projects. It becomes a heavy task for the team owner to first administer all the members of the Team. To be able to add a member or guest to a Private channel, this person must first be a member or guest of the team. In addition to that, the team owner must administer both owners and members of the private channels. Private channels are also limited to a maximum of 250 members. It’s usually not a problem, but it can be.

Taken as a whole, it goes without saying that all this user administration will be an unsustainable solution and that you will not be able to manage to have good control over access rights and who can do what and where.

4. Your meetings will be very transparent (like it or not)

The project meetings you conduct as Team meetings you may run as Channel meetings. This is a smart way to have meetings because both the meeting chat and any recordings are then available in the channel afterwards. Since all team members have rights to the content in all channels, this means that if you have project channels, all recordings and meeting chats will be visible and accessible to all team members. Once again, openness in all its glory but it is not certain that everyone wants their project to be open to all team members.

5. You will not be able to archive the project

If you use project channels and are done with a project, you cannot archive a channel. Sure you can hide the channel to avoid seeing it but you (and all other members of the Team) still have read and write rights to it.

The points above are pretty strong arguments against doing it this way, aren’t they?

(Image by Clker-Free-Vector-Images from Pixabay)

Redo, do right!

Create one Team per project

The fact that each project has its own team gives you completely different opportunities than just using channels. Create a Team for each project. Consider naming standards. It is a great advantage to be able to quickly identify a team using the Team’s title. Feel free to use different prefixes for different types of Teams. If it’s an Internal project team (just for your organization) you might want its title to start with “IP-” and if it’s an external project team (with external guests) you might want its title to start with EP-
Put at least two people as owners of the Project Team. If one of the owners is absent, the other must be able to do what needs to be done and you don’t have to wait for the sole owner to be back at work.

The right information in the right place.

Create channels in the project team that correspond to the main areas or sub-processes you have in the Project. that way you ensure that both files and dialog are in the right context and it becomes intuitive where to post posts and store files (and consequently where to find posts and files)

Limit the possibilities of messing things up

Avoid chaos and confusion by configuring right settings on the team so that only the team owner can create channels, tabs and add apps. You as the owner should create the folder structure you should have in each channel.


When the project is complete, you can easily archive it and thus make all the files read-only. If desired, the project team can reactivate an archived team to resume work on it.

Have you already fallen into the trap?

If you have already lost your way in this jungle of project channels, you have the opportunity to redo and do it right.

There are nice third-party tools that make it possible to move channels to other teams, so if you now choose to establish a Team per project, you can copy both posts and files from your old “project channel” to a History channel in your new project team. After that you can continue to work in your new project team but now in the right way and with your old history available.

If you want advice, help and tips with this, you can contact me via direct message either on Twitter or LinkedIn.