You’ll find plenty of advice about creating Microsoft Teams and a collaboration environment out there. None of it should be considered absolute but instead, guidelines when creating your own Teams environment. However, the most important rule should be that Teams should be a planned process, not something randomly generated. Actually taking time to think and plan your Microsoft Teams environment will make your life a whole easier.

The first major suggestion is to plan an environment that is wide, not deep as I have outlined here;

Your collaboration structure should be wide note deep

Unlike traditional file server environments, you have the benefit of powerful search functions and AI surfacing relevant material now in Microsoft 365. Having a flat structure also make it easier to re-arrange if you need to down the track and it also make permissions much easier to handle. If you need some form of hierarchical structure for navigation you can create this using hyper links but underneath the covers, keep the structure of what you build as flat as possible. This means creating lots of Teams and SharePoint sites as needed and then linking them together, using hyperlink, into whatever you need, NOT creating subsites.

Also, as I have outlined in

A framework for file migrations to Microsoft 365

Don’t dump your information into a single location, Team , SharePoint site or Library, etc. There are lots of places for collaboration inside Microsoft 365 and certain types of information works better in different places. Break your information up and put in where it makes sense. You have all these areas available to you, use them.

Along these lines, another guideline I can give is that when information requires pure storage (no conversations or chat around it) then use a SharePoint site. If however, there will need to be conversations around that information then a Team is a much better option. For example, a SharePoint site is a great place for an archive, with finalised forms and documents like manuals and marketing material. A Team works better when creating documents that when finalised, will end up in a SharePoint. Using Teams chat correctly will cut down back and forth emails as well as making all these conversations searchable for all members of the Team.

Further, I’d suggest is to limit the depth of the structure to three (3) levels per:

The rule of three

Making a structure deeper than 3 levels generally results in people hunting up and down a structure looking for the information they are after. At the lowest level you should be able to go into a Document Library and see everything, including one level of folders below. Going deeper means you lose the initial context and when you come out you need to get re-orientated again to continue. This wastes time and creates frustration for users.

Next, when you create a new level, Team, Library, folder, etc always ask yourself the question, “Will be this be by function or location”?”. For example, if you want to create a new Team, ask the question. You then decide with Team will be for Human Resources (i.e. function). Then, when you create a channel below that Team, ask the question again. This may result in channels by State (i.e. by location). When you create a folder inside that channel, ask the same question and maybe create folders like CV, jobs, application, etc (i.e. function again)

Asking this simple question at each level provides a surprising logical structure very quickly. This is in fact where I find most people get hung up when creating a new collaboration environment and having very simple guidance you can follow helps overcome this and get on building what you need.

It is also important to follow some basic guidelines when naming each item in your structure.

– Keep the names you use as short as possible i.e. HR is far better than Human Resources

– Avoid using spaces and special characters i.e. Customer-Service not Customer Service

– Avoid having duplicate items. For example calling your Team “Projects” and then each channel something like Project-1, Project-2, Project-3, etc is redundant and consumes space.

Settling on a naming convention prior to creating your collaboration structure is a very worthwhile investment of your time. For example, settling on how to name a location like a state which could be New South Wales, NSW, N.S.W., Nsw, just to name a few possible iterations. Having a consistent approach to how you name all items in your environment will greatly assist users when they are searching for information and avoids duplicated areas. This is why a small amount of timed invested up front planning your collaboration structure pays huge dividends down the track. Unfortunately, I see too many rushing in and just creating items on the fly and then having issues down the track.

Remember, that you don’t have to build the complete structure on day one. What is the minimum viable solution required? Maybe it is something for a limited group of your users. Build it, learn, test, adjust and then move forward. Typically, you are introducing major changes inside an organisation and best method to see how this is adopted is to take a slow and sure approach while seeking feedback from users. You certainly still have your overall plans but taking one step at a time is going to allow you to quickly adjust if you need to.

Don’t forget that you’ll also have to invest in user training as I have detailed previously here:

Stop making your users feel stupid

This will be especially true if you have moved from a traditional server. Collaboration is very different from storage and failing to help users come to grips with all the features Microsoft 365 provides is going to make adoption of any new system hard. Remember, you can create the greatest collaboration structure in the world, but if people fail to use it, then that investment is wasted. In the end, technology serves humans, so help your humans come to grips with the new system and you’ll be surprised at what they can achieve it with. In my experience, the single biggest point of failure when building a new collaboration system is a failure to train the people who will be using it every day. Fail to do that, and you will struggle to make things better.

As I have outlined in

Process for file migrations to Microsoft 365

Assigning permissions comes AFTER you have created the structure. Remember, by default, Microsoft 365 is an environment designed to make it easier for users to collaborate. This means, by default, users are encourage to share, edit, and so on. For example, Teams is largely designed so that all members have the same permissions inside a Team and can read, write and delete documents by default. The more restrictive permissions you wish to apply to a structure the harder it becomes to bend the technology to accommodate this. Can it be done? Of course, but the more complex and restrictive the permissions, the harder it becomes to accommodate these inside a structure. In short, Microsoft 365 is primarily designed to allow people to work together not blocking them from getting to information. Think of it as allow more than deny.

As I said initially, there are not hard and fast rules when it comes to creating a collaboration structure in Microsoft 365. It is a tool that can be structured in just about any way to suit a business. However, following the above guideline, is going to make your life much easier and will mean you are not fighting the technology to achieve what you want. Because you want to create a structured environment it is always recommended that you design this prior to actually building it. Cleaning up afterwards always takes more time and causes more frustration in my experience. Always start simple and build from there.

Hopefully, these guidelines, based on my experience, will help you get the most from your Microsoft 365 collaboration environment. In the end, build something that work for you.