Monday 11 April 2011

Twenty Reasons Why IT-Driven SharePoint Projects Can Fail

If one thing appears generally true from the evidence to date, IT- led SharePoint projects tend to 'fail', or only have very limited impact. Conversely, business-led SharePoint projects frequently succeed in every respect. There are a wide variety of reasons why this occurs so this article is simply to highlight the top reasons we have observed from being out in the field. Before we commence listing reasons it is worth mentioning what we mean by 'fail'. The failure of a SharePoint project can be determined as failing to meet business objectives, failing to be adopted by the business users, failure to meet original strategic objectives, failure to make the intended impact, failure to adopt best practices to achieve technical objectives, failure to replace other systems, failure to change working practices and embedded behaviour, failure to meet time and budget constraints etc. We should also note that failure can always be turned into success if the right consulting takes place and the best practices followed.

Therefore, before setting out on any SharePoint project (preferably programme underpinned by strategy), one should have a clear sense of what the business success criteria are, what follow-on activities will occur, how success criteria will be monitored and analysed and how to act upon lessons learned in future. But more than anything else, like most software, SharePoint should only exist to facilitate business-driven services, solve business issues, and demonstrate actual business value. A CIO may argue that no, SharePoint is being used for reasons the 'business would not understand', such as the unification of platforms - maybe so, but that doesn't mean that replacing multiple systems with SharePoint is any less business-focused because it is the end user who will be the judge of it's success.

These are the top twenty issues we have noted, in no particular order:

1. The IT department doesn't understand the technical SharePoint platform requirements at the outset and relies on very limited skills to commence it's install, supplemented by some 'technical' blog posts for problem-solving. They treat it like all other 'standard' platforms without having any understanding of the technical skills required, and governance and mechanisms to release and support it.


2. The IT Department explores SharePoint in a 'demo' or test environment, uses a poorly configured platform for a small business proposition (often quickly and under duress) and finds they re now supporting a 'live' platform that won't scale out. Once 'live', the business doesn't give up a service easily.

3. The IT Department has no good business reason to introduce SharePoint and has no strategy for business adoption but is simply driven by the fact that either 'it should be used' or 'competitors and friends are using it'. This often occurs in political situations where competing technologies are sponspored by competing directors who have differing agendas. All this does is stifle the platform growth and leaves the end user dazed and confused. 

4. The IT Department doesn't know how to budget for SharePoint and has very limited funds so attempts to cut corners in terms of technology, design and configuration. Too often there is a very limited budget for 'a couple of servers', perhaps virtualised, with no understanding of farm architecture, the very specific skills required to configure the farm and no budget to bring in a professional partner. Getting a couple of 'developers' in on the cheap or a one man army who can do it all is usually a recipie for disaster in the long term. This is often exacerbated by bringing in a project manager who has no idea what is involved with building a SharePoint service platform.

5. The IT Department selects the wrong supplier or partner. Like all things in life, you get what you pay for. Whilst cost is an issue for everyone these days, cheap doesn't always mean good. There is a reason why one party charges £1200 a day and another charges £200 a day but then again a Tier 1 generalist management consulting firm charging £1500 a day may be a far worse choice than an expert specialist supplier charging £800 a day. In other words, there are specialists who charge the going rate and there are generalists who charge what they can get away with. Worse still are those who cut corners by relying purely on contractors and avoid partner expertise completely. Choose the right partner and you will receive expert advice that saves a heck of a lot of time and money in the long run. Choose the wrong partner and you may be rebuilding your environment from scratch sooner than you think.

6. The IT Department proceeds with no business input and no synergy with business strategy. This really is a big problem because SharePoint requires explicit business sponsorship and input. Without it, SharePoint can easily be seen as an exploration of technology without any business raison d'etre. Would you build a house for someone without asking what they want first? The chances of releasing an effective service to a business community that meets their expectations without first understanding or at least setting their expectations, is remote to say the least.

7. The IT Department has no interest in SharePoint and, typically the IT leadership team, views SharePoint as something the business wants but something that is of no interest, or not to be used by IT as a department themselves. This is all too common and one only has to look at IT departmental use of SharePoint services to see that SharePoint is often viewed as something that happens to business users only whilst missing the point that IT is indeed a business department too. Without fundamental IT leadership understanding of the possibilities of SharePoint, it is extremely difficult to influence respective business leaders who will themselves need to inspire their teams.

8. The IT Department is unprepared for fast business adoption and uses 'change control' as a method to stifle its growth due to lack of IT strategy, budget and resources. In other words SharePoint is a big business success and has led to a greater range of business services request than was expected. The IT Department is caught on the hop, doesn't know how to respond and instead uses a wide range of means to slow down further business interaction or service release. In turn the business user community becomes increasingly frustrated and turn their attentions to other things, services or simply complains bitterly. Setting up every single out of the box service as a 'project' is a classic case in point.

9. The IT Department has other technical challenges such as bandwidth, poor infrastructure, over capacity, a backlog of other projects such as an aging desktop and a general lack of strategy. What often happens is that the end user only sees SharePoint as a point of reference regarding performance (browser) and incorrectly percieves it as 'slow' or unreliable. Poor infrastructure can quickly undermine a strong browser-based service. How many times have you met a network engineer who swears blind there is nothing causing slowness on the network! When this happens the increasing use of SharePoint highlights the weaknesses in other areas of IT, but the end user doesn't understand that and perceives SharePoint as a failure. This is a perfect scenario where the IT department should begin to investigate Microsoft cloud services such as Office365 as this takes away the management responsibilities of the SharePoint infrastructure overhead and allows IT to focus instead on other areas that need enhancing quickly.

10. The IT Department is not committed to SharePoint as a core system and uses it in an ad hoc fashion for random small solutions. There are times when this strategy can work effectively but this strategy underlies a deeper problem which is that the major/core IT systems are not clearly defined and aligned. In other words a clearly defined SharePoint strategy and roadmap (the future) would demonstrate that SharePoint offers a huge amount of services that could replace legacy systems (maybe now, maybe when other licenses expire), integrate systems and act as the unifier of technology to the end user. Put simply, there are far too many IT bosses who are afraid of change and prefer to maintain the status quo rather than advancing technology services to the business - 'anything small, new and inconspicuous, stick it on SharePoint boys'. 

11. The IT department does not spend enought time at the beginning understanding the business benefits and services of SharePoint and then using a SharePoint awareness programme to advertise the benefits to the wider business community early enough. This really is a bugbear as it is so easily avoided. tell the business suers what is coming, excite them in the possibilities of the technology, show them the art of the possible and inspoire them to take part and adopt. Do this at the beginning and you already have an excited audience. Do this after the event and you have already lost them.

12. The IT Department offers conflicting technologies which can offer the business user the same services. Why I should I save this in SharePoint when I can save it in Outlook, in My Dopcuments, in Lotus Notes (say), on my memory stick and in the Oracle portal? This is where business and IT governance comes into play. If you don't establish the rules from the outset all you will do is provoke prolongued confusion and the workers will make up their own mind. Each technology has its purpose and its business justification, so from the beginning, IT must be absolutely clear on what technology is being used for what purpose and make this clear to the business too. The less a user needs to move between technologies the happier they are, which is why SharePoint is such a great unifier and why social networks such as Facebook have been so successful.

13. The IT Department doesn't budget for training and business user adoption and releases a SharePoint service hoping people will just 'pick it up'. All too frequent this one and something here at Salem that we strongly advise against. Whilst it is possible to make technology 'easy to use' there are as many different users as they day is long. What may seem easy and intuitive to some, may well be difficult and incomprehensible to others. People sell their time to work and get money, so introducing new technology and making people's work harder (at least for a while) is not a route to success unless they are assisted through the change.

14. The IT Department does not focus on govenance and policy which fundamentally underpins training and adoption and business users are left to decide themselves whether to use the new services or not in a confused and piece-meal fashion. It isn't just abpout training, it is about demonstrating the logic clearly behind why things are changing, and changing for the better. People need to understanding when to do something, where to do it and why they are doing it, and to a degree, what happens if they do not.

15. The IT Department hasn't aligned its IT strategy to meeting the business strategy. If you don't understand the business and know where the business is going how can you support it through new software services ? Once again, SharePoint has a wiude range of superb business service offerings but there is no point releasing something for the sake of it, it has to be aligned with business priorities. All too often we see a Finance department asked to adopt a SharePoint service during year end or whilst they are moving to SAP. We note an HR department who is trying to cope with a new HR system but is asked to spend time moving to SharePoint collaborative services. Understand what the business priorities are, then cater for them in an orderly manner and use SharePoint to underpin and enhance.

16. The IT Department takes a project rather than programmatic approach. In itself this does not make SharePoint fail, but what it does do is make only limited use of an extensive platform that could easily offer the business user so much more. SharePoint should be viewed as a sequence of inter-related and enhanced business service releases (a programme) over time, in line with practical timescales for effective user adoption. It is easy to prove the point, search a job board for a SharePoint project manager and you will find vacancies, look for a SharePoint programme manager role and you will struggle. Why? Well two reasons, first it is easier to view each business requirement as a separate project that fits an IT budget and resource pool that can be controlled in a measured fashion, and second programme managers cost more than project managers. However, we think one of the real reasons is simply because most clients do not have a roadmap view of SharePoint, cannot easily see a business service sequence of inter-related projects and simply do not have a SharePoint strategy. 

17. The IT Department underestimates the time and effort to design, build, configure and release SharePoint services. SharePoint must be designed and built correctly, particularly to cope with potential scaling and growth over the long term. This is all too common and leads to platform instability through poor configuration. The only way to handle this from the beginning is to bring in the required expertise at the start, analyse the potential growth and service requirements and design and configure accordingly. It is extremely likely that SharePoint will be asked to provide a wide range of services, not just the service for which it was originally commissioned. 

18. The IT Department takes a purely 'development platform' view of SharePoint. SharePoint is extremely dynamic and agile and slowing down a release cycle because everything has been coded from new and developed bespoke may slow down business adoption to the extent that it simply fails to make the desired impact within frustrated business-driven timescales. Out of the box SharePoint services, and particuarly those exempt from standard IT change control procedures, liberate the end user from laborious project-driven deliverables and ensure that IT is seen as a facilitator and agile service provider. Developing everything means that cost and time impact, if not stall, the growth of SharePoint within the business.

19. The IT Department believes 'organic growth' will gently provoke user buy-in without much risk and much expenditure. What happens when the business users do buy-in to it and the platform hasn't been readied as fit-for-purpose? What happens when there is no IT or business governance in place to cope with its growth. What happens if the business insists other services should be added but the platform cannot scale out due to initial failings in the initial design and configuration? The answer is that the business users will be dejected and frustrated why SharePoint does not cater to their ambitions, when indeed it would, if such requirements had been captured in simple analysis at the start.

20. The IT Department doesn't like SharePoint. Yes I know this is difficult but we have witnessed environments where IT managers do not favour SharePoint and have their own favourites such as open source, or some other product vendor. Personal choice should never flavour an IT strategy and yet it occurs more frequently than we would like. There are many IT managers who have selected major software for an organisation for purely selfish reasons and then gone on to undermine excellent products like SharePoint because it doesn't fit their personal philosophy.  

Let us finish by saying that we have worked with numerous excellent IT departments who have avoided these pitfalls due to good advice and planning. The reasons listed above do not negate well thought-out IT strategic SharePoint delivery programmes. However, any IT department must begin by endeavouring to understand SharePoint both from a technological and a business adopter perspective. To effectively manage SharePoint, old principles and processes within an IT department may need to change or go completely. SharePoint is a true IT enabler, and for those departments that have a current PR issue with the business, SharePoint offers a fantastic route to true agile business service delivery. We are sure that you could come up with other reasons but as we said earlier in the article, any of these scenarios can be rectified with a simple approach. If you recognise any of these and would like a solution, give us a call at Salem.