SharePoint

4 Telltale Signs Your SharePoint Project Will Fail

By March 13, 2015 No Comments

50% of internally implementad SharePoint projects failDid you know that a staggering 60% of SharePoint projects are stalled, struggling or failing?

According to a recent research by AIIM, every second SharePoint project, which has been implemented with in-house or internal expertise and external training, fails. Another estimated 20% of all implementations fail even with the guidance of a consultant or consultancy!

If you consider the cost of implementing and servicing Sharepoint is between $6-$9 per $1 spent on licenses, this will make an unbelievable $3.6bn – $5.4bn down the drain every year!

But what are the reasons for such a high failure rate? Here are the four most common scenarios:

#1) No Unified Strategy

A SharePoint implementation is like building a house. You must have a sound architectural plan, get permits and the approval of an engineer before you hire contractors to start pouring the foundation. If you don’t and you piecemeal together one room after the next without a plan, your house would have a horrible layout, no unified design. It would be inefficient, and in the end, cost you a lot more than if you had invested in the planning phase first.

The same is true for your SharePoint implementations – without a unified strategy in place first, you are setting yourself up to fail.

For example, I recently helped a client get their enterprise-wide SharePoint implementation with several hundred users back on track. Each of the involved departments had contracted different vendors to build the same functionality, or created functionality that other departments could have used as well. All departments were tracking data differently, making it impossible to roll them all up into unified metrics.

#2) Business Goals First

Unified StrategyIn my experience, the person tasked with the SharePoint implementation is held accountable to business goals. A lot of times, SharePoint licenses are bought as part of a Microsoft Enterprise License Agreement, as a larger organisation-wide technology push or a business department gets carried away. The primary focus is on getting the acquired technology deployed, with little or no consideration for overarching business goals.

No matter what your reason for getting started with SharePoint, your primary focus must consider your overarching business goals. The technology needs to serve the business, not the other way around.

Otherwise, your project will not get any funding or support from any executives. Prove how your efforts will make or save the company money. So, before you even start thinking about implementing your Sharepoint project, ask yourself why this would matter to your CEO? Does it save your company one thousand man hours this year? Does it improve collaboration between the product management teams?

#3) No User Centered Design

Most software projects include a phase called user acceptance testing to make sure the product is built around design requirements and meets statement of work. However, often the statement of work does not meet real-life business requirements. Just consider how that can mean something different to you than it does to me.

By engaging and involving your users early on (e.g., by presenting them mock-ups) you make sure, you are all on the same page. For example, recently I presented mock-ups of functionality that we were going to improve upon in an already existing SharePoint project based on the statement of work requirements we received. But it turns out the users do not have that functionality! This would have cost the organization easily 20% of the entire budget – that now can be invested in functionality they do need.

#4) Stealth Mode

There are two ways you can go about any software development: your team of designers and developers can create a product and present it to users when it is done. Or you can involve users even before you write the first line of code by making sure your ideas meet the user’s requirements.

While it seems the easier (less political) way out, to take the first route, it is almost always a recipe for disaster.

To make sure, you don’t fall into this pitfall, make sure to roll out one project initiative at a time instead of overwhelming your user base with ten different ones at once.

This lean, iterative approach will allow you to collect feedback very early on and turn-key influencers into your biggest advocates by involving them and getting their approval. If not, these key influencers are not bought in and often will block your initiative.

What roadblocks did you hit with your SharePoint project?

We would love to hear your experiences, your successes, and roadblocks. Please share in the comments below.

Mark Tiderman

Author Mark Tiderman

More posts by Mark Tiderman