Yesterday I woke up and checked my email. It was clear that the email lull of the holidays was over. I was taken by a post on one of my core community lists, KM4Dev, from one of my colleagues. You can see the full thread here (or if that page won’t load I save them here KM4DevSharepointDiscussions):
Dear colleagues
A few weeks ago, I posted a query on IT-tools for virtual projects and got very useful recommendations. One colleague pointed out to me that, for an organization like SDC (big, Government), one of the main elements to consider would be the IT department. This proved to be very true. Our ministry’s IT department over the past few years developed one major collaboration application (consultation tool to develop consolidated Swiss statements for UN), based on MS Sharepoint. This application has a fantastic track record: it is used, it is appreciated by ist users, it produces good results and it saves time. Our IT department therefore concludes that MS Sharepoint is the basis on which to build SDC’s collaboration platform.
We are not quite sure they are right, but for the time being they definitely got more and better arguments than we do. This is why I would like to tap into the km4dev collective experience again: what do we as a group know about MS Sharepoint as basis for building a community collaboration platform?
Some of the questions turning in my mind are:
* What was MS Sharepoint initially conceived to be? What is its development history? What are the core functions it is really good at?
* I got somewhat alarmed when seeing that MS Sharepoint is not mentioned at all in “Digital Habitat” (book by Etienne Wenger et al on Technology Stewardship for communities). Nancy, why don’t you mention it?
* What are “make it or break it” features we should ask for, which would guarantee that a useful community collaboration platform can be built on MS Sharepoint?
Wishing you all a great start into the new year. Thanks for helping us along
Adrian
Adrian Gnägi
Knowledge and Learning Processes
Being on the US West Coast, my other KM4Dev colleagues had already provided some great responses (again, see the thread!) But since Adrian had asked me specifically about why SharePoint was not in our book, Digital Habitats, I wanted to answer. My friend Jon Lebkowsky suggested that I blog my response. Considering the number of page views on my last SharePoint post I figured that might be a good idea. SharePoint and other collaborative platforms are also not new topics for the community as you can see from this summary on the community wiki: http://wiki.km4dev.org/wiki/index.php/SharePoint. The topic stays alive, so I chimed in:
Adrian, by the time I woke up, my peers pretty much summed up what I would have said. I found all the messages really resonated with my experience and research.
We did not include it in the Digital Habitats book because in the community we have seen more failures in the use of SharePoint than successes and our goal was to tell stories of usefulness, not frustration. 😉
Others have already well articulated the core strengths and weaknesses of SP. From my personal experience with older versions of SharePoint (I have VERY little with 2007) is that it is built p from the metaphor of one’s hard drive. My folders. Your folders. Each community “ready to go with a click” but siloed in the very design of the software. Have you ever noticed that out of the box you can’t easily cross link once you are deep into a community space? You have to go back “up” to the top of the system, find the other space, and drill down. In essence, there is no fundamental network structure to the platform. In today’s world, that represents a significant problem for me. It actually creates more division, rather than facilitates connections.
There is also a distinction for all products that is important to consider. The differences between the tools a platform offers, how it does or does not integrate them with and without, and the features that make them usable all matter. (Quick definition: platform is the integration of a number of tools. Integration can be incredibly important and is probably the biggest “sales pitch” for any platform. Tool is a piece of code designed to do a particular thing. A feature is something that makes a tool usable. ) For example, a wiki is a tool. The wysiwyg feature, makes it easier for non-geeks to use. If a group makes a lot of tables in their wiki, they probably don’t want a wiki that requires wiki syntax to make the tables. These are examples of features.
Many platforms (not just SP) started bending their base structure (often built off of discussion threads) to “act like” newer tools such as IMs, wikis, blogs, etc. These re-purposed bits of code often lack the features we come to know (and depend upon) so they don’t feel right nor are they as useful. This is where examination of technology at all three levels: platform, tool and feature — can really matter.
As Matt says, who knows what 2010 version will bring. If it doesn’t bring a network sensibility, then MSFT will lose the game of both collaboration and cooperation because we are in a networked world and we need both. Simply having spaces for teams to collaborate won’t work for most of us, particularly in international development.
The key is always to start thinking about what ACTIVITIES you want to support in your collaboration platform, then assess the tools in the context of those uses and the environment of the user. The comments so far have really done a good job exploring some of those aspects:
- What are people already using (start where they are)?
- What are the connectivity issues (SP has a problem with this internationally, even when people have built “low bandwidth friendly add-ons)?
- What tasks do people have to do individually and together (yes, consider the range from individual, to defined group, to network, which includes internal and external folks many times! So often we only look from the organization’s perspective if what it mandates)
- Where is the locus of control of the software? we find that communities that have control of their environment tend to “bend” it to their needs more easily, more intelligently, than if they have to keep asking IT, who may or may not understand the context of their community. This is at the heart of the idea of “community technology stewardship” — in, from and for the community)
- How can the tool allow a community to face in the directions it wants to face – in other words, if it is totally inward facing (private in all ways), a mix of inward and outward, or very outward facing (meaning it wants to connect outside itself with other individuals, communities and networks)
- What is the simplest possible thing you can use now that will support your purpose and how can it grow, vs having every possible thing now and none of it is used (this is probably one of the biggest traps we all fall into)
- How can the tool connect with, integrate, grow , evolve with outside tools and services (no community is an island!)?
If SP can support the activities you want, in your context, fabulous. If not, try and open a dialog that shows why not. Use the Spidergram (http://fullcirc.com/wp/2009/03/31/digital-habitats-community-orientation-spidergram-activity/) as a talking tool, and then, if their arguments are verbally convincing, try USING different tools. The FEATURES of the tools, what makes them useful (not just thef fact that there is a wiki or an IM tool in Sharepoint), is the difference that makes a difference. SP locks everything down to its specs. It is one way, or no way. If that works, fine. It has rarely worked for me.
You may also want to see this wiki http://cpsquare.org/wiki/Technology_for_Communities_project
And this chapter from the book, the Technology Steward’s Action NotebookNancy
Photo Credit: ‘Dereliction Splendor‘
http://www.flickr.com/photos/71038389@N00/2218657600
http://www.flickr.com/photos/vermininc/ / CC BY-NC-SA 2.0