When you get around on a few SharePoint projects you tend to hear a lot of pre-conceptions, attitudes, and plain old wrongheadedness around what SharePoint is and does. Collected below are my personal favourite ten of these, which believe me I've heard more than once.
1. Install And Forget
Not only is this the most common one, this is also my favourite, or least favourite depending how you look at it. ;)
The thought processes seem to play out like this;
"So, SharePoint is a Microsoft product right? The marketing material made it look so simple. It's basically like Microsoft Office then huh? Cool, OK let's put the money down for the initial install and configuration, put it in front of our users, and forget about it. Next time we need to mention it will be in the Company Annual Statements where we revel in how we increased business productivity 300%... "
Mmm yeah, not my experience in the real world it has to be said. Microsoft SharePoint is NOT Microsoft Office on so many levels. SharePoint is a major league business tool that has the potential to completely change how your people do their daily jobs. Therein lies the problem. For a start your people might not want to change how they do their daily jobs. They certainly dont if it seems like things are suddenly harder to do than before - unless the payback for any extra effort is pointed out.
Put SharePoint in front of your folks and forget about it, and they will do whatever they can to continue working as before. Without an End-User adoption strategy to provide training, support, sticks and carrots, and basically demonstrate what is in it for them you are heading for failure. At best they'll limp along using the high level features and not gaining any of the return on investment that was expected on the implementation, at worst your folks will shun SharePoint as if it were a rabid dog.
End user adoption is not the main thrust of this article, so let me leave it with a soundbite; "explain to your people what you are achieving by adopting SharePoint and train, train, train!".
Adoption isn't even the only reason you can't install and forget. For example you likely considered the powerful Enterprise Search features were worth having when you evaluated the product? To get the best out of Search it needs to be tuned as it becomes clear through Search Keywords and surveys what your people actually want to find. It needs to be adapted as your organisations information silos go from Terabytes to Petabytes and beyond.
Also consider the potential for custom workflows, Business Intelligence, Document retention policies to meet your legal obligations. Not the only topics by any means, but worthy of thought.
Time for an anecdote - I once did a project in a major retailer. They told me from day one that SharePoint Search sucked and I was not to talk about it in a positive way in their presence! When I was allowed onto their server I immediately discovered that the account they'd set up for the Search Crawler had expired some months before, and nothing new had been crawled since then. Install and forget huh? :)
The Three Nos;
2. No 3rd party apps
"We paid for SharePoint so it should do it all, no way are we paying for any extra applications"
When Microsoft put together all the iterations of SharePoint I've worked with it's pretty evident to me that they realised they couldn't cover every possible base. The product could be feature rich sure, but was it really going to be able to nail every possible angle for every adopter r.e. backup, security management, web analytics, content translation to name a few? Nope. If they were expected to meet all those extras on top of the core product there'd be a ten year release cycle and the product would be obsolete five years before it was even released.
So a rich ecosystem of third party vendors has grown up around SharePoint to fill in the gaps. As an organisation you get the choice of what you want to implement in terms of specialisation, cost and complexity. If you don't like the out of the box web analytics you can implement the free version of Google Analytics in about half an hour. Not good enough? Get the corporate wallet out and pay for WebTrends. Everyones a winner, including the third party vendors.
As a rider to this issue I often see organisations task their developers to write functionality or tools that can be bought for a tenth of the cost of writing them inhouse. Once again puzzling, expecially if the vendor is willing to sell you the source code hence ensuring you can support the product if necessary.
3. No SharePoint Designer
"SharePoint Designer is powerful and dangerous therefore should not be allowed anywhere in the organisation"
I've taught a few classes recently where in the act of teaching absolute beginners about SPD it's opened my eyes to how empowering the 2010 version of the product is to users. The workflow authoring process is a lot better than in 2007, but that's just the beginning. How about the fact my users can create their own KPIs by editing an XSLT listview? No XSLT is ever seen, it's intuitive as heck (if you get pointed to the right place initially!). List creation, permissions management, styling of pages, I'm not even pretending to put an exhaustive list here.
The fact is you can't afford an outright ban on SPD. The ethos behind SharePoint is that end users are empowered to make the tool work for them. Ban SPD and one of the main planks holding that ethos up has just been kicked out. The key is education and responsibility. Train users that will find SPD useful so they know how to use the tool, and what to avoid. Have governance in place that assigns rights and responsibilities. If a user knowlingly breaks the rules and brings down the production system, there's a procedure for that and everyone knows it. You don't have to give universal access to SPD, Power Users are fine. Just make sure they get trained, or you're suffering from the "Install and Forget" syndrome detailed above.
4. No custom code
"Custom code is expensive / Is a Block to future Product Upgrades / Causes Support Headaches"
I have some sympathy with this one. Bad customizations can indeed lead to support headaches, outages, and painful upgrades. This is something that needs to be managed, and processes in place to mitigate impact.
However the 100% blocks to custom development can be maddening. I try to shoot for non code solutions wherever possible, but the reality is that some requirements can only be met through custom code. For example I spent some time last summer trying to implement Column Level Permissions on a list without custom code. It's not supported by SharePoint out of the box, but custom code was not allowed. I managed to put something in place that did the job, but frankly custom code would have been neater and quicker from the outset.
One of the functions of my job is to warn clients off the most expensive and troublesome approaches to solutions. Sometimes I feel like a car mechanic - whistling, shaking my head slowly and saying "It's gonna cost you mate!". Like it or not, sometimes I'm going to say that custom code is by far the best option, and blanket bans are not good for any party involved.
5. Graphics Heaven
To be honest this was more a bugbear of mine with MOSS 2007 than SP 2010, but it goes like this;
"SharePoint is cool, therefore it can display anything any way without effort"
If a product is cool it's gotta be graphically amazing out of the box. OK, I've heard that one quite often, and I must admit that what looks nice is often valued more highly than what actually works. As a technologist this drives me crazy, but it's the Realpolitik. The graphical expectations weren't always easy to meet in MOSS 2007, and believe me I sweated over it.
In SP 2010 things are much better. We have lightbox type dialogs, ajax, silverlight, and yummy stuff like Visio Services which allow the rich interactive diagrams. My life is easier in this department than it used to be...
6. Magic Fix For All Issues
"SharePoint Can Solve Anything"
Ever get the impression a marketing division has done its job too well? One particular example of this still gives me chills.
A multi-billion dollar organisation is implementing an end to end replacement of all their legacy systems. They have brought in the consultants from a household name IT provider, and are buying the packages that provider sells. However, there are gaps between the packages, so after an afternoon on Bing our old friend SharePoint is chosen to fill in those process gaps. I'm sat in the analysis workshops detailing the business processes and make a startling observation - SharePoint is not suitable for what they want to do AT ALL!! I then proceed to work on them over a period of about two months to get them to implement SharePoint in a way where it can actually help, and in the end thankfully they leave some of their legacy processing in place so their business doesn't collapse after the new multi-million dollar system revamp is released. Phew.
What was the problem? It was having no understanding of what SharePoint is or can actually do. It was simply cool, hip, and showed up in the search results when they typed "Middleware" (which it shouldn't have done).
This is one of those topics I could name a zillion examples of what SharePoint can apparently solve according to X, but I think you get the message so I'll leave it. :)
7. Install Because Everyone Else Is
This is kinda related to the Magic Fix issue. "If SharePoint is hot, hip, trendy and yet also cool (surely the laws of thermodynamics are breached by such statements?) I don't need to understand what it can do for me. Company X is installing it, so we should too. Not like those guys to make a bad call."
In the final analysis I make a living out of putting in IT systems that increase the productivity of organisations (not necessarily profit though... many of my local orgs in Geneva are non-profit!!). If I'm party to putting in systems that dont benefit the organisation at all I'm breaking the covenant. Eventually through tarnished reputation, lower investments due to a clients weaker financial performance, or plain old Karma I'd be out of a job. Therefore I do not encourage anyone to use SharePoint unless they have a clear picture of what it can do for them and how. Maybe it is suitable, but if unsure get some reputable professionals in for advice. (Always always sniff any provider out to make sure they're not the type who sell solutions at any cost. Some sales guys act like they're really hungry, and it does no-one any good.)
8. One Feature Usage
"We need a Web Content Management system. SharePoint does that so let's get SharePoint"
Even if you get the licenses for free (as many orgs do) SharePoint is expensive. Hardware, hosting, consulting, training, adapting to new working methods. I encourage everyone to get their fair bang for the buck. SharePoint is not a single feature product. It aims to meet 80% of the regular requirements of several products spanning Enterprise Content Management, Business Intelligence, Search (etc etc). If you genuinely only need a Web Content Management system and nothing else, consider getting a specialised Web Content Management system. It may be cheaper, and will probably be 100% suited to what you want to achieve, rather than 80% suitable.
On the flip side, please dont complain that SharePoint isn't as good as Documentum. That might be true for Document Management, but it's good enough for most customers and includes a lot more coverage for other functions besides. It's like saying a Swiss Army Knife isn't as good at cutting wood as a Tenon Saw - have you ever tried opening canned food with a Tenon Saw while you're on a camping holiday? - It gets messy real quick...
9. 100% Requirement Compliance Or Bust
SharePoint often puts me in the strange position where I'm constantly explaining to the client that the functionality he thought would take a week will be ready in five minutes, but the small change will take until next Fall. The more experience of the product you get, the more you know where these gotchas are. Much of my job is telling people what is easy and what is hard in the real world of implementation.
One thing I find a little mystifying is the complete intransigence on requirements. Don't get me wrong - requirements are king. If the business folk decide that a certain message wording is likely to make a customer a customer for life they are much more expert on that than I. However when for instance I have to explain that a button needs to be on the left side of a pane, because if we put it on the right we have to completely re-write out of the box functionality and spend five days implementation instead of five minutes perhaps a little compromise is cost effective and wise. That said - I will raise it, perhaps several times, but once the decision is made I'll just do it. Customer gets what customer wants, and this is as it should be.
10. It Sucks Because It Doesn't Work The Way I Think It Should
Just last week someone was telling me how much SharePoint Variations suck. [A debate for another time perhaps.] His reasoning was that because he had to click through to a new page to see translated content rather than being able to switch the text on a single page therefore ipso facto everything sucked. It was a heinous crime indeed to suggest we did a multi-lingual site in such a way.
Elsewhere on this blog (here) I've spouted at length about whether Variations do indeed suck, and I believe the viewpoint I ended with was that multi-lingual sites are a tougher business problem than you might casually think and variations were a reasonable but imperfect stab at a solution.
But let's not get hung up on one feature. Someone might say that the SP 2010 Social Features suck. If someone comments on your profile, replying to that comment isn't as easy as it should be. Discussion Boards - kinda useful but lacking some essential features especially around comment moderation. Wikis - why is it so hard to export the content offline?
These are valid concerns, and Microsoft should be made aware of them through the normal channels. They do seem to listen to feedback on their products, well certainly not 100% but more than you might think! :) (one example here)
If it doesn't work the way you think it should the choice is stark; wait for the next fixed release, buy something that does it better, or get coding.
Does it suck? Maybe, who knows, everyone has an opinion. Decide on cost and time if it's worth living with it or changing it. End of.
One last point to consider - if Variations had been perfect I'd have probably never started blogging. An extra grudge to hold against them? ;)