Don’t Try to Shoehorn SharePoint
I’ve noticed some people seem to become a little disappointed with SharePoint over time. Eventually or quickly, during evaluation or post-implementation, one way or another they start focusing on limitations not strengths, become jaded about the SharePointy way it does things or the things it doesn’t do, or maybe they let the dawning realization that it’s not going to be the silver bullet that will eradicate their burning (people-related) business problem get them down. I don’t know if this disillusionment can arise due to lack of knowledge, poor initial understanding or advice, consultant / Microsoft marketing promise versus the cold-light-of-day reality …
… whatever the cause, it can lead to tweaks, customisations, development and enhancement that collectively result in a SharePoint extreme makeover.
And this is the basis for my success tip #3 which boils down to getting to know SharePoint as well as possible, and evaluating, selecting or working with the platform as it is, warts and all. Avoid shoehorning SharePoint into something it isn’t. Possibly it was never intended to be what you want it to be. It’s not SharePoint, it’s you
Extreme Makeovers = Extreme Pain
In all seriousness, I would advise anyone to resist the temptation to customise SharePoint heavily, or add on third party products to make it into the system you think it should be, or – the worst variation on this theme – force SharePoint into becoming a mirror image of the system you’re currently used to. Believe me, people do try. I wonder why they selected SharePoint in the first place.
For example: if you don’t really approve of usability in SharePoint, I respectfully suggest you evaluate another product. (I’m not talking so much here about a SharePoint public website’s UX, as in that scenario you generally don’t expose the administration elements required in internally-focused deployments, but rather SharePoint for document management or internal collaboration or intranet publishing.) Of course you should give some thought to the navigation experience, particularly if you’re deploying multiple Site Collections and a Search Centre, otherwise users can become stranded in a location with no apparent way home. And there are plenty of options for designing your own brand that you can explore – see this post for just some examples http://www.steptwo.com.au/columntwo/make-sharepoint-intranets-beautiful/. But fundamentally, task-based UX in SharePoint is what it is, and you should not attempt to shoehorn it into a different model.
Serious risks associated with the shoehorn approach include:
- High deployment (and potentially licensing) costs
- Usually very high TCO (Total Cost of Ownership) over the long term
- Compromising updates (e.g. Service Packs have been known to ‘take out’ customisations) or complicating the upgrade path when the next version is released
- The Frankenstein Effect or Robot Barbie
Sometimes, yes, I accept that customisation/extension is warranted. When it’s the ingredient that will elevate a dish your diners (business users) find barely edible to one they find irresistibly appetizing. Microsoft certainly promotes SharePoint as highly extensible platform, and the 2010 version is designed to be more attractive to the developer community, with Visual Studio integration, Windows Powershell, etc. I’m fortunate to work with some extremely clever and talented developers at Chamonix, and our sister company Kloud, and get to see the compelling solutions they’re building for clients in SharePoint. There is a right way and a wrong way to develop and enhance SharePoint, so make sure you choose the right path or customise in haste, repent at leisure. Anyone who is facing a problematic upgrade from 2007 to 2010 due to zealous customisation in the past would surely urge you to learn from their mistakes and protect your upgrade path vigilantly. Having critiqued the lore of ‘best practice’ in an earlier post, I shall now inconsistently exhort you to follow Microsoft best practice guidance on SharePoint development at http://msdn.microsoft.com/en-us/sharepoint/ff660756.
Alternatively, if you’re considering integrating a commercially available third party plug-in, do your due diligence and ensure it the product is not intrusive and will not cause performance, security or other problems in the longer term. If you have no idea what I’m talking about, get independent assistance and evaluation.
Some Cocktails are Toxic
Okay, that heading’s pure hyperbole, but I just wanted to catch your eye for one final point to finish up this post. I’m challenging the notion, spruiked by many vendors, that SharePoint is endlessly and easily ‘connectable’. Or happily coexists with everything else you might be running in your organisation today either straight out of the box, or with just a smidge of customisation. Be cautious when adding SharePoint to a complex or crowded applications landscape.
From painful experience, I would say beware the SharePoint ‘connectors’ that so many vendors of alternative enterprise solutions seem to be spruiking these days. They’re often clunky in practice and – my biggest criticism – necessitate a high level of awareness, conscious thought and deliberate action on the part of end users about why, when and how to use their company’s SharePoint solution versus everything else on offer. Most business people are busy just trying to get their work done and meet their KPIs, and really don’t want to have to think about what type of content they’ve created and where and how it should be saved or published. And, quite frankly, they probably shouldn’t have to (a shout out to one of the best reads available on user experience, Steve Krug’s Don’t Make Me Think).
Sure, SharePoint does some things merely adequately. There are ‘best of breed’ alternatives – let’s call them BoBs – to some of SharePoint’s capabilities that might win a functionality face-off. But if you’re going to deploy a BoB or two and expect they will “just work” and coexist harmoniously alongside SharePoint, I suggest you watch out for a rarely acknowledged but common enough outcome: when SharePoint and BoBs start to fight over shared territory in users hearts and minds you may end up with a very ordinary enterprise solution in practice.
For example, some organisations’ information management strategies seem to align with their technology landscape something like this: “SharePoint for the Intranet, Confluence for Collaboration, Documentum for Document & Records Management, Jive Engage for Social Networking, etc. (Feel free to swap out the product names with those of your experience.) SharePoint 2010 now overlaps functionally to a very considerable degree with many of these products and fights do seem to arise as a result. I might agree, for example, that Jive Engage beats SharePoint in the category of usability: as Jive doesn’t intend (yet) for Engage to be an enterprise intranet platform or document management system, ipso facto does it make for an all-round better solution to give your user base Engage and SharePoint? I disagree with that. The BoB’s not the salient point of this example, I’m just suggesting that your users may be confused rather than empowered by certain choices. And will undoubtedly be frustrated by clunky connectors. Anticipate they won’t figure out when to use one application or the other, nor understand why they should. Expect they will display a marked preference for one over the other (whichever has the lowest barrier to entry), and will probably try to use that one exclusively.
I’m not saying coexistence can’t be done, or shouldn’t be done. Where you already have multiple legacy systems in place it has to be done and then of course you’re wise to keep the conceptual distinctions between systems as clean and clear as possible. Just don’t go ahead blindly or blithely, and do amp up your Change Management and Communications efforts exponentially. Try to anticipate user issues and design the best user experience across multiple systems that you can. Or your SharePoint deployment could gather dust.
- Enjoy SharePoint for all it is, and accept it for all it’s not … unless it fails to meet a core business need in a particular area, in which case…
- Enhance your SharePoint solution judiciously
- Keep customization to a minimum and adhere to Microsoft ‘best practice’ in any development activity
- Manage coexistence between SharePoint and other enterprise systems sensibly and focus on the user experience and user education for best outcomes
U P D A T E:
Was recently alerted to these useful posts, courtesy of an EUSP article, which help clarify the vexed topic of SharePoint customisation and distinguish between customisation and development: