Category Archives: Business analysis and systems selection

Top 10 Tips for Success with SharePoint: #5

Don’t Expect Miracles

This tip is short and sour: don’t transfer your existing problems from one environment to SharePoint and expect miracles – there is no silver bullet.

Try to use a SharePoint 2010 implementation or upgrade project as an opportunity to:

  • Challenge work practices or processes that clearly aren’t working for the business, and make adjustments or eliminate them
  • Introduce new ways of working better, faster, smarter – e.g. try moving time-consuming manual, paper-based processes online, reducing touch points and hard copies
  • Identify key limitations of any technologies being replaced, and figure out how SharePoint overcomes them (if it can’t, then manage expectations)

That list’s not particularly easy to achieve I grant you, but you should be embracing Change Management anyway when deploying SharePoint (particularly if you’re upgrading), so add the above to your strategy and tactics. More on that fun topic in an upcoming post.

The self-help books are right:  run away from yourself and you’ll just take the problems you’re trying to escape with you wherever you go.

In other words, if your business has issues today, you could spend time and money replacing the underlying technology only to find the same old problems simply manifest tomorrow, in the expensive new solution.

It’s not SharePoint, it’s you 🙂

Are You Really Fixing Things with SharePoint?

…YES

A while ago I worked on a project to replace an existing EDMS with SharePoint. Facilitated by the system, employees had developed a deeply ingrained practice of securing access to each and every document in the system individually.  Very few documents were viewable by all staff.  Item-level or fine-grained permission setting came up over and over again in requirements workshops as mandatory for the new SharePoint-based DM system.  Why? No-one could fully argue the case, beyond reiterating that it was “extremely important”.  Even as they also acknowledged the practice had become a maintenance headache and too many documents were effectively ‘lost’ due to over-enthusiastic application of permissions.

The clever clients recognized the chance that the SharePoint implementation provided and grabbed it with both hands.  Kudos to them for having the courage and foresight to challenge a mandatory business requirement.  They used the deployment of SharePoint – which, by the way, doesn’t particularly like fine-grained permissions, and if you pursue that too comprehensively you will pay the price in the long run – as a golden opportunity to change a habit that was not enabling the business.  With SharePoint’s introduction came a new enterprise policy, in which all documents were to be viewable by all staff by default, with further security applied if required by exception only (and in a manner more suited to SharePoint).  Yes, the transition was difficult and yes, there were complaints initially. But the sky didn’t fall in, the tide slowly turned and broad-based document access became accepted; and with it the potential for improved information exchange and knowledge-sharing across the company.

Very recently another business I assisted decided the time had come to move away from its near-complete dependency on Excel, PowerPoint, Word and email messages for communication and collaboration, due to quite extreme problems with duplication and version control, and very poorly informed employees. They worked hard to build user-centric web content management into their SharePoint deployment.  Out went a handful of old intranet pages that comprised little more than vast columns of hyperlinks to PDFs, and in came news feeds, publishing sites, lists (see post #4 in praise of lists), blogs and wikis.  Even their policy PDFs and their SharePoint governance framework were re-created as Enterprise Wikis.

…NO

Conversely, another client took a widely disliked, manual, multi-stage and confusing procurement and approval process, and insisted on recreating it as an online SharePoint workflow exactly as it had been offline.  In refusing to address the underlying issues staff had with the process, they missed the opportunity to re-work and improve it – and they didn’t assist user acceptance for SharePoint much along the way.

I’ve worked with many organisations that, in feeling the pain of a sprawling mess of a file server, with terabytes cryptically named files scattered around in thousands of folders, have decided SharePoint is the cure to what ails them.   Some of these workplaces have not previously seen the value of ‘overheads’ like naming conventions and modest filing / archiving guidelines, nor the need for sustained user education on acceptable practice.  And yet they continue to remain sceptical about the need for such things with the introduction of SharePoint.  Or perhaps it’s just deemed too expensive and therefore relegated to ‘nice to have’. But isn’t this skimming a little too close for comfort to Einstein’s definition of insanity?

Michael Sampson, a collaboration specialist, has been warning against ‘silver bullet’ thinking for a long time.  He shares his many valuable insights into making collaboration work, plus his research findings and lessons learned on a huge range of technologies, including SharePoint, at http://currents.michaelsampson.net/.   I’ve enjoyed robust discussions with Michael over the years, and have learned a great deal vicariously from his observations on the highs and lows of Lotus Notes in the enterprise.  If you’re working with SharePoint, I’d encourage you to look up his work.

Sorry about that, sunnier tips coming right up.

Summing up:

  • SharePoint is not and never will be the silver bullet that fixes poor business practices
  • So don’t do the same thing over again and expect different results

Top 10 Tips for Success with SharePoint: #3

Don’t Try to Shoehorn SharePoint

Love the one you’re with

Don't Try to Shoehorn SharePointI’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.

Summing up:

  • 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:

Lori Gowin: http://www.pointgowin.com/SeeThePoint/Lists/Posts/Post.aspx?ID=22

Jeremy Thake: http://wss.made4the.net/archive/2008/11/25/where-to-draw-the-line-between-sharepoint-customisation-and-sharepoint-development.aspx