Tag: SharePoint

More Reflections on SharePoint and Picking Technology

Creative Commons image 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 Notebook

Nancy

Photo Credit: ‘Dereliction Splendor‘
http://www.flickr.com/photos/71038389@N00/2218657600
http://www.flickr.com/photos/vermininc/ / CC BY-NC-SA 2.0

Tom Vander Wall Nails My Sharepoint Experience

Azul DeCobalto vs. Touchez LaSurfaceFor a number of years I have cringed every time one of my clients tells me that have or are planning to deploy Microsoft SharePoint as a collaborative platform. They say it is their “social media” deployment. SharePoint is many things, but it misses the critical element of social media which is networked connection between people and ideas, easy discoverability, makes visible and allows people to act on weak ties, and support for other network-like interactions rather than closed group performance.

I am not an IT manager, nor would I say my main competence is in portals and intranets. My focus is on what people DO with these tools, and very often I’ve seen people struggle with SharePoint.

Recently Tom Vander Wall has posted a really thoughtful blog post that says what I have experienced. SharePoint is a silo builder, not buster. (Thanks to someone in my Twitter network for Tweeting the link and I’m sorry I did not note who this was!!)

In SharePoint 2007: Gateway Drug to Enterprise Social Tools :: Personal InfoCloud, Tom quotes one of his informants:

“We went from 5 silos in our organization to hundreds in a month after deploying SharePoint”. They continue, “There is great information being shared and flowing into the system, but we don’t know it exists, nor can we easily share it, nor do much of anything with that information.” I heard this from an organization about 2 years ago in a private meeting and have been hearing near similar statements since. This is completely counter to the Enterprise 2.0 hopes and wishes they had for SharePoint. They were of the mindset that open sharing & having the organization and individuals benefit from a social platform.

Clearly, the challenges of any platform is not just the platform, but how and WHY it was used. Driving from real needs, not simply IT convenience or standards alone. But there is something critical here that is missing from a social interaction perspective. Horizontality.

Without extensive customization (and addition of external functionality), SharePoint requires you to dive into an area, then back out of it before you dive into another area. It is built on a tree-branching model. To maximize the power of networked interaction, you need a networked architecture. If you are trying to reify and support a hierarchical reporting and accountability model based on the org chart, SharePoint fits like a glove.

Our mental models and values permeate the very coding of the software we use. When people say technology is value neutral, I say people have values and people build software, therefore the software carries the imprint of the designers’ values. SharePoint is a perfect example.

If you read the excellent comments to Tom’s post, there is some great insight as to what Sharepoint is good for and some ideas about how and why it stumbles in other areas. One of Tom’s own replies stands out for me:

There is a lot of understanding of how social tools should work and need to work in enterprise (deeply based on how people interact with others and with interfaces) that must go on top of the technology platform. I have deep interest in that story and that understanding, as it is one I rarely see inside enterprise, but I see with in the makers of the social tool products.

The point I hear over and over from those trying SharePoint to accomplish enterprise 2.0 functionality (open social interaction, ease of use, ease of working in the flow, sharing collectively, aggregating in context, and eventually getting to collaboration) is not the platform on its own to do this without very deep pockets for development. Lockheed and Wachovia are the only big deployments I know that went down this path..

From a global perspective, there are some additional challenges which I brought up during a live webcast (recording of Part1) and web discussion (on Ning) that Tony Karrer hosted on SharePoint a few weeks ago. (If you are interested in some on-the ground conversations about SharePoint, dig around the Ning site):

  • SharePoint is not low-bandwidth friendly. Between page load times and the need to navigate up and down, people in low bandwidth areas struggle with SharePoint.
  • SharePoint does not have many offline options for those who have intermittent connectivity, but the tie in with MS Office can offer some opportunities for work-arounds.
  • For global organizations, IT tends to make the software choice without a lot of insight about field conditions and social interaction/working patterns AND are often lured to use any software offered to them free as an NGO. The false economy is the customization costs eat up any savings and then some for these organizations.
  • Global NGOs often do not have the support team to help with implementation and roll out, leaders rarely use the software themselves, setting poor examples and middle managers have little incentive for creating the culture change to adopt the tool. This is NOT a SharePoint problem, but it is a factor that increases the failure rate.
  • The organizations that have successfully implemented SharePoint have good connectivity, robust IT and support teams and usually have a strong content management (file sharing) practice. Not network collaboration.

See also on SharePoint

And related, a Maise Center report on learning platform adoption which has some interesting parallels!

Creative Commons License photo credit: d.billy