Step 2 – Define a structure

Four steps to Teams success

In the last article, you learned that it makes sense to divide your companies teams into categories.
Before we continue at this point, I would like to return to the example from the household. Here we had noticed that households all over the world have benefited a long time from the fact that here, too, all objects are divided into categories (rooms) (“knives belong in the kitchen”), and these rooms again into subcategories (shelfs) (“forks belong into the cutlery drawer”).
The main advantage in this categorization is that we no longer have to search for things, but only remember very roughly in which room/shelf which item is located.
But there is a second advantage that is not immediately obvious:

Every category has its own structure

Thus, we put toothbrushes into the bathroom not so that everyone knows where to look for his toothbrush, but also because the optimal usage of toothbrushes requires a certain room structure.
Thus, brushing teeth is easiest in the bathroom simply because there is running water and towels, etc. No one would think of brushing their teeth in bed, for example.

The situation is similar with Microsoft Teams.
Also here each category should have its own structure in which the contained teams can be used optimally.
For example, let’s take a closer look at the two categories “Departments” and “Customer projects”:

DepartmentsCustomer projects
Duration of the collaborationMany years/decadesWeeks – Months
Frequency of structure changesNot oftenEvery week or month
Structure can be changed byA few peopleAll sales people
External access of guests allowedNoYes, customers
Default channelsAbsence/Holiday planning..Commissioning, Status report…
Teil des IntranetsYesNo

So you find that the teams of certain categories have similarities that should definitely be taken into account.
Define these similarities!
You could consider the following criteria:

  • Teams-Templates per category (Apps, Channels…)
  • Sensivity labels per category (Guest access, external access…)
  • SharePoint-Templates per category (for DMS)
  • Public areas for each team: Yes/No
  • Lifecycle per category
  • Self-Service vs Team-Approval per category

This list is not complete, however, you should not be too strict either. It may be fine in the first iteration of the four steps to think only roughly about the structure of each category. The finer points can also be adjusted later. Nothing is carved into stone.

So we can expand our picture from the last article a bit:

Summary of steps 1 and 2

  • By categorizing teams you set a rough structure (Like the rooms of an apartment).
  • All teams per category share a common structure. Here you focus on the finer details (Like the individual compartments per room).
  • What exactly you mean by “structure” is up to you. However, the above list can be a good start.
  • In certain categories, new teams are added frequently (e.g. Customer Projects/Events) and these should be able to be created/disbanded by a specific group of employees (e.g. Sales only). Other categories are much more rigid (e.g. Departments).
  • Also the lifecycle per category is different (departments exist over years/decades, customer projects only over weeks/months)

Especially the last two points we would like to pay a little more attention to. Therefore, in step 3 we continue with the permissions per category.