The other day I was talking to one of my clients and I was trying to explain what SharePoint is exactly and why projects delivering them tend to fail. Like most others, they had been sold on the collaborative power that SharePoint introduces into an organisation and how it was the be all and end all of online delivery of content, collaboration, business intelligence, search etc. After a little search in my head for the best analogy I could think of, I settled on comparing it to a fisherman’s tackle box.
When I was much younger my dad bought this fantastic fishing tackle box. It’s one of those boxes that when you pulled back the lid there would be all these multilevel compartments that could be folded out and had millions of little drawers to hold all kinds of different fishing tackle. My dad had filled it up with all kinds of different hooks, sinkers, floaters, leaders, etc. By having everything at our disposal it meant that we would be prepared for any fishing environment.
Now just because we had purchased a complete kit with all the equipment any fishing pro would have at his disposal did not make everyone in my family a pro. In most cases I had no clue what the thing did or when or how it should even be used. Context is a major part of fishing, just like in a SharePoint project. Knowing what the functional use for the accessory is does not mean you know the environment or situation in which to use it. For example, can you have a guess as to what the following equipment is and when it’s typically used?
If you didn’t manage to guess it, its a fish bite alarm. To some this may seem pointless because you’d be asking the question “wouldn’t you know that you have a fish by the fact its trying to rip the rod out of your line?” and you’d be correct in some circumstances but there are times when you may have multiple lines or the kind of fish you’re fishing for requires a more subtle technique meaning the bite is quite hard to detect without some kind of aid. SharePoint is no different; there is a time and a place for all its components.
When you install SharePoint, you aren’t installing a tool with the knowledge and wisdom of a thousand grey haired developers. What you’re installing is a tool of immeasurable pain toolbox of components commonly used in the development of a variety of web based applications. Just like fishing, we need to know the environment we’re in. We need to know whether it is an intranet site, internet site, collaborative portal, document management portal, or records management portal (just to mention a few) that we’re building. We also need to have an understanding of the IT / businesses processes and procedures in place as these are likely to affect the kinds of solutions and the paths we choose for customisation.
Judging the success/failure of a SharePoint project is also much like fishing, we judge it on the level of user engagement we attract. The less user engagement, the more likely we’ve totally missed the needs of the business. The more we understand the business needs as the business views it (I’m glaring at those developers who think they know the business better than the business knows itself) before we undertake the development of the project then the higher level of user engagement we’ll receive.
The ultimate point in all of this is that SharePoint alone won’t get the level of user engagement sought after by organisations. There is a level of maturity and understanding required by implementers around both the needs of the business and the business goals that are to be achieved. These need to be understood long before you decide upon SharePoint as the platform. It’s for this reason that many SharePoint projects fail. SharePoint can deliver on the promises of collaboration, portal, business intelligence, business processes, content management, and search. What it can’t deliver and doesn’t promise to deliver is that these tools will be used properly by the SharePoint ‘fisherman’ and that any users will be successfully ‘caught’.