;)
In the first blog in this series, I noted that there are five stages to the lifecycle of each M365 Group: Ideation, Request, Creation, Monitoring, and Archival.
Today, I’ll expand on the first stage, Ideation. This is the point at which someone has an idea for a place to accomplish some kind of work. We need to fully understand several issues that may come up during phase, so let us review them.
- Does an M365 Group already exist for this purpose?
- How can you create a directory of M365 Groups?
- Is an M365 Group the best way to solve your problem?
- What template should the M365 Group use?
- What are your next steps?
Does an M365 Group Already Exist?
One major issue that organizations face is that when they allow M365 Groups to be created, there is an explosion of groups that are duplicates of each other. We saw this in Yammer, where it was so easy to create a new community that users would often create one before determining if one already existed.
Ensuring that users check to see if an M365 Group already exists for their proposed use is step one in controlling your M365 Group environment. The question is, how do we accomplish this?
The first step should be to train our users to always look for an existing group before they create one. Unfortunately, this is more challenging than you think. When a user has an idea for a Group, they want to get working on it right away, and any delay in our process is likely to drive them into using another tool that offers them immediate gratification.
For example, a user wants to chat and collaborate with their team on a project. This is a quintessential ad hoc collaboration example that Microsoft designed M365 Groups to address. However, if we force users to enter a request and it takes hours or days to create their workspace, they might just create a Group Chat in Teams with everyone on the project team and use the Files tab in the chat to collaborate in their various OneDrive accounts.
This is not the best practice for using Microsoft Teams. We should provide guidance for users on the proper behavior. It underscores how important it is to not place roadblocks to creating M365 Groups.
If we want our users to see if an M365 Group already exists, then we are going to have to help them as the out-of-the-box experience is lacking. Let us take as an example a user who wants to create a Microsoft Team workspace for a demo. For this example, I have created three Teams workspaces. Demo Public Team, Public Demo Team, and Demo Private Team.
For our purposes, either would be a duplicate of our example user’s new proposed Team. They go to the “Join or create a team” link and click it. They are presented with a list of public teams that they might want to join.
You can see the first problem here. Where is the Demo Public Team? It is not suggested to the user for some reason that only Microsoft truly knows. We can search for it, so our example user will type in Demo and see if they find anything.
In this case, the user sees the public team that starts with Demo, but not the private team, or the team Public Demo Team because it only looks for Teams that start with your search term. We can see that if we search for “public” we get these results.
As for private teams, that is even harder to locate. So, how do we solve this problem?
Creating a Directory of M365 Groups
We will need to create our directory of M365 Groups. This is not necessarily difficult but keeping it up to date is tedious and requires us to automate a process that runs on some schedule. We can use PowerShell to accomplish this. There is a PowerShell cmdlet called Get-AzureAdGroup that returns every AzureAD Group. It is part of the AzureAD module, and it will return the following:
This could be used to create a directory, but it does not tell us much about the M365 Group. We could use Get-SPOSite instead which gives us much more information, including Site Collections that are not M365 Groups, which might be valuable to us. We could also go to the SharePoint Admin center and export the list of Active Sites to a CSV file:
Here you will get a list of all the sites with everything that you might need.
If you want the list up to date, then you will either need to re-run the PowerShell or the export and then save the data someplace like a SharePoint list that you can use for your directory. Keeping that directory up to date either requires a job to run daily or forcing every new site to be created through a process that updates this directory as part of its process. We will talk about that in Part 3 where we discuss Requesting a new M365 Group.
Is an M365 Group the Best Way to Solve this Problem?
This is a tricky question to address technologically, but from a Governance perspective, it is one that we need to address. There are reasons that an organization might want users to work in specific ways. For example, there might be a process to create a project workspace when D365 reaches a specific point in the opportunity lifecycle. Thus, we do not want users to request or create a site for a project since it will happen as part of an ERP workflow.
This training and communications issue should be part of our Governance process even though there is not a technological solution for it. We might prevent users from seeing the project workspace template, but that will not stop them from requesting say a generic M365 Group and customizing it. We need to monitor that, as well as educate our users on how to create these groups.
Select the Right Template for the M365 Group
Like the directory that we will need to create, each M365 Group should be based on a template. These should be designed to guide users to which template they would request based on the problem they are trying to solve. For example, if a user is looking for a place to collaborate and communicate around a set of documents for a presentation, creating a Teams workspace makes sense. If they are working on a process like loan origination, then it might make more sense to create a channel in an existing Teams workspace or add a folder to a SharePoint site.
Another advantage of templates is that they can be used to customize the content, the features, the look and feel, and more of an M365 Group when it is created. Take as an example a new project workspace. We might want to include the template for the project charter, as well as a risk register, and the templates for requirements and design documents. That way we can ensure that the correct documents are used without the users having to search for them.
Putting It All Together
Our goal here is to allow our end users to easily create sites when they need them with minimal disruption or delay. To accomplish this, we need to ensure that they can quickly and easily find M365 Groups that already exist, even if they do not have access to them to prevent duplication. If we do not do this now, then during the approval or creation step someone else will need to validate that a group does not already exist, or we will have duplicate groups that will require merging.
This is the time to prevent that, but to do so we must have a searchable list of all the groups. Yes, you can still hide some groups that might be secure in nature. We call those hidden groups that do not appear in the directory.
Next Steps
The Ideation phase of M365 Group Lifecycle is focused on aligning users with the best options using M365 Groups to address their issues. We also need to ensure that they don’t duplicate existing sites. This means that we need a directory of sites that users can search prior to creating a site. The Out of the Box tools for this aren’t great, but with some PowerShell and time you can enable this searchable list for your users. This is the point that we should expose users to the potential list of group templates that exist so that they can select what works for them. This means we need to identify and create these templates that are linked to use cases that we have identified.
In the next article in this series, we will talk about the Request phase of M365 Group lifecycle.
