New Microsoft 365 Groups governance content

Microsoft recently refreshed its Microsoft 365 Groups governance content on – something that was very timely as the amount of confusion that still exists around Groups.

I was engaged to review a bunch of the content and make suggestions/recommendations on where it might need to be corrected or updated, but additionally I authored a couple of docs that are now available.

End of lifecycle options for Microsoft 365 Groups

The first one is around a topic that is not fully understood by many, especially end users: your options when it’s time for the Group to be put to rest.

There are a number of services associated with Groups – not just a Team with its channels or SharePoint site with its document library. I often hear horror stories from users and IT pros who deleted a Team or Group and too late realised that there was something in the Planner that they wanted to refer to, a results in a Form that needed to be shared. Depending when the Group was deleted, options at this point are limited.

Writing this doc was quite cathartic, as it allowed me to really explain a topic as well as research some of the areas I wasn’t as familiar with (such as Project). Initially it was supposed to be 1,500 words but ended up being about 3,000 because there was just so much to cover.

You can view it online here.

The interaction between Microsoft 365 workloads and Groups

Building on the previous section, how various Microsoft 365 workloads interact with Microsoft 365 Groups is mind-boggling. This too was a cathartic process as it allowed me to explain an even more misunderstood topic.

Matt Wade has a fantastic guide to Groups that I refer to (with attribution) on a regular basis, however there’s still some gaps and products that aren’t referred to.

Similarly to the previous doc, this too was supposed to be 1,500 words but ended up being 4,000 words!

You can view it online here.

Authors note: a product feature changed a week after this was accepted and put into the publishing machine, so needs to be updated.

Microsoft Teams without… teams!?

Virtually every organisation I talk to wants to deploy Microsoft Teams. When I ask why, often they aren’t able to come up with a good reason other than Microsoft said so.

Many organisations are still trying to find their feet when it comes to the governance and lifecycle of Microsoft Teams, and truth be told I’m yet to meet one that has a good solution (not that good solutions aren’t out there). I generally see either one of two extremes: IT has locked down who can create a Team and all requests come through them, or on the other hand anyone can create a Team and they have a considerable amount of sprawl. I recently worked with an organisation whose users numbered in the thousands, where there was virtually one Team per person.

Sometimes organisations are simply wanting to transition away from Skype for Business on their own terms, before one day Microsoft starts shutting down services. Others want to move to Microsoft Teams for the better chat, meeting and calling experiences.

The challenge is that many organisations, IT departments, managers, and users are not ready for the teamwork aspect of Microsoft Teams. What I also see is where Microsoft Teams is used for channel conversations and files, but the organisation still has file shares as their primary storage system. Or where they use Microsoft Teams to collaborate without using the voice and meeting capabilities, and so and and so forth. Or where Microsoft Teams was thrust upon the users with virtually no training. Trust me, I’ve seen a lot of bad scenarios and continue to on an almost daily basis.

The other end of the spectrum is the organisation that wants to move to Microsoft Teams and wants to do it thoroughly. They want to migrate files to SharePoint and OneDrive. They want to use Microsoft Teams for voice and video-based meetings. They want Microsoft Teams to replace their phone system. They see Microsoft Teams as a way to improve how they collaborate on a daily basis both internally and externally.

And while I’m a big fan of doing it once, doing it right – the problem with the latter approach is that it takes time, and potentially a lot of money and resources. But more so the time. While the organisation tries to do things right they hold back from giving staff access to Microsoft Teams.

A while back I started floating the concept of deploying Microsoft Teams without the teamwork aspect; effectively separating the client application from the service behind it. What do I mean by this?

Well, the reality is that Microsoft Teams without the teamwork functionality is in short; a better version of Skype for Business. The chat is better, the mobile experience is better, the voice and video experience is better, the meetings are better.

So how can we give people this functionality without giving them access to the core Microsoft Teams functionality? Simple: don’t add users to any Teams.

Here’s what a normal user of Microsoft Teams will see when they are the member of a Team:

And here’s what the same user will see when they are not a member:

By not making the user a member of a Team, and by restricting who can create Teams – you have effectively restricted the Microsoft Teams application to be the reincarnated version of Skype for Business.

What this allows you to do is to give people access to the application, improve how they communicate, how they have meetings, etc.

Then when you’re ready you can start adding people to a Team where they will at least be already partially familiar with the user interface.

Sure, this doesn’t drive the metrics that some people would want (or actually shows more “adoption” of Teams than exists in reality), but it’s a good way to dip the toe in the water and start the journey.

It also addresses the whole “we need to upgrade from Skype for Business” challenge by allowing organisations to do it sooner rather than later, and without all the challenges around migration, governance, lifecycle, sprawl, etc.