I’m sure that most of you will have probably heard about the success of Microsoft Teams this year. It’s reporting exponential growth in usage; climbing from 13 million active users in July 2019, to 32 million in March, then rapidly jumping up to 75 million by the end of April this year. It goes without saying that the rush to adopt Teams has been primarily driven by the need to support remote working. I think it’s fair to say that Teams has successfully risen to the challenge, almost overnight developing into an essential tool relied upon by many organisations.
Feedback from users is very positive; Teams makes it easy to have video calls, send messages and collaborate with colleagues. The only downside that you tend to hear is around finding content – it’s sometimes tough to work out which channel contains the content you are looking for. However, Microsoft is actively working to improve search within Teams, so it should become a lot easier to find content in the future.
Many in the Knowledge and Information Management community have a slightly different perspective on content within Teams. Their focus is predominantly around how to ensure that all of the information stored in Teams is well governed, managed and retained throughout its lifecycle. Microsoft provides an array of governance capabilities for Teams, which, I’ve previously outlined in both in this blog post from last year and also in this webinar:
One of the debates I’ve been hearing when speaking to Information and Records Management professionals, is around how permanent a Team should be. There are almost two distinct schools of thought materialising:
Perpetual: some see Teams almost as the perfect tool for any form of collaboration. Whether project, committee or departmental in nature, a Team provides a one-stop digital workplace for almost any scenario. Content is created, edited, shared, consumed and retained – the whole content lifecycle maintained in-situ within the Team.
Temporary: sees Teams only created to support time-limited forms of collaboration – typically projects. This principal thinking behind this is that the Team is the storage location while the content is created, but that content of value should be published to a more appropriate location for wider consumption.
I’ve been toying with both these two concepts for many months now, finding myself switching back and forth between the relative benefits of each approach. This blog might best be considered my own cathartic attempt to finally reach my own conclusion [I write more in hope than with any certainty!]
Why perpetual?
The obvious retort is ‘why not?’. Teams are simply great for rapid collaboration scenarios. You need to get a group of people together to work on a concept, why should you need to worry about the manner of the endeavour? Teams simply lets you get one with it.
Perhaps the most overlooked benefit of Teams is actually in their reliance on Microsoft 365 groups. For the first time we have a really simple security model, that (out of the box) anyone can use to create their own private workspaces. Why wait for the IT team to sort out the Active Directory groups when you can spin up your own Team and chose yourself who should be allowed to collaborate?
Why should the collaboration features provided by Teams be reserved only for projects? Why can’t permanent and semi-permanent communities, such as departments, colleges or committees be able to take advantage of the same features?
The perpetual argument is really one of consistency. If every way of working is supported through Teams, then there is less hopping about between applications, less training, and in theory a more intuitive modus operandi.
Certainly, Microsoft would likely recommend this approach – and it’s hard to argue with the benefits. However, this approach isn’t without its drawbacks.
Saturation point
Firstly, nobody wants to be a member of too many Teams. This isn’t obvious when you first use the application. You can quickly navigate across the first few Teams you are a member of, finding content, noticing useful posts and, well, collaborating with colleagues. However, a few months down the line, and I have noticed many user start to experience something I call ‘Teams saturation’ – the point in time when you realise that you are now a member of so many Teams that unless you are actually @ mentioned, you simply don’t see all of the conversations (and don’t have time to spend all day scanning for updates).
I’m not sure when the point of Teams saturation exists. I’m sure it is different for everyone. It crept up on me when I reached around 20 Teams, and almost like crossing an event horizon, I didn’t see it coming until I’d crossed the saturation point. One of the major problems I see with having everything as a Team, is quite simply that many will reach that saturation point a lot faster.
Microsoft seem to be well aware of the saturation point phenomenon, building functionality such as ‘hidden team’ (which automatically hides your less used Teams), to help try to reduce the clutter. I personally would like to see other features added to make it easier to find the content you are looking for. Wouldn’t it be great if you could have a filter in Teams to allow you only see, say those Teams that have been marked as being, say, Projects?
Siloed information
Microsoft Teams has really been designed to optimise each Team for collaboration with a (relatively) small group. While Teams can be used for sharing information with large communities, this really isn’t their forte. Not only is there no concept of ‘read-only’ Teams – anyone who is in a Team can modify that Team’s content – but there as we’ve discussed above, granting people membership of teams as a means to share content actively tends to increase the probability of Teams saturation.
As such, most Teams that I’ve seen, especially those seen in larger organisations tend to be Private, with a limited number of members. The larger the organisation, the less useful Org-wide and Public Teams become. Beyond a few hundred staff and almost all Teams tend to be Private (with the exception of social groups and other casual communities, where membership can be opt-in).
What this really means is that most Teams (especially Private Teams) tend to acta as information silos. Content is seen by members but hidden from everyone else. One of the major issues with everything becoming a Team, is that it leads to a much larger amount of your content being held in silos. Anyone in Information Management knows what this leads to – content duplication, multiple versions of the truth, reducing trust in the accuracy of content, re-invention of the wheel etc.
Let’s imagine for a second that you are running a project to repair a motorway bridge. You fix the damage and document the way that the issue has been repaired. Where is it most useful for your project files to exist? In the context of the project, or should they instead be moved together with all of the other content relating to bridge? When answering this question, put yourself in the shoes of the next contractor who comes along to fix that same bridge in a few years’ time.
Why temporary?
’ve recently seen a number of organisations decide that Teams should only be used for temporary ways of working. Broadly, these organisations have recognised the issue I’ve described with saturation and siloing and concluded that they want to keep the number of Teams they have at any given time to a minimum, and that Teams aren’t really where they want to be storing their content in the long term.
In these organisations the ‘closure’ of each Team is almost as important as its creation. When a Team is ‘closed’ all of the content of value within a given Team should to be moved to a more appropriate long-term storage location.
This perspective almost views Teams as merely providing a tool for supporting the early phases of the content lifecycle, with other technology (typically SharePoint Online) providing the basis for some of the later phases.
This approach clearly manages to help mitigate the major drawbacks seen with perpetual Teams. Not only does it help to keep ‘saturation’ at bay by minimising the number of Teams you are a member of, but it also helps to reduce the likelihood of information silos by publishing content into more accessible spaces. It can also help to sort the wheat from the chaff, the very process of identifying high-value content earlier in the lifecycle could help reduce large volumes of low-value content.
This approach can also be quite intuitive. If messaging and communications are clear, from what I’ve seen staff quickly understand that projects are run in teams, while, say departmental content can be found in SharePoint. If rolled out well, this approach to Teams really doesn’t need to feel inconsistent.
However, it is also clear to me that this temporary model for Teams is far from perfect – it introduces its own drawbacks to consider:
Context
Anyone working in Records Management knows the value of context. The perceived value of content often relies upon its relationship to the other content – often the other files it was created with. Of course, if you introduce a process that moves content away from the context of the Team, you will most often be losing the context in which the file was first created.
This was one of the reasons why in-place models of records management superseded the old ‘record center’ model.
I’d personally value the thoughts of records managers on this subject – how significant is the impact of this loss off context if a ‘closure’ process were introduced that published content of value into a more appropriate, long-term storage location?
What does closure look like?
Finally, it’s worth pointing out that Teams doesn’t have a ‘closure’ process (sure, there is a confusingly named ‘archive’ function, which effectively makes teams read-only and hides them from the navigation – but doesn’t actually export or archive content). Teams can be deleted and even automatically disposed if they aren’t being used, however there isn’t an out of the box process for reviewing Teams with a view to moving content into longer-term storage.
As such, anyone looking to architect their Teams using the temporary model, will likely need to implement a ‘closure’ process (either manual or technical) for reviewing content stored in the Team, moving it to a separate location, the disposing with the remaining Team.
Final thoughts
I can argue this one both ways – I can see that the different approaches are likely to work well for different organisations. The key is almost certainly to make sure your way of working determines the use of the technology (when the temptation is sometimes to release technology without clearly defined purpose). Why not get in touch if you need support or have any questions?
コメント