My company is diving into Office 365 head on and currently we are trying to put together an Office 365 Governance Program.
First step, defining the applications and their uses…
While SharePoint Online is seen as the obvious choice for publishing and content management, we are getting a little mixed up when it comes to Teams as when a users uploads documents to the Teams app, it will create a backend SharePoint Online site. And, many, see Teams as a “working site” for a department.
So, in essence, some departments (if they utilize Teams) could have a department SharePoint Online site then a Teams’ SharePoint Online site. Meaning two different SharePoint Online sites, multiple repositories, etc., etc.
How are you differentiating SharePoint Online sites vs. Teams site in your company today?
And, how are you training users on which site to post to?
OGE Energy Corp.
Hi Your question indicates that you are planning a department-based “structure”. That is almost always a mistake; it leads to information being stored (read:hoarded) in silos based on the organisation structure, rather than being stored in context of it’s purpose and/or the “business process”.
The idea behind Teams is largely to break those silos and move to a more process-oriented model. However, there is nothing in “classic” SharePoint that would stop you from doing the same without Teams (which in many cases would be an overkill for requirements); consider e.g. the standard SharePoint “Project sites” which are probably one of the most widely and used and most successful SharePoint “app”.
Note that I’m not saying that “department sites” are not needed; they are, but they should be just landing pages providing information and guiding people to the processes; filling in the gap between the traditional intranet and the “business apps”. Their content will be long-life, accessible to everyone and managed closely by the department: for example policies, guidance etc.
All work-related / business-related documents should then be on sites and libraries dedicated to the “instance” of a process: for example Customer site for each customer, Case site for each Case of any kind, Project or Engagement site for each delivery, Review site for each review of each case etc.
You will find that such structure will make SharePoint shine like never before, and be easy on everyone: SharePoint builders to create templates; users to learn them as well as the admins governing the system and data: as everyone working on a matter will be literally “on the same page”. Filing, sharing, finding; permissions; metadata searching; as well as retention and archiving will all fall into place easily.
For examples and ideas, take a look at some of the add-on products for SharePoint which are based on process thinking: e.g. WorkPoint 365, or Skybow (it’s no secret my company is a big fan & partner of the former). Those have been around for years, and evolved based on the needs of thousands of user organisations – so even if you end up building your own solution (based on Teams or classic sites), there is a lot to learn from them.
Agree wholeheartedly with Pauli. Specifically to governance of Teams, my recommendation would be to have a policy of not allowing users to store any files in the SPO site collection that gets created for a Team until/unless MS provides more controls and ability to easily/transparently link Teams to normally discoverable and manageable SPO sites/site collections vs. the current “hidden” architecture.
We’re not using 365, but an earlier version of SharePoint, but we differentiate between Department sites and Team sites as follows:
– Department site – viewable by all across the company, but only a select few (Tech Writers and Manager or higher level of the associated business unit) have permission to upload or change content. No need to instruct them not to upload here because they cannot due to permissions.
– Team site – accessible only to team members (business unit); permissions vary by library and may include individuals from other teams on a need to know basis. Many libraries are “working” ones, where team members can upload/edit; some are more restricted, with tech writers’ source files (not accessible to most team members) or published documents of record (viewable but not editable).
Works for us!
Welcome to the problem of multiple choices.
Let me first say that teams is a user interface. It collects the features of Skype for Business (formerly Lync), Exchange Online, and SharePoint Online. It’s a fancy client interface built on top of the things that you already do.
That being said, there are some interesting challenges based on what is currently released, not the least of which is the template that’s used for the SharePoint site created by teams — and the fact that we don’t have the ability to connect existing sites in a meaningful way. Microsoft has said publicly that they’re aware of these issues and are going to close the gaps. You’ve got a short-term governance problem.
I’d disagree with Pauli (and Lorne by extension) but primarily because they weren’t answering your question. I’m recommending that customers get to one site for teams/departments to work with whether they do that by creating the team and repurposing the site more broadly — or more commonly in my situation today, working to discourage use of the site that teams creates automatically and encourage the use of the team site. It’s not as straight forward as we would like, but it’s workable.
More broadly, addressing Pauli’s response, Awareness that there are two types of content that departments create is important. There’s an external awareness and there’s internal working. I’ve attached a draft slide that I’m using with a client. It’s to describe the awareness piece. On the one side you have internal customers who have needs/desires and on the other side you have departments that offer services. This slide is designed to structure the conversation for wire frames for the publicly facing internal sites. If the proposed item doesn’t fit this framework we need to understand why. One gap that I’m aware of already is the missing orientation component. Some might call this wayfinding. It’s about knowing where you are — and that’s not captured in the diagram.
However, teams is about internal operations and how collaboration happens in the group. That’s something different — and in a different site anyway.
So the real short of this is … it depends on what you’re using your SharePoint sites for. If you are trying to do externally facing to the organization then you can do a “regular” SharePoint site for this and use teams for the internal collaboration.
Thor Projects LLC
Thank you all for your replies! Helped a lot and helped me and two of my project members sketch out what we are visioning- Which is a life saver to me as I’m supposed to come up with the Governance policy 🙂
Hi, only just came across this thread, this is exactly the question we have. Not fully knowing what 0365 and Teams was capable of I’ve begun building our SP sites in the traditional way. Having learned more about Teams i’m now wondering if I create them here. The only issue I have is that the sites I’ve built contain libraries with content types (for retention, permissions, workflows, etc.) and I don’t see a way of implementing content types easily if we use the libraries created by Teams. Does anyone have a solution for this? Is there an alternative to content types that we can use…..which can ‘force’ users to specify when uploading files?
You can still use content types in the libraries Teams references. However, the issue is still that the site collections Teams creates are “hidden” in that you can directly see and manage them from the rest of the SharePoint Online environment. Until/unless MS chooses to fix/change this, I still recommend putting a governance wall between Teams and SharePoint. Use Teams for everything else (discussions, unified communications if you want, the various app integrations, etc.), but use SharePoint for files and don’t allow users to upload files in Teams.
That’s obviously valid only IF you want to actually control your content of course.
I’m confused, Lorne. All Teams are Groups (though not all Groups are Teams), and the file storage location for a Group is the Documents library of the root site in a SharePoint Online site collection.
The underlying Team site is discoverable via the preview version of the SharePoint admin console in O365, and via the usual code mechanisms.
‘Channels’ in a Team translate into folders in the Documents library, auto-provisioned by Teams at Channel-create time. You can create sub-folders, but they won’t show up in the Teams UX.
I agree that it’s kludgey, and Microsoft should help us out here, but I’ve found that it’s possible to meld the two worlds together, with a bit of ‘management by convention’ sprinkled in.
Step one, as always, is to remove the ‘Document’ content type from the ‘Documents’ library and replace it with a single content type that provides some location-based defaulted attributes (since you can’t populate metadata from Teams or Groups).
Use the Documents library for pure work-in-process collaborative content management. When something emerges from that process as authoritative, publish it to a curated location somewhere else, or to a curated library in the Group SharePoint site (which is mechanically slightly easier).
MS clearly rushed Teams (and Groups) out the door because they were getting clobbered by the Internet-kiddie toy systems (Slack, etc.). They delivered great response to that threat. Let’s give them time to construct some long pants for the new capability. I’m pretty sure they’re doing that.
One thing I can’t explain is this: When you send an e-mail to a mail-enabled channel, it gets copied to the ‘e-mail’ sub-folder within the channel folder. It isn’t in the Group mailbox. That one presents some interesting lifecycle management challenges.
Should be interesting to see what Microsoft comes up with on Teams. I know that plenty of large customers are asking for more enterprise-class features. The challenge will be to maintain a balance between the collaboration ease-of-use of Teams and the IM needs.
When I wrote that reply to Tom, the ability to see the, previously hidden, SP site collection for a team in Teams in the preview Admin center wasn’t yet available. Hopefully that helps the confusion.
I forget how quickly time passes (and features advance). Thanks for the reminder. Took me a while to figure out the convolutions of Teams/Groups/SharePoint/Exchange, so I thought I’d take the opportunity to share. Hopefully it will help folks out.