In my work implementing SharePoint at organizations of many different kinds and sizes, I've seen a trend that I wanted to share, with the hope of starting a conversation about how we can improve the way we all collaborate.
Here's the background:
A company will have an initiative around collaboration sites / project sites / team sites (call them what you will). Maybe there has been no centralized place to collect work-in-progress around a specific goal, or maybe there's an older system that has fallen into disuse or disorganization, and needs an update. Maybe the organization has a metric around improved innovation or findability, or wants to combat the use of outside-the-firewall resources for shared work efforts (e.g. Google, DropBox). Whatever the situation, the company makes the decision to implement SharePoint for collaboration.
This is generally where I come in. The company hires their local SharePoint experts to help get them up and running. The joint project team will invest time in designing a template or templates for the collaboration sites, possibly developing some custom functionality if the requirements call for it, and in some cases automating the request and provisioning process, so that end-users can either create new collaboration sites on their own, or can fill out a form and route the request through a standard process. Increasingly, the company will have some flavor of enterprise social computing, where the end users can vote and comment on content, subscribe to topics, post updates, and see activity streams. We test the solution, incorporate feedback, receive some form of signoff, move all the new collaborative functionality into Production, train the end-users (who, of course, have received communication about the coming change along the way), and that's a wrap for that scope of work. The IT department can tell their executives, "The deployment was a success, we now have collaboration." There is a mental checking of the box.
Here's the problem:
That nice robust technology solution isn't collaboration. Nor is even the most well-populated and highly-used collaboration site, if it's the kind I typically see. Let me demonstrate.
Take a look at the following team site. It has many of the components of the ones I work on every day - a task list, a calendar, document storage, contact information, announcements, and even a picture of the day to keep things dynamic and engaging. The entire team can contribute or remove anything at any time with no restrictions. The site is an important hub of frequently-changing information, accessed multiple times a day.
Is it the most mature team site in the world? Admittedly not - there's no remote access, no automated notifications on new content, no integration with other systems, and no ability to share the information with external contributors or collaborators. The items are not linked to each other, targeted, or personalized, there are no standard processes for archiving and storage, and there's no way to track metrics over site usage or content.
But even if all those more mature features were in place, I still wouldn't call this a collaboration site. Team members post information and other team members consume it. Sometimes they make updates to each other's information, for example if a meeting date changes or a task is completed. For the most part, this site is used exclusively for displaying and consuming information.
I call that publication.
It's easy to find definitions for Colllaboration that stop at "working together to produce or create something" or "working together to achieve a goal." They make it simple to check that mental box: "We're doing Collaboration!" But I'd like to go beyond these definitions and get at the more difficult, more valuable questions.
If you're thinking, "Our collaboration sites are perfectly good," I'll give another example that I see frequently. Let's say we're inside a product or service organization, where a team has formed around a sales pitch. One person on the team is given ownership of creating the draft pitch or proposal. Whether it takes the form of a slide deck, lengthy document, or multimedia presentation doesn't matter. He/she may start from a fresh template, but more likely starts from a good example of a pitch that he/she used before. Once the task owner completes the draft, he/she posts it to the team site for the others to review. The process is more fast-paced here than for actual project work, because the organization is competing against others and has committed to a rapid turnaround time for the pitch or proposal. The others on the team quickly review the materials, make changes each in their turn, and after a final round of review and approval, someone on the team (typically, a different team member than the one who drafted the original) goes through the materials, cleans up all the edits, and sends the document out to the customer.
Everyone worked together to produce or create something - check!
But the original creator of the materials didn't see any of the revisions that came out of the review process. Because it happened so quickly, and/or changes weren't tracked or weren't able to be tracked, and/or the individual had to move right on to the next project or pitch, they don't know which improvements the other team members made to their work. The next time they're tasked with creating a similar pitch, they will do it the same way they did before, and won't be able to bake in any learnings from the process. If the team happens to lose the sale, to what extent do any of the team members know why? It's not an easy thing to get feedback from a customer on why you may not have been successful, but even if the sales lead asks for and receives this feedback, to what extent is it incorporated into the overall effort? If, somewhere else in the company, a different sales team comes up with an innovative new way to make a pitch, how quickly does that innovation reach our example team so that they can start using it as their go-to proposal template?
I could relate many more examples beyond the Sales process, but this post is already long, and my point is: a group of people individually saving their work product to a teamsite and making revisions to it isn't enough. If we want to get better at what we do, we need to stop being complacent about our collaboration efforts. These are a few of the questions I'd like for us to start asking before we check the We've-Got-Collaboration box:
- Are we producing new insights, ideas, or approaches, and feeding them back into the system?
- Are we learning, or just repeating?
- Are we making each other better as a result of our collaboration?
- Are our ideas relating to and building on each other's, and serving as springboards to the next idea?
- Does everyone on the team feel like they can express new ideas or ways of working?
- Could we REALLY re-invent the wheel?
- How can we tell a "good" collaboration experience from a "bad" one? (successful vs. unsuccessful, efficient vs. ineffecient, etc.)
- How do we know if we're getting better at collaborating?
- Does this process / platform / team make sense for what we need to do?
Many people before me have grappled with these issues and written about them. I'm including below a by-no-means comprehensive list of resources that informed this blog and reinforce what I'm trying to express. And I hope you'll drop me a line or a comment with your own questions, thoughts, or trusted resources on the subject of getting to a better, more valuable Collaborative place.
Resources:
Dan Keldsen: More Collaboration (Isn't Enough)
Paul Culmsee's four-part Facets of Collaboration
Chuck Hollis: Beyond Document Collaboration
Peter Cripps: We Need More Women (IT) Architectural Thinkers (Duh)! - I include this one because the description of how the girls work together to brainstorm, in paragraph 2, is a how I'd like to see more enterprise collaboration work.
