“Office 365 provides a genuine set of capabilities for individuals, small businesses and major enterprises”
Simon has worked with many businesses to find out how best to implement Office 365 for collaboration – and shares his advice here
The prevailing view is that Office 365 is rather good. Even Mr Honeyball says so, and he isn’t known for leaping to Microsoft’s defence. The company has created a technology and brand that successfully ranges from individuals through small businesses (O365 Business Essentials) and up to major enterprises with 100,000+ seats. It provides a genuine set of capabilities that’s well matched to the needs of this disparate group and it continues to improve. If you’re used to Microsoft tech, then I’d always favour O365 over the Google platform.
But it isn’t perfect. In common with other tech firms, Microsoft often takes some fun internal project and launches it as a new component of O365. I’m all in favour of the “minimal viable product” approach, but not when it’s combined with a “throw it at the wall and see what sticks” strategy.
All of this is a lead-in to me talking about the complexity of the O365 content and collaboration story. In the old days, when my business partner and I launched Cloud2, the landscape was simple: you had file servers (which everyone used, but that were unfit for this purpose) or you had SharePoint (which is complex and compels thought and planning to be effective – an unnatural act for most users). And you had email…
Today, the O365 stack is what you see on the right. Of these 14 core items, the first nine are involved in content and collaboration. Several target document-based collaboration and storage, while others are more about sharing comments and ideas. Several have overlapping functions or fill the same niche (SharePoint, Teams and Groups). You’d almost think that there were three different teams developing them, neither communicating nor taking direction from a master strategy.
So what do organisations do about it? How do they decide what tool to use and where to put their stuff? How does this fit in with their content and collaboration strategy? Recent upgrades to Office 365 Groups and Microsoft Teams finally made me sit down and formalise my thinking on the subject.
Let’s start with the documentbased collaboration. At this point you need to know that SharePoint (and, by extension, Teams and Groups) stores files in libraries. Although these can appear like a traditional file share – they even allow folders (shudder) – the content is stored in a SQL table. This means they can have metadata attached: additional data fields that are largely absent in a file share. As an example, if you want to store a set of quotations, you could set up the library to capture the client name, the technology offered, the price and the discount rate as part of the document – so much more useful than trying to force it into the file name. With this in place, these tools offer clever ways to view your documents: one view could show all documents created in the past ten days, while another might display everything grouped by client name.
Groups and Teams are designed to be a broad but shallow collaboration tool. Microsoft has long worried that the sophistication of SharePoint is too much for many organisations – and it may be right. I see Groups and Teams as a dumbed-down SharePoint site, since both fail to expose all the power of metadata. For those who remember Windows SharePoint Services (WSS) or SharePoint Foundation, Groups and Teams could be considered their modern successor. They fill the same niche, but Groups is email-centric while Teams is (Skype) chat-centric.
Standalone, Groups and Teams are great for lightweight intranets and team collaboration. Combined with other parts of Office 365, they offer the ability to build out mid-range digital workspaces. Combined with the extra power of SharePoint, enterprise-class applications and workspaces become the norm, with Teams and Groups filling a role for unmanaged or lightly managed collaboration. Some organisations will choose OneDrive for Business for the former, leaving Groups and Teams for the latter. In this case, a sensible approach is to have a standard folder structure that consists of: Private Shared with Team (<owner name>) Shared with Everyone (<owner name>) Shared Externally These would be used as shown in the decision tree opposite (top right).
Then there’s Yammer. This can also store and share documents and allow a form of collaboration. Using Yammer in this way hasn’t felt natural to me, but it was part of the original design of the product, and it may well suit some organisations.
Where Yammer excels is for publishing a stream of consciousness of the organisation; you can liken it to a combination of a group discussion, mini-blogging, announcements and cross-company comms. What really makes Yammer rock is when it’s structured to mirror organisational structures and processes, especially when discrete parts of the Yammer stream are embedded within a SharePoint page in an intranet. In this case, it becomes useful for wrapping a shared conversation around a project, team site or document.