4 Final Points to the SharePoint is Crack Debate

By Stephen Fishman (@trivoca) Dec 7, 2011

Last month I dove into the problems that SharePoint brings to the workplace. Matt Ranlett, a colleague, didn't completely agree with me and addressed some of those points. But before we nip this "he said, he said" in the bud once and for all, let me offer a couple of clarifications.

A Few Clarifications

Let's take a closer look at some of Matt Ranlett's responses to my article and provide some additional clarifications:

1. SharePoint as the Be All.. End All..

Mr. Ranlett acknowledged that I had valid arguments related to my core idea that Microsoft markets SharePoint as a panacea despite its affordance for overly simplistic implementation patterns which more often than not lead to the same information management problems that SharePoint was brought in to solve (ok, Matt didn't exactly agree with that, but he got where I was coming from).

The article continues on pointing out that many packaged software products can be implemented poorly. Mr. Ranlett's article fails to account for three critical points here:

Microsoft sets itself apart from the industry in how it courts business users, wanna-be developers and mediocre developers. Its ability to embed itself into an enterprise through rapid but unscalable progress is awesome. Some people say that Microsoft is not user-centered and I vehemently disagree. Microsoft is user-centered, they're just oriented to a different user-base: their army of developers. Don't misread this as me saying that all Microsoft developers are, at best, mediocre. This is patently untrue. There are many extremely qualified Microsoft developers and architects out there; however, the mediocre ones are legion and SharePoint beckons both them, and the executive in search of the quick fix, like a siren on the banks of the Mediterranean Sea.
I never argue in favor of the pre-packaged software products mentioned in the rebuttal article or otherwise. I do argue in favor of solutions which lend themselves to being more rapidly adaptable to the changing needs of today's enterprise; i.e., the cloud vendors.
I'm actually not ranting about SharePoint in and of itself. I'm ranting about the prevalent dynamic where the packaged software is implemented mostly by engineers without qualified designers, strategists or architects. SharePoint currently stands head and shoulders above the others as the poster child for poor implementations across industries. Mr. Ranlett should actually be cheering me on given that I'm actually arguing in favor of the absolute necessity of using truly talented professionals, like him, when looking to implement SharePoint (or any other package).

2. On SharePoint's OTB User Experience

Mr. Ranlett agrees with me that "SharePoint’s out of the box user interface leads users towards isolated information silos" and that "SharePoint can be done well, but is frequently not." The article proceeds in saying that this is by design and is somehow a good thing because it empowers people. This philosophy is overly simplistic and belies the fallacy that pervades so many of the interactions humans go through every day.

When a product is used in a way that is not intended, or fails to self-reveal its intended usage pattern, most people blame themselves. How many times have you heard or said the following: "I must be stupid! I just don't get this." Don Norman's masterpiece "The Design of Everyday Things" points out, more elegantly than I ever could, that we all need to stop blaming ourselves and blame the product design. This tendency for self-blame ultimately limits the pace at which products and services evolve and, in the realm of business software, hurts overall solution quality.