What’s wrong with SharePoint?

You've probably seen or heard the message quite a few times: "We can build a intranet for you in less than one week". (Me and Jeff Willinger had a good laugh at this particular rollup)

I am sure they can. But it is really "How fast can you build me an intranet?" the most important question you want an answer to? I can guarantee you that it's not. For one thing, it assumes that you know exactly what you need and that you know that you will find everything you need in one product out-of-the-box. When did that happen recently? Have you even heard it happen to anyone? (Well, I believe it when I see it.)

The questions you really would want to get answered are likely questions like "What do we need to improve and why?" and "How can an intranet help to improve it?". So, the first thing you will need to do is to cover your eyes and ears when you read about or hear messages such as the one above, and instead spend your time and energy on finding answers to questions such as:

• What pains are we experiencing, where, and how can those be relieved?
• How can our work be supported, taking into account the entire flow of a particular task or process?
• How will people interact with the solution in the context of their work, at what touch-points, and what value will each of those interactions give them?
• What will you need to improve that is outside the scope of the platform, but necessary to make work flow smoother end-to-end?

The last bullet is anything but unimportant. If you just improve a part of a task or process, the investment in the new solution will be wasted if there are hurdles elsewhere that make it hard, or provides no added value, to adopt the new way of working. The chain will break at its weakest link.

Let's take an example: Many organizations have implemented SharePoint to support collaboration and communication in projects and other collaborative efforts. For this purpose they typically implement team sites with lots of features and a nice corporate look and feel. Still, so many organizations fail to get the basic document management capability that it supposed to be SharePoint's main capability to work. After some initial attempts by users to collaborate on documents via SharePoint, they usually continue to collaborate on documents as they used to before, emailing attachments back-and-forth, or working on the document on file server with ad hoc versioning in the file name. SharePoint becomes a place for storing documents when the documents are completed, which in combination with the fact that few people see the value in visiting SharePoint when they work with their documents elsewhere turns it into a document graveyard.

"80% of email users with SharePoint access continue emailing documents back and forth, instead of sending document links and using library services for check in, check out, and version control.   This is consistent with the overall population of email users surveyed"
- September 2010 uSamp survey

First, let's be clear with one thing. This is not SharePoint's fault. Blaming the product is simply the wrong approach. It's like blaming the soup when you’ve spilled soup on your shirt. Blaming the product is what you do when you're too embarrassed to confess that you have made the wrong choice of product, or implemented it incorrectly. Or when you want to indirectly blame the person who did just that (my suggestion: try to find the root cause instead and fix it).

Every product has it's weaknesses, and those weaknesses typically exist somewhere outside of the scope of the product. The weakness is this example lies in a part of the typical workflow people use when collaborating on documents that the product doesn't support, for one reason or another. This leads me to the second point: What the product supports and what it doesn't support should be a well-know fact from the start. It's one of the reasons why you would hire a company to implement SharePoint for you. They should know what the product can do and what it cannot do, and be able to explain that in the context of your work. They should help you spot and fill in the blanks. Do you think a company that tries to sell you a new intranet in one week will do that?

In the example described above, such a simple thing as adding a third-party product for SharePoint to the mix can make all the difference. There are vendors, like harmon.ie, that have made it their business model spot weaknesses in products that make work break, and provide solutions that help organizations overcome those weaknesses. If organizations would just adopt a similar way of thinking and approach to implementing technologies for information workers, they wouldn't waste so much money on implementing technology solutions that doesn't get used or bring the expected returns.

As my friend Michael Sampson, Collaboration Strategist, puts it:

"Clearly you need to know what the technology can do…but the focus you should have is: how can I bring these features and capabilities to core business problems and pains people are dealing with."

Yepp. But that's obviously easier said than done.