As a traditional SharePoint consultant (enveloping the developer, architect and business analyst roles) we have spent years focusing on tools, categorization of information, process , rigidity and accountability. Now though, with groups starting to become useful, our lives are changing.
I think my statement on twitter from last week sums it up pretty well:
Groups, not teamsites. OneDrive, not libs. Next-gen portals, not publishing. Office add-ins, not SP-apps. Office 365, not SharePoint.— Patrik Björklund (@pbjorklund) 12 maj 2015
After spending more time thinking about it I thought I would take some time and document the reasoning behind the statements in the tweet. This post will deal with the first statement:
Groups, not teamsites
Normally when a set of people wanted to do some common work in SharePoint the teamsite was the best/recommended way to do it.
Users like it because they have everything related to the specific entity in one place. As long as they could find the "Project X" or "Department Y" team-site they knew that this is where all information related to "Project X" or "Department Y" will be stored (and later retrieved) by everyone working with information related to these entities.
Corporations spent a lot of time and money making sure that we set up the correct "teamsite templates". To decide how we designed our solutions we worked on answering questions like:
- What document libraries does a project-site need?
- What content types should these libraries handle? What site columns should the CT's consist of?
- What taxonomy should be available to users for "tagging" documents and list items?
- Do we need to provision a set of tasks for a newly created project? Can we integrate our business management process into these sites?
- How will we make sure that we optimize our information architecture for search? Can we make information retrieval as context free as possible? What is our goal regarding findability and explorability?
This is a very top-bottom approach to managing how people work. We always have the best intentions, and the end-user, in mind when we develop solutions and strategies for our customers. We know that people like having a well executed process that helps them get their work done and helps them comply with enterprise governance (well, at least they appreciate having to spend as little time as possible on that).
One problem with this approach is that it's very much a one-size-fits-all solution. This is how you do a project. This is how you create your deliverables within a project. This is how you do X,Y,Z.
In for instance a larger consulting business with thousands of projects accumulating over the years the need for this sort of structured tooling will still be needed (and we can still build them on Office 365 or SharePoint on prem). People need to be able to use refiners, custom search pages and other enhancements to search for projects related to "customer:X", of "size:Y" that are related to "BusinesArea:Z".
But. How well does this fit into a self-organizing organization where teams form in a more ad-hoc way? An organization where we can go from idea to execution in minutes. What about projects and teams that don't fit into the previously "sanctioned way of working", at lest not until they have figured out what they are actually creating?
This is where we see "groups" enter the picture. Groups are a way to create ad-hoc workspaces for people brought together outside of the "sanctioned way of working". The feature was first announced on the Office blogs in September 2014.
Depending on how you look at it it's clear that groups are aimed at being the piece of the Office 365 puzzle that brings other services together. For instance there is a TechNet article about deploying Office 365 groups in Microsoft Dynamics CRM.
Office 365 Groups, available with Dynamics CRM Online, provides a new environment for collaboration with Microsoft Office 365 users who don’t use CRM. For example, use Office 365 Groups when a sales team has a major opportunity requiring input from several people who don’t have access to CRM. Office 365 Groups provides a single location to share documents, conversations, meetings, and notes. You can enable Office 365 Groups for any entity.
Add to this that Lync and Yammer are about to be integrated into groups and you can see what I mean.
Using groups as a self-organizing team
But let's look at a usecase for when groups would make sense for employees in an organization:
Imagine that Carin (software developer), Eric (marketer), Angelica (account manager) and Louie (graphic designer) are all tied up 75% in other projects. One day Carin comes over to pitch an idea that both Eric, Angelica and Louie get really passionate about. Since they all have a certain number of hours to spare on this new, exiting and possibly hugely profitable idea they decide to stop talking and get to work.
Now the kind of work that they are going to be doing does not require them to fire up a "proper project site", they can't even do that seeing as the project sites are automatically provisioned when a new project is registered in the billing software (according to a requirement from the customer). And they don't have a customer that they can tie the project to seeing as internal projects are not billed internally. All these great integrations and tools built into the project management solution is now totally pointless for this particular project.
Now when Carin first got the idea for this new product she emailed the other people and asked if they would be interested. When enough people said "Heck yes, let's do this!" she created a new group from the application she was already in, Outlook 2016, by clicking a plus-sign next to the "groups folder". 2 minutes later, she is up and running together with the team.
Now to be fair, the group's feature is pretty limited compared to a full blown teamsite. A group basically allows you to:
- Have conversations. Either by sending email to the whole group at
firstname.lastname@example.org(a new email will be stored as a new conversation in the group and replies to emails as replies to conversations). This means that you would most likely use emails as conversation starters and not the actual communication medium, but the lines are very fuzzy here on whats better. The group will (if you so choose) notify all members of new messages to the group. You can still see all these messages by navigating to the group from the outlook webapp or the onedrive webapp.
- Store files in the same way as you store files in OneDrive (the groups are browsable through the OneDrive app and the Outlook app from the waffle/app launcher as well as the Office 2016 outlook desktop app). It also let's you reference files stored in SharePoint sites, OneDrive or your computer by uploading either the actual file as an attachment or share the file via OneDrive.
- A shared calendar for the group
- A OneNote-notebook shared with the whole group.
(Oh, btw. There is a phone app coming during 2015 for groups. I bet a lot of people are going to love this).
A group is a mix of Exchange, Azure AD and SharePoint. Even though is backed by a web in a SharePoint sitecollection we don't have any way to add new lists to a group (at least not in a way that makes end-users actually being able to see the lists). We just don't have permissions as developers to customize groups the way we are used to with traditional SharePoint teamsites.
This means that for instance all that metadata we all love to have, but not enter, just is not there in groups. This is huge when it comes to structured search!
And what about tasks? There are no tasks outside of OneNote in groups. Although, this might be an opportunity if OneNote gains deeper integration with search and the graph.
How do we handle groups?
The question then remains. How do we handle search, findability, structure and processes in an enterprise setting where we might have tens of thousands of groups? The official answer in an Office 365 world is: the office graph. And for now it's flagship product: Delve.
Now the Office graph makes an assumption, it assumes that the things you are interested in is contingent on the relationships you have to other people. If I am working a lot with Erica and have an upcoming meeting with Erica it makes sense that I'm probably looking for material that me and Erica have both edited/viewed recently. The same assumption also means that I probably want to read what Erica has been up to on Yammer.
This is really awesome for day-to-day/top-of-mind work.
But what about the longer perspective, the knowledge management perspective? What if I'm not interested in Erica per-say, but I'm interested in documents related to customer X, graph databases, or agriculture and pre-studies? This is the scenario we originally built our structured and search optimized team-sites for, is it not?
We love the mindset switch towards empowering productive people and the aim of making software as unobtrusive as possible. But we need to as ourselves the question:
Where do we draw the line between ad-hoc work and work that builds the company knowledge capital? How can we feed work done in an ad-hoc fashion into our corporate knowledge capital?
If you were to ask me right now I would say:
If you don't have lots of teamsites already. Start with groups. Follow how people are using groups and what their experience in finding content from groups that they are not already a part of is.
If you have a large, working, functional and familiar deployment in place. Let people use groups, provide guidance for when to use them and make sure that they feed results back into their correct place as they are finalized. There is no automation that will collect, categorize and make sure that content is made visible for uninitiated users. Also make sure to follow the development of the group story, there might be an opportunity to further develop your usage of groups in the future.
Next time: Office 365 OneDrive, not SharePoint libraries.
Subscribe to Cognit Dev Blog
Get the latest posts delivered right to your inbox