SOLVED

SharePoint Online vs. Microsoft Teams; Planner vs. Project; Sway vs. PowerPoint

Copper Contributor

It seems with the coming of such apps that Microsoft may have muddied the waters for the enterprise users and has left the IT teams to figure out how to provide guidance and or governance with regards to their usage considering the investment into such products as SharePoint Online, CRM Online, and Project Server Online.

 

We have a E3 license and all of our users are now on O365, but with the coming of such Apps, we're left to figure out if we need to maintain a SharePoint Online or Project Online prescense on O365?  There's no clear comparisons that we can draw from to know who is the intended audience for such apps, or what are the clear differences between them; e.g. Teams and SharePoint Team Site? 

For the most part our IT team has been left to its own devises to figure out what are the differences and more strangely to know what our corporate strategy should be.  Should we let users use Teams, and Planner and opt out of SharePoint and Project/Project Server, or not?

 

Are their any guidance out their by Microsoft that we can refer to that provides us guidance on each of these apps, their intended purpose and audience, the pros and cons in comparison to SharePoint Online, Project or Project Server?  IT teams have been left on their own to figure all this out with very limited resources and or time to provide any meaningful guidance and or governance.

 

Our current understanding of these particular apps are the following, Planner is a light version of Project, Sway seems to be a light version of PowerPoint, but we are thrown in a loop with Teams? It doesn't seem to have cross-site search capabilities (it creates silos), the cross-collaboration is limited to those invited, beyond that we have no idea what the pros and cons are for its use and or how to acurately compare it to SharePoint Team Sites.

 

Any assitance anyone can provide would be very much appreciated.

15 Replies

Don't forget about Flow, PowerApps, Yammer, Delve, I agree that creating a corporate strategy has become extemely difficult, especially around Sharepoint, Groups, Teams, and Onedrive.  You seem to be covering a lot of ground with your inquiries though.  I would suggest you spend time in the new tools you are unfamiliar with.  Watch some of the Tech Summit sessions or attend SharePoint Fest in your area.  Have a small "test" group of users start using a 365 Group, and share some information with someone using Sway.  If you currently use Project, it will only take you 30 seconds to realize Planner will not suffice.  

 

Creating a strategy for Sharepoint Intranet and document collaboration though is another story.  Wish I could help.  Our strategy is to continue to put our Intranet project on hold as we try to sort things out, and wait for fixes to some significant issues.  

Eric,

At this point I'm just looking for any guidance on SharePoint Online vs. Teams.

We've made the analysis that Planner and Sway are light versions of Project and PowerPoing and we have instituted a strategy on their use.

 

But I'm glad we're not the only ones frustrated by the lack of communication, diretion,strategy and guidance from Microsoft.  Its put our teams into a tail spin as to how to implement and manage these environments without becoming the police and hammpering innovated ideas etc. 

 

Thanks for your suggestion, we've begun some of that, but it requires a lot of time, which we don't always have.

 

Thanks again,

Aria

best response confirmed by Aria Mansuri (Copper Contributor)
Solution

Does something like this help?

 

Microsoft Teams

What is it? 

A chat-first platform for Team Collaboration. Conversations with your team members take place in the Team environment, rather than email. Files associated with your conversations and projects are stored in an associated SharePoint Online site (an Office 365 Group Site) but you may never be exposed to the SharePoint UI.

 

SharePoint Online

What is it?

Microsoft's document management / collaboration platform, which also serves a number of other collaboration use cases. SharePont is extensible and can incude the management of data in lists, workflow approvals, and document publishing use cases.  Team members typically use SharePoint as a place to store and collaborate on files, but the discussions around those assets are typically done via email, Yammer, Skype, or other communications modes (not natively inside SharePoint itself).

Kevin,

Thank you so very much for that description.  Now I have to figure out the IT/Corporate strategy in using Teams in conjunction with our SharePoint Online Team Sites. Its apparent that there are other Microsoft competing products with Teams, e.g. Yammer, Skype and we have fully vested in Skype, but it lacks any of the capabilities of Teams or Yammer and Yammer does not seem to be so tightly integrated with SharePoint Online and still lacks some features.

 

More importantly to me, is how to manage and provide a decent strategy about and around SharePoint Team sites and Microsoft Teams.

 

We are a small company of about 80 employees, so I would love to hear how other companies of smiliar size has successfully implemented this configuration and what strategies/governance were put in place and how these are being managed.

 

Thanks again,

Aria  

This has always been a problem with Microsoft products.There seems to be a disconnection between development and marketing teams, they don't know how to name products properlyt or where they are going. I always get lost trying to explain OneDrive vs OneDrive for Business vs OneDrive (cloud version) to end users. For them OneDrive is just one thing. And I don't blame them. Another source of confusion is with OneNote versions - both desktop and Office versions looks the same, but they are not. Same with Delve, Groups, MySites, Teams, Planner, Flow, Power whatever... Microsoft Alphabet soup seems to be getting worse.

Yeah to make it even more confusing - Teams are actually Groups, which are actually SharePoint sites (albeit with some features missing) :)

 

People are visual - we're getting in the habit of building infographics to help folks pick what they're looking for. Even short videos which give a brief overview are likley helpful instead of just throwing words at them.

Understanding whats what and what these apps are capable of is challenging, and Microsoft definitely needs to improve it's marketing strategy and collaborate more with their development teams.  However, to back up Aria here, even with good knowledge of these products, the challenge for businesses like ours is the strategy around how to implement these.  The typical answer is to "let the users pick what they need," but even if we trained the users on how the apps work, we have no strategy around what they should pick.  

 

For example, our organization has some people trying teams, but now they're doing some work in the teams, saving files in a group named similarly but not created for the same purpse, attaching some files to yammer, then wondering why they aren't saving the documents on their department team site for centralized storage.  We are in a position to completely revamp our intranet, and yet we haven't been able to move forward without understanding how we're going to tie all these pieces together, and how to decide where to put what.  

 

@Jared Matfess would you be willing to share some of your infographics, or provide some of your sources for informative training videos?

 

 

In one casual sentence, if I'm understanding you correctly, you've made more sense than hours of wading through documentation.

Essentially, they (Groups/Teams) are just user interfaces to the same back-end (Share-Point)... is that correct?

If so, THANK YOU for the Eureka moment. If not, please do correct me so I can update my notes - a full-wall whiteboard - my own personal "infographic"!

No, that's not correct.

 

Think of Groups as the foundational membership constuct.

 

Then you layer on UI / end user features for collaboration, using the Group as the membership base for the product (so you don't manage permissions in each workload).

 

SharePoint - sits on top of Groups

Planner - sits on top of Groups

Teams - sits on top of Groups

et. al.

Boy I liked how this thread was progressing until I got to this last post.    I was right there with Jessica.

 

But maybe I'm misunderstanding Kevin's post.

 

Kevin, do you not like the statement "Teams are really Groups, which are actually SharePoint sites"?

 

When you say "foundational membership construct", you're not trying to describe the situation in any sort of OSI model way? 

 

Simplistically, I think you're saying you have to be authenticated by Groups to access SharePoint.  But after that happens, isn't SharePoint basically the lowest layer of software.  SharePoint is some sort of big database + UI while Teams is a stripped down version of SharePoint with a different UI?

 

I'd throw in more questions but I ran out of question marks!

No, that's not what I was saying.

 

Again, the Groups service that is a membership layer is at the bottom. That membership construct provides the foundation for a number of services in Office 365 that subsequently leverage the Groups service.

 

SharePoint Online sites based on Office 365 Groups (which I refer to as "Group Sites" to differentiate from traditional "team sites") are a workload in Office 365.

 

Teams is a completely separate workload from SharePoint, but one that leverages the same O365 Groups service for membership of the Team.  The "hooks" that Teams has with SharePoint are basically elegant side-loading of documents from Teams conversations and dropping them into a SP document library.

 

Teams aren't Groups. Groups aren't SharePoint. That is 100% accurate.

Just wanted to update on this post since its inception.

We are now in the midst of creating Communication Sites as our Hub Sites and using MS Teams for all our various teams as a means to manage their projects and tasks etc.  However, there are two detractors, again from a management perspective.

  1. Each MS Teams creates its own Team Site Collection and if there were other team sites or sub-sites for a particular unit in our organization, we would need to then consider migrating content from the source library to the MS Teams library so it can be accessed and managed accordingly.
  2. There are no security permissions for any Channels created, and last I checked (December, 2018) it was on the board to be worked on, but no news since then as to where Microsoft is in releasing this capability.
  3. Inability to make the MS Teams site collection a sub-site to the Communication site/Hub site that exists.
  4. Inability to make a SharePoint Team Site map to a MS Teams. So if you already had a Team Site, new template, and wished to simply use that site as your MS Teams, you cannot.

There's a lot of capabilities still missing that in my humble opinion is very much needed.

In the meantime, we have a wild wild west, where every team is creating a site collection for every project with no ability to tie anything together. From an end-user perspective, its all good.  MS Teams provides a way to seamlessly see all the MS Teams you belong to and you can hop from one to another with relative ease.  From a management perspective, its a nightmare.

Don't get me started on the document management from Teams either as we are back to the days of file server, where we're creating folders for everything.

 

Just thought to at least give an update to where we are today.  We've chosen, due to the easy adoption by our users, to abandon collaboration within SharePoint Online and choose MS Teams, however, this has completely destroyed any taxonomy we had as well as the ability to manage the Teams permissions.  We know we can control the folders permissions from within SharePoint site/document library and it MS Teams will adhere to those permissions, e.g. if you don't have access to a particular folder, you wont know its there.  But it has created an additional administrative burden and one that has larger consequences if mistakes are made.

Aria, I can sympathize with your situation.  We are slowly rolling out Teams now and already seeing many of the same issues.  I am starting to worry about all the folders being created, and not being able use metadata in Teams.    We are also just now starting to brainstorm how we are going to handle deleted channels and Teams.  The concept I keep hearing from Microsoft is that users should collaborate in a Group, and when done, basically move the important documents to a more official document library and apply metadata.  Then the group can be deleted.  "Filing" documents is going to be extremely challenging for us to implement.  Users don't go back in and move their data.  They'd rather just never delete it.  Plus, many of our Teams are permanent (like a department), so the folder nightmare is spreading.  

 

Just a couple of comments on your comments :)

- Yes, each team creates its own site and migration is your best option (tools like sharegate make this easier).  However, have you considered using the "add cloud storage" from the Teams files tab?  You can use this to create a link to any document library, so you could potentially point to your existing documents.  Only problem is the "open in sharepoint" link will not take them to their documents. 

-  On a related subject, I spoke to someone that recommended that we actually never store any documents in channel folders.  They said their company had a link in every channel that went back to a central document library, and all the files were appropriately structured from there.  If someone erroneously put a file in the channel, they would be told to re-upload it to the main library (or else it would be deleted).  I found this an interesting approach and have started trying it for a few groups.  I think this approach does require that Group owners are trained well and diligent governing their Team.   

-  Channel permissions is by far the most requested feature on the uservoice, but I'm not holding my breath.  It really messes up their fundamental design/concept and it could be a long while before we see anything.  

-  I would avoid subsites altogether.  Everything I've heard says not to do it.  Use Hub sites, and site navigation (mega-menus are out) to tie things together.

 

Biggest items on our wish list: 

- Being able to move/archive Channels!

- Support for renaming Groups/Sharepoint URL.  We spend so much time moving things between Groups because the original name wasn't right

- Support for renaming Channels.  Renaming a Channel doesn't change the name of the folder, and this causes confusion

- Metadata shown within Teams.  In order to mitigate the folder nightmare that is developing, we need to be able to at least see existing metadata in Teams.  Editing it would be great.  

Eric,

So our strategy around document management has been to actually link a document library, e.g. Project Library, that has all the necessary metadata, content types etc. enabled and if the team activity is around a project, then the final product (folder(s)) and all of its content will need to be moved/copied to that Project Library that has the metadata enabled etc. So that is happening, but I can't tell you how successful it is happening yet, as we're just getting off the ground ourselves.  We've put the responsibility on the Site Owners to manage the process and are working on a governance plan for all things SharePoint. God Help Us!!

 

Other than that your wish list is similar to ours.

I'm still trying to figure out how we can link a Hub site to the Teams, so essentially it is a sub-site to the Hub site. I know they keep saying to move away, but in reality I don't see how. If you don't you're essentially creating lots of site collections to link together via a Mega Menu, which presents its own set of challenges.


Keep me posted on what you're doing, I like to know how others are working through these problems and perhaps learn from each other ;)

Thanks for sharing!

I find these discussions with end users easier if I try to avoid groups altogether.  The biggest mistake Microsoft made is call "groups" a product.  Groups should have just been the new way you secure a SharePoint site or other Office 365 products.  Calling out Groups as it's own thing is what has created so much confusion in my opinion. Unfortunately end users still get exposed to Group terminology and therefore confusion reigns.   

1 best response

Accepted Solutions
best response confirmed by Aria Mansuri (Copper Contributor)
Solution

Does something like this help?

 

Microsoft Teams

What is it? 

A chat-first platform for Team Collaboration. Conversations with your team members take place in the Team environment, rather than email. Files associated with your conversations and projects are stored in an associated SharePoint Online site (an Office 365 Group Site) but you may never be exposed to the SharePoint UI.

 

SharePoint Online

What is it?

Microsoft's document management / collaboration platform, which also serves a number of other collaboration use cases. SharePont is extensible and can incude the management of data in lists, workflow approvals, and document publishing use cases.  Team members typically use SharePoint as a place to store and collaborate on files, but the discussions around those assets are typically done via email, Yammer, Skype, or other communications modes (not natively inside SharePoint itself).

View solution in original post