Why Some Organizations Succeed…and Others Fail…with SharePoint

Posted by Gary Voight, CorasWorks President and CEO

I was having a discussion with a CorasWorks customer last week and we evolved into the topic of what it takes to have a successful SharePoint implementation.  This client has had a great deal of success on SharePoint….measured by a rich set of applications and strong end user acceptance.  It was fascinating to hear his story.  It also got me thinking about why some organizations succeed…and fail…with SharePoint.

Before going further into this topic, let me segue a bit.  I have been in the SharePoint world for a bit over four years.  CorasWorks has been in the SharePoint world since early 2003…almost nine years. CorasWorks initially built and sold Web parts, subsequently created a builder package called the WorkPlace Suite, then re-engineered that package into a build & run-time system, and then built Project and Portfolio Management (PPM) and CorasWorks Idea & Innovation Management (Cim) applications.  Over the past two years CorasWorks has been building up a professional services team and has delivered several custom-built applications.  We are totally invested in SharePoint and committed to its success.

I decided to profile a couple of successful SharePoint implementations, and a couple of failures. My attempt was to see if there are any significant lessons.  Here is my summary:


-          Automotive Manufacturer:  This company decided to use SharePoint for a Product Lifecycle Management (PLM) application in lieu of more established products available from their ERP and CAD vendors.  PLM is the process of managing the entire lifecycle of a product from conception, through design and manufacture, to service and disposal.  PLM is truly a collaborative application, and is often employed across customer-vendor lines.  This project was run by Engineering, with some oversight from IT.  This customer saw true value in SharePoint.  Had they pursued product alternatives from their ERP or CAD vendors, they would have paid $250,000 for licenses, plus another $150,000 to $200,000 for customization and implementation services.  In addition, the implementation looked difficult due to a steep learning curve of the products, likely locked them into an implementation vendor, and carried significant on-going cost and maintenance burden for when the product vendor shipped a new release.  As SharePoint had many of the capabilities needed for a PLM, this customer determined it would be simpler to build out their PLM functionality to more precisely meet their operational requirements.  It was also much less costly.  All products and services totaled around $250,000.  The customer was able to get what it needed, secure greater end user engagement, and have something they could easily maintain and extend.

-          Green Energy Company:  This company decided to use SharePoint as a platform for 20+ applications (ie. maintenance schedules, contract archive, PO log, Help Desk), along with a Portal for user access.  There were software packages for utility firms, but none were obvious fits.  Alternatively, they could have hired custom development firms, but these seemed expensive.  They needed to build and implement a main portal, but also needed sites for each plant, the capability for process management, ability to assign and manage tasks, and aggregate data into live reports/dashboards.  SharePoint was a great starting point, but the customer also recognized both capabilities and limitations of SharePoint out-of-the-box….and budgeted what was needed to complete the system to meet their requirements.  Even more important, the customer realized that SharePoint could be intimidating to users and managers.  Therefore, the IT implementation team was fanatical about providing ease-of-use, and truly committed to business and end user support. Although they also contracted much of the build work to CorasWorks, they also knew they could provide for on-going support and additional functionality as needed.

What these successful customers had in common were:

  • They understand the potential of SharePoint, but then realized that many of the “features” were actually only capabilities that required further development or configuration.
  • They understood and accepted SharePoint’s strengths and limitations.
  • They had projects with hard and measureable return on investments (ROI’s), and that this enabled them to gain management support
  • The implementers were focused on the needs of the business functions, and dedicated to ease-of-use and support.


-          Large IT product company:  This company invested in SharePoint 5-6 years ago.  They investigated the potential of SharePoint with Microsoft, and had the full enterprise product packaged into their enterprise agreement.  The CIO announced it to the rest of the company and set up a small IT team to provide some support.  Unfortunately, there was little consideration given to governance and not enough support. Further, no one was allowed to use third party tools.  What resulted was the creation of approximately 3,500 sites that did not have consistent navigation, users who were unable to effectively use what was built, confusion over the location of documents and lack of clarity on document revisions.  Few people were happy with SharePoint.  Approximately six months ago Jive Software was installed, and gained traction with users.  When I spoke to an engineering user he said that he got more use from Jive in six months than from SharePoint in five years.  He now thinks his company is phasing out SharePoint.

-          Financial Services firm:  This firm invested in SharePoint circa 2005.  They had heard some of the horror stories around unmanaged site creation, so they decided to apply strict governance and control.  Only IT could create a site and build out solutions.   Unfortunately, users got frustrated with the IT backlog as well as what they perceived as a lack of SharePoint intuitiveness.  One user group found a way to bring in the Confluence Wiki (Atlassian) and had a positive experience.  That alternative went viral.  When the financial services vertical segment experienced serious business problems during the financial crisis, the IT department lost its funding for SharePoint. The base SharePoint was retained, but has very little use and adoption.

What these failed firms had in common were:

  • SharePoint was rolled out without the enough education or support.
  • IT funding was minimal, and generally left up to the user functions.
  • User functions didn’t understand the difference between capabilities and a finished product.
  • No one was focused on ease-of-use and end user support.
  • They did not seem to have projects that had measureable return on investment (ROI), thus, did not attain management support.

I suspect we all have our own examples of positive and negative SharePoint implementations.  However, the reasons for the successes and failures summarized above apply to any product set.  The underlying difference between success and failure is commitmentIf your organization is not committed to a product, it will almost certainly fail.

Comments are closed.