Office 365 collaboration
Simon has worked with many businesses to nd out how best to implement O ce 365 for collaboration – and shares his advice here
How best to implement Office 365 for collaboration .................................................
T he prevailing view is that O ce 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 eective – 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 documentbased 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 dierent 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 stu? How does this fit in with their content and collaboration strategy? Recent upgrades to O ce 365 Groups and Microsoft Teams finally made me sit down and formalise my thinking on the subject.
Let’s start with the document-based 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 oered, 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 oer 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 O ce 365, they oer 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, miniblogging, announcements and crosscompany 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.
So, there’s a lot to go at with just this part of Oce 365. Tools such as SharePoint Search and Delve can look across all Oce 365 content, ensuring that finding things is straightforward (provided you added metadata where possible). We call this “Findability” – and it’s pretty good given the context.
But there remains an unspoken challenge: users just don’t know where to put things. We call this “Putability”, or knowing where to store your content.
Chris Sparrow at Tata Steel has been battling this issue, and between us we’ve developed a generic Oce 365 Putability Decision Tree (below). As you can see, it’s complex; this reflects the nature of the content we expect people to deal with daily. It is, however, simple to explain:
1. Keep your own stu in OneDrive. If appropriate, put it in a “Shared with Team” subfolder to make it available to your colleagues.
2. Put Team and Project content in the relevant site on your intranet; this could be a Microsoft Team or Oce 365 Group if you don’t need sophisticated processes, metadata and control.
3. Put stu you don’t expect people to collaborate on in your intranet, in a publishing area (such as the Comms Department News site or a Document Centre).
4. If you need to share externally then consider a dedicated extranet built on SharePoint. You could use OneDrive for Business for non-sensitive content with minimal tagging or control needs.
5. If it isn’t a document, or you just want to talk about a document, use Yammer (email, if you must). Use Skype for Business if you need to talk in real-time.
Most of all, don’t panic. While this looks complex for users to remember, I hold the to the view that there are really only five places users need to remember because there are only five types of content: My stu, My Team’s stu, Project stu, Corporate stu (things that belong to the company as a whole and are probably someone else’s problem) and Miscellaneous stu. The last one is probably one of the first four for someone else; you just need to find the right person. So don’t forget that O365 also has user profiles and great Findability tools too…
The Office 365 Putability Decision Tree offers direction over where content should go
Use Groups and Teams for lightweight intranets and team collaboration