Friday, May 1, 2009

Why SharePoint Projects Fail

Microsoft Office SharePoint Server 2007 (affectionately known in our circles as “MOSS”) is now at what should be at the peak of adoption.  The product has been on the market since 2007 and there is a new version coming in a year.

Yet with many of our customers, we find that MOSS has been implemented but barely gets off the ground.  There a few reasons why this seems to be happening:

  • MOSS is championed by IT and then too tightly controlled.  For example, we have customers who have installed MOSS but will only use it for out of the box collaboration – no custom code, no document management, no BI, etc.  If you want an out of the box team site, then that’s part of the “service” but otherwise you will have to wait.
  • MOSS starts in a single department and then never makes it out.  A department picks MOSS for their needs but then there is not enough support or sponsorship in the organization to roll it out further.
  • MOSS is implemented skunk works style on a single box.  The implementation is more successful than originally envisioned and what was a “proof of concept” starts getting treated like production.  This sets up the assumption that MOSS is “Rapid Development” and eventually the box falls over under strain.
  • MOSS is implemented by IT but there has been no planning for adoption and training.   MOSS sits there with a bunch of services – users simply don’t know how to use them and go on using other more reliable forms of collaboration such as email, file shares, etc. 
  • The implementation gets mired in legal, HR, or branding issues as corporate citizens start to have the ability to create their own content.  Similar to the IT clamp down, the organization clamps down on the services that MOSS can provide such as blogs, wikis, My Sites, etc. because they do not have a good model for managing the risk of employees contributing their own content.

Why does this happen?  What is missing from most MOSS implementations?  In my experience, there are a few common causes:

  • Too much involvement by IT, not enough involvement from business stakeholders.
  • Too much focus on MOSS as a generic toolbox (document management, collaboration, search, etc.), not enough focus on MOSS as a way to automate or enable true business services.
  • Poor infrastructure planning to enable scaling to the enterprise.
  • Lack of training, adoption and change management.
  • Lack of a killer app for the particular needs of the business
  • Not enough support from executive champions
  • No governance model to set expectations on how MOSS will be operated, changed and maintained.

If you are an IT Director or department champion for SharePoint, I strongly encourage you to think about these issues BEFORE you start an implementation.  We see many cases where organizations start thinking about these issues after the first implementation has already failed and the organization has soured on the platform because there was not enough investment in managing the project and an eager IT department ready to roll out a service.


jc said...

These are excellent points Chris. We use SharePoint, and I would venture to say that it's use has also been a failure, due to many of the reasons you state.

There are others however. A lot of core features either do not work, work poorly or are just riddled with bugs. I do not have first hand knowledge if this is because of configuration issues, or simply caused by the product itself. But the general taste that one gets, as an end user, is on par with eating last nights Kraft Dinner.

I also believe that in typical Microsoft fashion, the product is trying too hard to be too many things at one time, and because of it, it lacks focus. Quality suffers due to this ADHD, and confusion on how to use it also spawns from this symptom. The old principle of do one thing and do it well is clearly lacking from the design and evolution of this product. Which is a shame really.

But it is not all bad. A few months ago we were able to make a dozen or so customer portals in a few days without any development effort, using the tools provided, and quickly deliver on a customers urgent need. It is used internally by all departments mostly for document management and sharing fairly successfully. And any product that can allows you to get work done quickly and effectively in a busy IT development department is not all that bad in my book.


Anonymous said...

There are a lot of reasons why SharePoint sites don't make it off the ground, but this list is awful and barely scratches the surface on exactly what makes MOSS so bad. If you're not doing custom development in MOSS, for example, consider yourself lucky. It's a disgusting pile of crap. The API looks to have been written by a bunch of narcissistic, junior level developers, posing as principal developers, that were thrown into powerful positions by brain dead management. Anybody involved with the MOSS architectural direction should be fired. They're worthless. I've never come across a more hideous platform. Worse yet, idiot CTO's and other technology leaders believe it's the "be all end all development platform". At its best, it should be considered nothing more than an extension of the Microsoft Office suite.

Would you suggest developing all custom applications in Word? Then why is it that technology leaders feel differently about doing the exact same moronic thing in MOSS? Seriously, MOSS needs to die and anybody that supports it is worthless in the software development world.

Anonymous said...

Sadly, I have to agree with the other anonymous, except he/she/it goes a bit over the top in true anonymous fashion.

I can only describe the development side of MOSS as "icky". I think part of this is that MOSS is from the Office team at Microsoft, not the development team. Another part of this may be that the development side of MOSS was originally more of an afterthought. From what I hear MOSS is a huge step up from the previous Sharepoint in terms of the development side of things, so perhaps the next version will be more palatable to developers.

I also find the admin functionality in MOSS to be counter intuitive. And as an end user of MOSS, I feel the same way. MOSS sites just feels "weird" to me. This may be because the product does not target 'web savvy' folks, but rather the non-web savvy folks.

I know that the company I work for during the day has had problems scaling MOSS - even after following Microsoft's guidelines regarding MOSS setup, consulting with Microsoft folks on the architecture as well as other MOSS experts.

This isn't to say that the problems we've seen are specifically the fault of the product, because our environment may be a bit different than a "typical" installation. However, it is disheartening when the "experts" have trouble recommending a MOSS architecture that works for us.

I think MOSS adoption will be helped (compared to other solutions) by the economic downturn, at least at larger companies that already license all Microsoft products and are looking to cut costs by moving from more expensive solutions to MOSS.

It will be interesting to see what the new version of MOSS brings.

Anonymous said...

We have both MOSS and Confluence (a wiki that comes with the ticketing system JIRA). Thankfully MOSS died on the vine.

It looked to me like a thin wrapper around a file system. People would post Word (!) documents to it and expect others to check them out, make local edits, and upload. Oh and don't forget to lock / unlock it. A lot of these people were ex-MSFT.

They eventually came around to the wiki as their documents quickly became out of date. It was like the electronic equivalent of a dead tree copy.

And the search was awful. Like unusable awful. Contrast that to the wiki that did its own pages and searched inside of the occasional word doc.

I'm not sure what MOSS gives anyone. Maybe it has an easy to install interface or that it comes preinstalled? There's plenty of free and inexpensive wikis out there to ever go with MOSS.

Marcelo Lopez said...

@Anonymous 1 & 2: I don't think Mr/Ms. Anonymous goes over the top, as a matter of factor, I think Anonymous 1 was rather reserved in some respect.

Speaking from the standpoint of a developer, and an architect that's evaluated extension systems ( like K2 Blackpearl/Blackpoint )and find it still woefully lacking for many things.

First let's look at business processes in general. When is ANY business process ( especially one's involving BPM and Workflow together ) EVER static in any sense. The answer is never. Sure any particular snapshot might have a lifespan, but usually that lifespan can be measured by an egg timer, not the atomic decay rate of carbon-14. MOSS has no innate way of rolling out versionable business processes that can overlap, or even cohabitate. When you roll out a document, that's the document, you edit, approve, request mods, etc. But on THAT version of a document, there's no literal temporal way of managing the lifespan of anything that's requires versioning of any sort.

Secondly, like jc said, MOSS tries INCREDIBLY hard to be every possible CMS to every possible CMS situation. Again, woefully inadequate because as Anonymous 2 said, the development side is "icky". Actually, no, I'll see his/her "icky" and raise it with "inane". Sharepoint Designer is practically Expression Web ( nee MS Frontpage ) with a few different templates installed, and some various menu differences. The fact that tools like K2's toolset are almost a no-brainer for anyone trying to do anything MOSS of significant merit, is a testament itself that trying to do so without tools ( like K2 ) and using only what comes "out of the box" on MOSS is devoid of any practical sense. Not that I've found using the extensions gets you much further along that what many other CMS/DMS's do out of the box already without all the hub-bub and extra expenditures.

Anonymous said...

Accurate and appropriate post with commentary sounding very much like one other widespread SP project problem: arogant IT who under respect the complexity and committment this platform requires to be truly effective. Yes, it has frustrations, and probably spreads itself too thin, but no enterprise platform like this can be said to be free of such difficulties. Everyone seems to approach the product trying to leverage a specific area, (CMS, collab, workflow) and the howls when it doesn't do all the work for them, or anticipate all their needs in that area. Yes, each area is not as fully baked as dedicated platforms are, but they don't have all the other areas that can be leveraged. If you only want CMS, BPM, or such, SP is not where you should be anyway. This is a broad based STRATEGIC platform, requiring serious commitment and experience to bring it all to bear effectively.