Why do SharePoint Projects Fail – Part 5

Hi again and welcome to this seemingly endless series of posts on the topic of SharePoint projects gone bad.

We spent a couple of posts looking at problem projects in general before focusing specifically on SharePoint. If you have followed the series closely, you will observe that haven’t talked much on technical aspects of the product yet. If you were expecting me to pick apart annoying aspects of the architecture then unfortunately, you will be disappointed because I really don’t believe that it is a big factor in why SharePoint projects fail. Besides which, 90% of SharePoint blogs are on technical/development content anyway.

So where am I going with part 5 then you ask?  I am indeed delving into technical aspects, but once again it is all about the people involved.

So now its time to take a few cheap-shots at the geeks. (After all, they are sensitive souls and we don’t want them to feel left out do we). For the purposes of this post, infrastructure people, tech support, system administrators can be lumped into the same ‘geek bucket’.

Geeks can also cop it like Project Managers do, when projects take on wicked tendencies. They will implement the agreed requirements, but the stakeholders feel that the end result isn’t what they wanted. In the ensuing fallout that happens when the project sponsor realises that say, half a million bucks has been blown with little to show for it, blame is inevitably directed their way, whether justified or not.

In some ways the geeks have an easier job than others in the project (but don’t tell them that you will bruise their ego’s). The infrastructure geeks simply have to plan, build and configure the SharePoint farm and assimilate it into existing infrastructure.They deal with servers, SAN’s, networks and in general, devices are much more agreeable than other humans :-). Infrastructure integration can range from easy to hellish, depending mainly on the attitude of management to its importance and the ability of the geek to sell that importance. Sadly, both sides equally suck at this – and it is a reflection of “organisational maturity” which we will get to a little later.  

In Homer Simpson’s imaginary land of chocolate where everything is wonderful (and edible), the infrastructure people and developers take the functional specification and build it without ever having to speak to the users/stakeholders. You see, in this land, the business analysts and stakeholders have done their job and the agreed off requirements are exactly right, thus all of the problems outlined in the first four posts of this series never happened 🙂

So to complete this article, we have to spend it in the land of chocolate, because we have to suspend reality and assume that somehow, we have managed to avoid all of the issues outlined in parts 1 to 4.

I realise that this requires a significant suspension of belief, but humour me and just go with it…

Product Complexity – Infrastructure

Let’s face it. SharePoint is big, complex, nasty, over-engineered yet under-engineered, skinnable yet unskinnable and depends on other products and supporting technologies that have big, thick books written just about them (SQL Server, ASP.NET, etc). Such a large number of components means there are equally as many points of failure or disruption, therefore points of governance to cover and experience required to cover it.

The combination of skills required to really become an expert in this product is not easy to develop unless you have a significant amount of real world experience over a period of time. To give you some idea of what is required, Joel Oleson wrote a blog post some time ago on what he considered was the combination of skills required to be a SharePoint Architect. The list was expansive. I’ve listed some below (and cut a heap of them out too)

Ready? Take a deep breath… 

IIS, Windows Server, TCP/IP & networks, SQL Server 2005 Advanced Administration, Firewalls, Proxies, Active Directory, Authentication, Security, IT Infrastructure Design, Hardware, Performance Monitoring, Capacity Planning, Workflow, IE, Firefox, Office Client tools, ASP.NET, HTML, Javascript, AJAX, XSL, XSLT, Exchange/SMTP, Clustering, NLB, SANs, Backup Solutions, Single Sign on, Monitoring & Troubleshooting, Global Deployments, Dev, Test, Staging, Production – Staged deployments, ITIL, Virtualisation.

… and that’s just the core skills apparently! There are many, many other skills listed by Joel – and I could add a few more myself.

The complexity of the infrastructure requirements are very much a product on the size of the organisation, the scope of the project and which SharePoint disciplines are involved. The biggest mistake project teams and infrastructure people make is to underestimate the implications of this infrastructure investment.

I remember sitting in on an early project team meeting for a widely scoped, document centric SharePoint deployment. It was for a company of some 500 staff with an existing 1TB+ file system. I told them that for what they wanted to do, and for the organisation size and utter reliance on its availability, they had better size up and budget for a clustered SQL Server and SAN. I also warned them, that their existing backup infrastructure may not be scaleable enough to accommodate the requirements of SharePoint and they should also investigate this. The look on the face of the CIO should have made my spider senses tingle. It turned out that they were not aware at all that all the documents lived inside SQL Server. Thus the possibility of a high speed, fault tolerant SAN, a review of their backup system and a clustered SQL server never entered their minds.

That small ‘oversight’ ended up costing some $200,000 all up. That came close to doubling the initial budget that was sold to the project sponsor – ouch!

Scope, Infrastructure and Organisational Maturity

This doesn’t really belong in part 5, but I forgot to mention it in part 3 (blush). When I talk of “organisational maturity”, I am not talking about the how crude the office dirty jokes are, but I am talking about maturity in relation to awareness and pragmatic adoption of best practice methodologies. Perhaps another term to use is corporate wisdom?

Anyway, many methodologies, such as COBiT and CMMI, contain a measurement system which allows an organisation to rate themselves against what the standard considers to be ‘mature’. In this way, the organisation has the means to know where they are and where they need to get to.

In this competitive, post SOX world of compliance and governance, this is becoming an increasing part of the corporate and IT landscape. Organisations need to provide assurance to their customers, shareholders and staff that all is well and that their investment in the organisation is safe.

Sarcastic Note: I’m very interested in whether compliance has made any difference in the current subprime mess. Expect more posts on that topic.

What I have noticed is that the ‘less mature’ an organisation is, the greater the propensity for wicked problems to occur, whether SharePoint or any other product. I believe this is because of all of the factors described in the first four parts, but particularly, panacea effect, described in part 3. The panacea effect can easily take root at organisations where the culture is not conducive to organisational maturity. A less mature organisation will find a tool with potential and then try and solve all of their problems at once, without the sort of soul searching, dialogue and raw data analysis that would give them a deeper understanding of the problems they face.

Another inexplicable problem that I have also noticed (but haven’t quantified), is that organisations with a low maturity often find it difficult to properly make use of the very methodologies and frameworks designed to improve maturity. They are well aware that they have problems and want to improve, but always seem to go about it the wrong way and go from complete disorganisation to complete over-the-top process and structure. Typically this does not end up improving productivity or resolving longstanding problems and in extreme cases, can do more harm than good. ISO9001, PMBOK, ITIL and process improvement methodologies like Six Sigma have suffered this fate. It is basically the panacea effect in action again, this time not around a platform like SharePoint, but around interpretation of the intent of the methodology.

Infrastructure and Project Budget

The result of product complexity and low organisational maturity is a vicious circle. The poor old infrastructure architect/engineer is asked to plan, design and size a solution to a system that will “do everything”. The infrastructure person usually have had little visibility or input into scope and the requirements. Therefore, with so many knowns and equally many unknowns, they have little choice but to produce an infrastructure design to accommodate all of these possibilities.

SharePoint’s complexity and aspects of its architecture mean that there can be a significant infrastructure cost for many projects. For example. A stakeholder would have very little idea just how much work the seemingly innocuous request of requiring that the SharePoint solution be extranet accessible, adds to a project. Another example would be that a stakeholder would also not appreciate the implications of mandating that all files in SharePoint are to have a complete version history.

Inevitably, infrastructure is going to be costly. As a general rule, the more ambitious the scope of a project, the more complex it is to plan for a cost effective infrastructure. When faced with an uncertain future, it is always preferable to add another server or two for more redundancy 🙂 When it is all said and done, the infrastructure person can rarely give you a guarantee that their solution is adequate either. Instead they can rate the solution in how comfortable they feel about it.

Thus, in the low maturity organisation, the project manager and project sponsor will balk at the cost because it blows away their initial, relatively naive, time and budget estimate. This is despite the fact the scope of the project is likely so broad that is has some wicked problem elements in it. The Project Manager may inform the infrastructure architect that the cost is unacceptable and try and pin them down into reducing the cost to save the project, and in bad cases, save face with the project sponsor or senior management.

I used to ask senior management to provide me growth assumptions to try and work through a balance between cost and benefit when this occurred. This method placed accountability for the assumptions in the right place, but often did not solve the infrastructure and budget issues. One notable case I had was an infrastructure design for a private company owned by a single managing director. The director had a serious case of rose-coloured glasses and delusions of grandeur around the growth prospects of his company. His growth figures were wildly optimistic and thus so was the cost that I provided. But at least I was able to argue that the design was sound, based on the assumptions that I had been given.

Conversely when there is a budget issue in a higher maturity organisation, senior management, the project manager and project sponsor would initially be more interested in why there is such a disparity between their budget estimate and the actual cost. From there they would determine the root cause factors that allowed this to happen. I’d love to get into how an organisation gets from low to higher maturity, but that is not the intent of this series of posts, so we’ll have to leave it at that.

Infrastructure and Product Skills

As previously mentioned, SharePoint is complex and the products it relies on are also complex. In the wrong infrastructure/architect hands, this can cause costly problems. Interestingly however, I have noticed that a lack of product skills among architect and infrastructure staff does not necessarily impact the project in terms of the project metrics of time and budget. Nerds are rather adept at hacking away enough to “make it work”, and thus they have a talent for winging it. Instead the cost will be quality, but that cost will not be immediately apparent.

The geek contribution to project failure is not as overt. Instead, problems caused by cutting corners tend to manifest themselves post implementation, where bad decisions, poor governance and dodgy workarounds all have a habit of coming home to roost in some nasty, high profile and costly way. By then however the project team can deny all knowledge :-). I really should do a blog post about infrastructure complexity separately to this series for the above reason. Since the risks around infrastructure complexity manifest themselves usually after the project has been delivered and is into its operating phase.

That said, In the project planning process however, it is common that several infrastructure oriented tasks are under estimated due to a lack of appreciation of what is involved. Some notable ones are:

• Capacity planning
• Impact on existing infrastructure
• Information Architecture
• Governance (procedures, standards, guidelines, change control, configuration management, etc

In the final section of Part 5, we will touch on each of these areas

Infrastructure – Capacity Planning

This is a particularly complex and overlooked area in document oriented collaboration projects. I specifically modelled a mythical project budget estimate in my return on investment series on this exact project type. Being document centric, it is the scenario that puts the most pressure on your infrastructure in terms of disk IO performance and growth due to the added overhead of version control, full text indexing, backup and recycle bin requirements. It is also impacts (and is impacted by) the information architecture and logical architecture design of SharePoint because of the architectural limitations of the product.

Microsoft’s top support call reasons were listed by Joel some time back and many of them are basic issues addressed via a capacity planning exercise.

• Are you monitoring all your disks?  If you did a simple/basic all in one install is it all on one drive that you are watching?  Disk space available on WFE and SQL, common support issue is Basic install running out of drive space for SQL
• If large file support is enable are the myriad of configuration settings to make this work configured, http://support.microsoft.com/?id=925083
• Scan the SharePoint farm and report if any of our capacity limits are exceeded, http://technet2.microsoft.com/WindowsServer/WSS/en/library/2aa12954-2ea7-475c-9dce-663f543820811033.mspx
• Check if /3GB switch is enabled in boot.ini, WSS does not support /3GB switch
  http://support.microsoft.com/kb/933560

Impact on existing infrastructure

Closely related to capacity planning is the impact that SharePoint has on existing infrastructure. As I mentioned in one of the examples above, the client gave utterly no thought to how adequate their existing backup system was for accommodating the database oriented nature of SharePoint. As it turned out, it was completely inadequate as it was, before the complexity of SharePoint was added to the mix. To rectify the problem required a new backup system that cost in the region of $50,000.

Extranet requirements are also typically unappreciated too. It is easy to ‘extend’ a SharePoint virtual server to be accessible via the extranet, utilising say, SQL authentication. But there are firewalls, reverse proxy as well as logical architecture to consider. Do you really want say, your internal documents potentially accessible via an external facing web server? No? Then you may require separate content databases, web applications and site collections to improve the “chinese wall” between internal and external oriented content. Ah, but that has its own implications on design, governance, custom development costs and information architecture.

Information Architecture

Information architecture is a large topic and I cannot do it justice here. Suffice to say, that we are talking about concepts such as design decisions around the set-up of web applications, site collections, sites, sub sites, site columns, site content types, libraries, lists, workflows, forms, navigation, user profiles and search to name a few.

Prior to SharePoint, many users will have known nothing else but messy shared file systems where the only means of classification was folders and file naming conventions (that no-one ever followed anyway). Now we have many other tools at our disposal which in theory is a good thing.

But as I said, many people know nothing but folders. This has been the predominant file classification mechanism for more than 30 years. Trying to “un-learn” more than 30 years of operating fundamentally the same way is not something that will come naturally. Thinking in terms of columns, views and content types requires a deeper understanding of the divisions, disciplines, compliance and vertical market of an organisation.

Information Architecture is one of those phases in a project that should come with a safety warning. “Please kids, do not try this at home”

I’d love to write more on information architecture because it cuts to the heart of what I currently spend a lot of time doing, but this post is getting long :-). So, I’ll simply say this: Information architecture is a very, very difficult area to get right and it can seem like more art than science. (don’t worry, there is science). Even in a good project, the amount of time and effort to develop it is grossly underestimated.

Yep, you heard right, even in a good project.

My absolute worst scenario is for people come at it with a naive notion that you can say, pick 5 columns to classify *all* files in an organisation the same way. This is records management thinking, and if you read this post, and think that I am mistaken and standard classification is the way document management should be, then I say to you in all seriousness, you have picked the wrong product and your definition of document management is different to mine!

Governance

Governance thankfully has been getting much more press in blogs, webcasts, whitepapers and the like in the last half year. A lot of it is still of questionable quality, but at least people are starting to factor it into their SharePoint project planning.

It is all well and good to use the term, but project teams still underestimate exactly what is required for governance. For all of SharePoint’s good points, it does have a relatively high cost of ownership in my opinion and that ownership cost is completely in the area of governance. In other words, I don’t think day to day management of a SharePoint farm is a big task. But if there is not a certain degree of discipline around change management, configuration management, procedures, standards and guidelines to administrators, users, site owners and developers, bad things will happen. Failure to maintain this discipline, means that the ongoing reliability of the system will be slowly but surely eroded.

Now rather that do a big write-up here about governance, I urge you to read Microsoft’s “Governance Checklist” found here. In your project plans, you should use this checklist and ensure you cover off all of the sections applicable to your SharePoint deployment. Additionally, when I wrote my ROI Series, I actually used the aforementioned governance checklist as the methodology to estimate project costs. You may find that post useful as a reference for your own project planning.

Conclusion

It is when you get to this part in the series, that you realise that you missed some important points in the previous posts. That is the nature of blogs I guess, since I post them as I write them. I think by the time this series is finished, I might release the overall content as a much more coherent and comprehensive whitepaper. Please let me know what you think about this idea and whether you’d pay a few bucks for it.

Part 5 was the longest post so far in this series, yet I still firmly believe that these topics are not the overriding reasons why SharePoint projects fail. Some of the topics covered here are simply symptoms of the fallout from a project that was wicked in the first place. So really, I believe that parts 1 to 4 of this series is where you will find most of your answers.

The next post is going to cover application development factors in terms of failed projects, which will be interesting, since I’m not really a developer, so I might miss a few things that are obvious to developers.

I’ll then follow that up with the end user factors.. after that it’s a little grey at this stage 🙂

I’m not sure how long it will take to get the next post out either, as the next couple of weeks are busy for me. In any event, if you have found this article or this series of articles useful, please let me know.

Later

Paul