Monthly Archives: May 2011

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

 

 

Top 10 Tips for Success with SharePoint: #2

Scope Management, Or…

Having made the decision to deploy (or maybe upgrade) SharePoint, done your due diligence and planned your project (see post #1 in this series), the next thing you need to do is scope your deployment and determine the functionality for implementation carefully, deliberately and preferably explicitly.  If the planning phase was effective this should be easy enough. You’ll know what you’re trying to achieve and why – I’ll assume you have clarified the vision or objectives – and project scope should come reasonably naturally out of that.

However, project scope can be fertile ground for growing assumptions, like sprouting mushrooms in the dark.  Being a little dogmatic up front, or at least very specific about what you’re delivering – and what you’re not – is usually a good policy, given an ounce of prevention is worth a pound of cure, as they say.  Your key stakeholders or Steering Committee members may have their own assumptions about what this SharePoint project is and what it will mean for their business.  Be as diplomatically pedantic as necessary to bring those assumptions to light and (also diplomatically) ring-fence any that are unachievable in the agreed timeframe and budget, or too great a tangent from core objectives.

For example:

  • If you’re doing a document management flavoured SharePoint deployment, are file disposition and archiving or formal records management also in or out?
  • Workflow is usually a big challenge in all sorts of ways that SharePoint may well expose but is unlikely to resolve on its own.  Is SharePoint being implemented to support business process improvement by, say, replacing time-consuming manual offline processes with efficient online workflows?  Then watch out for the implicit assumption that unclear or labyrinthine existing business processes, or lack of accountability, will somehow be resolved by the implementation (BPI/BPM is a different project, or at the very least a major workstream in itself).  Or the other one – that SharePoint will make Business Analysts out of every staff member and they will quickly grasp this new system and leverage its plethora of tools to transform their way of working
  • If you’re implementing an intranet on SharePoint, does your project scope also include sourcing / writing / reviewing / migrating content into intranet sites?
  • Are team sites in or out?  If in, what’s their core purpose and scope?  Does your Steering Committee, for example, assume that a team sites implementation will include extranet-type capability so external partners and suppliers can collaborate online with employees, whereas the project plan assumes otherwise?
  • If you’re upgrading from SharePoint 2007 to SharePoint 2010, is the objective a relatively straightforward version upgrade, or does the upgrade include re-assessment and restructure of the existing solution’s content, information architecture, etc.?

I raise these only to indicate that grey areas can proliferate, and unexamined assumptions can create plenty of room for scope creep or sometimes even all out scope wars down the track.  To avoid budget and schedule overruns, arguments and tears, discuss, agree and then document as specifically as possible what’s in scope and also what’s out of scope. Stick to this throughout delivery – anything that wasn’t included was presumably excluded for good reason, and should therefore be parked as a candidate for a later phase.

… Don’t Try to Boil the Ocean

Don't Boil the OceanSpeaking of phases, it’s a rare deployment that warrants or can afford serving up every piece of the SharePoint ‘pie’ (http://sharepoint.microsoft.com/en-us/product/capabilities/Pages/default.aspx) at first and at once.  Even if you did have the budget and were able to tick off every segment against burning business priorities, arguably it wouldn’t be a good idea to try, when you consider the user impact and adoption issues, not to mention increased risk of failure.  I imagine someone has come up with an equation that proves the likelihood of project success is inversely proportionate to its size and complexity.  It certainly holds true for SharePoint.  (For an excellent thesis on why SharePoint projects fail, see Paul Culmsee’s highly readable 8-parter that starts here: http://www.cleverworkarounds.com/2008/04/11/why-do-sharepoint-projects-fail-part-1/)

It’s also worth bearing in mind that rarely do people get as excited about a project that’s a highly qualified success, no matter how big or ambitious, as they do about a smaller project that’s an unalloyed triumph.  Which one do you want yours to be?

Once your project is in flight, be sure to manage scope rigorously and stay focused on the end game.   I admit this again sounds like basic Project Management and extremely obvious advice, but in the context of a SharePoint implementation scope management often seems to become particularly difficult.  I think this could be due to SharePoint’s embarrassment of riches in the capabilities department.   Despite (or possibly because of) that SharePoint ‘pie’, it can be difficult to explain to the uninitiated or a busy senior decision maker just what SharePoint is and can do.  (And, more importantly, what it can do in their specific situation and for their budget.)  And this can lead to misunderstandings about what “our SharePoint project” will deliver on Day 1.

But Don’t Just Boil the Kettle Either

Don't Just Boil the KettleBut – yes, another of my buts – don’t go overboard in the opposite direction and restrict scope, focus and functionality so much that you risk:

  • making the solution unappealing to or confusing for users
  • introducing ‘hidden’ costs by de-activating / hiding core features
  • locking yourself into a design (logical or physical) that won’t work for the business in future

You’re not just making a cup of tea here. Accept that SharePoint projects are usually fairly big the first time, and there are reasons for that (more of that in future posts).  You need to do a certain amount of base level work to establish a good foundation, even if you do have a tight focus on just one or two aims or outcomes initially.  And always think about future potential and the longer term roadmap when scoping a SharePoint deployment or upgrade project.   Be mindful that you may be designing and delivering what will be an initial solution or just the first phase of several projects that will build on the application’s strengths.

SharePoint is relatively conducive to phased delivery in some respects – conceptual ‘chunking’ of purpose, if you like – but in other ways it really doesn’t lend itself to modularization, in my view. Take just one example of several, the user Profile and My Site.  It’s easy enough to disable the private component of this SharePoint feature so that users are not equipped with a private document library and a workspace in which they can, amongst other things, manage web parts and create their own individual blog sites. And there are perfectly reasonable governance motives for choosing this approach.  The private My Site is quite easily enabled by your IT administrator if/when the organization is ready at some future point to train users, and support and govern this feature.  No consultants necessary. It’s not quite as simple a decision to disable the public Profile.  If you insist on this, as more than one of my clients has in the past (in order to replace the SharePoint Profile with employee profile information derived from alternate sources), you are choosing to excise a core element of the product and that, I think, is a dubious choice.  Profiles, for instance, augment information in SharePoint and enrich searches, and can add a great deal of contextual value to the user experience.   Further, if circumstances change and you want to repeal the alternative in favour of enabling SharePoint Profiles downstream you may also find, as did one client, that this makes for an unconvincing business case on its own and approval can be hard to come by.

Summing up:

  • Manage scope rigorously on SharePoint projects to help ensure success
  • It’s better to deliver a smaller, initial solution extremely well and build on success from there, than do an ordinary job on much bigger project
  • Start simple … but not too simple … and always think big picture

Top 10 Tips for Success with SharePoint: #1

Post #1 in the inevitable numbered series…
These will be just my opinions, of course but, for what it’s worth, they’re derived from years of observations on what’s worked and what hasn’t.  My lessons learned – sometimes bitterly – have come from working on or leading several real world SharePoint deployments. And also living with the results; I have done my time in an operational role as a Portal Manager on a SharePoint platform.
Not all my blogs will be like this, but this series will comprise quite long, discursive musings. You have been warned.   I’m a fan of cross-referencing, so if you persevere you’ll find links to other useful resources within.

 

It’s All in the Planning. Up To a Point.

Planning Makes Perfect

Don’t we all know the truism, or perhaps it’s a cliché:  if you fail to plan you plan to fail?  Ho hum you yawn, Project Management 101.  I’ll try to ensure the following isn’t wholly a variation on that well worn groove…

However, let’s begin at the beginning and focus on the importance of up-front planning before you embark on a SharePoint deployment, because it still needs reiterating.  I continue to advise and work with clients who want to “just get on with it”.  ‘It’ being implementing SharePoint to address [insert current problem here] or as the platform to replace [insert current broken application here] and fix all the company’s ills.  After all, it’s just a matter of installing the software, entering your licence key, doing a bit of configuration and away we go, right?  SharePoint pretty much runs itself.  How hard can it be!

Well unfortunately the answer is quite hard, quite often.  Also potentially quite expensive: even if your deployment is cheap and cheerful, the costs can mount downstream, when the brave new world of enterprise SharePoint turns out to be just as messy and difficult to manage as the problem it was originally going to fix.  

(I’m not going to open Pandora’s Box on the first and arguably most important task – determining whether SharePoint’s the right tool for the business need or problem. You can find plenty on that topic in the blogosphere, and this is a series on tips for achieving success with SharePoint after all, so we’re going to take proper evaluation and selection as a given.)

I advocate sound project planning for a SharePoint deployment; so far so obvious.  Next, please ensure the solution is designed for your organisation, not in accordance with some best practice ideal. You must understand and plan the implementation around your:

  • Priority requirements and pain points
    Are these the same thing?  Are you scoping the project to meet requirements but not addressing the real areas of pain in the business? Spotting ‘quick wins’ in the planning process and delivering on those on Day 1 will support user perceptions of success and help drive adoption.
  • Business practice
    Are organisational processes reasonably homogenous or are there many disparate units with differing needs and styles?  While SharePoint may be able to serve them all in theory, addressing widely different requirements and expectations can grow deployment cost and complexity. Scope will need to be carefully defined, or successful delivery could be compromised.
  • Organisation culture and user profile
    Are staff change ready or averse, and to what degree?  What’s the overall level of technical competence?  Is the organisation reasonably homogenous or are there many disparate units with differing needs and styles?  Be aware that SharePoint isn’t particularly intuitive for many people, and widely different needs and expectations can grow deployment cost and complexity. The answers to these questions can help inform decision making on change management planning and budgeting.
  • Technology landscape– e.g. current Office version, data storage capacity, complementary / competing systems, upgrade of a previous version or ‘greenfields’ deployment – and IT roadmap – e.g. on-premise or cloud hosting.
    How SharePoint is expected to fit into the bigger IT picture could rule some deployment scenarios in or out.
  • Software edition and core focus
    Are you deploying the SharePoint Foundation or SharePoint Server. If the latter, Standard or Enterprise editions?  Each will present you with certain planning and design choices.  (You can find a nifty editions comparison at http://sharepoint.microsoft.com/en-us/buy/pages/editions-comparison.aspx
    Is the core focus of your implementation internal (e.g. intranet or team collaboration environment), extranet or external (e.g. a website)?  Communication or collaboration orientated? If you answer “all of the above” be prepared for a huge project.
  • Deployment methodology
    Should you start with a pilot?  If so, how will you define and constrain that pilot? Will a staged rollout work best for you, or a big-bang deployment?
  • Budget
    Working within financial limits is a reality. But it’s important to be feasible – is the budget proposed really sufficient for an enterprise SharePoint project?  Just because you have an Enterprise EA does notmean SharePoint is free.
  • Environmental constraints
    Identify your specific risks and issues up front as far as possible. What factors might derail or compromise a SharePoint deployment and what can you do to mitigate these when planning the project?
  • And other specific circumstances – e.g. level of in-house technical and business skill available to the project, ongoing availability of administrative resources, etc.
    Do you need to engage external assistance or can you go it alone – for the whole or part of the project?

 

SharePoint Planning Resources

If you’re casting around for planning assistance…

Microsoft has done a laudable job in providing myriad Resource Centers to help with detailed planning of various aspects of the sprawling feature giant that is SharePoint 2010: http://technet.microsoft.com/en-us/sharepoint/ff465365  They’re pretty good, up to a point.

A cautionary note: be careful to interpret this material through your own filter and be aware that SharePoint best practice advice is sometimes an ideal and occasionally idealistic. It doesn’t always reflect SharePoint as just one part – however integral – of an organisation’s information ecosystem, or acknowledge that many companies struggle to maintain consistent, effective enterprise wide business processes.  For example, in the real world SharePoint users may simply not use Content Types (there’s a fascinating discussion on the promise and power versus dismal adoption of Content Types archived at http://www.endusersharepoint.com/2010/11/29/sharepoint-content-types-is-this-a-lost-cause/ to support this point).  They may not use My Site as predicted or the way you want them to.  And best laid plans may slowly go awry.

In my view, the Resource Centers can also sometimes become far too IT and product centric.  A small example: recommended governance roles & rules are synonymous with SharePoint roles & rules – very rarely meaningful to non-IT folk or senior stakeholders.

The SharePoint Help and How-To site within Microsoft Office’s vast online reference is also useful. While it won’t necessarily explicitly aid planning, it does offer more of a day-to-day SharePoint how and why that’s a worthwhile adjunct to the Resource Centers’ strategic / conceptual approach. See: http://office.microsoft.com/en-us/sharepoint-server-help/sharepoint-server-help-and-how-to-FX101834344.aspx

One of my favourite resources on SharePoint planning is provided by Paul Culmsee at http://www.cleverworkarounds.com/  – look for his Planning, Governance and Assurance series of posts.  (Also the Return on Investment series, if you’re still at business case stage – the multipart Learn to talk to your CFO in their language is pure gold: http://www.cleverworkarounds.com/2007/11/17/learn-to-talk-to-your-cfo-in-their-language-part-1/)

Up To A Point?

Right, onto that little caveat in the heading of this post. Having exhorted you to plan diligently and in detail, I’m now going to qualify that advice and hopefully not appear contradictory.

According to the principle of diminishing returns, eventually planning and yet more planning ceases to equate to project success and yet more project success. It becomes analysis paralysis, producing little or no return.

Having read some of the reference material out there you might think, for example, that you simply cannot move ahead with your SharePoint build and configuration until you have a detailed design document recording your enterprise’s entire suite of Content Types, Permission Levels, Term Sets, etc.  Or perhaps not until you’ve created use cases and identified actors for every dimension of a content approval process.  Not so.

On and Off the Page – Planning versus Reality

One of SharePoint’s strengths is, I think, its flexibility. You can quite easily move constituent parts around and tweak various elements on the fly.  Up to a point, again – sure, you need to be somewhat wary of burnt bridges, and once you’re a way down the implementation highway it can be time-consuming and costly to turn back and embark on a different route.

But I think we should leverage the application’s inherent flexibility much more during the planning and initial design process.  This is the point at which “just get on with it” has a valid place.  Let me explain…

I’ve learned from experience you can go through a user-centred design process by the book, for example, to arrive at an ‘evidence-based’ site structure and Information Architecture that everyone would agree, I’m sure, is empirically sound and exactly what is required.  Only to find the minute the IA moves off the page into a real world deployment it just doesn’t seem to work, and considerable adjustment to that carefully planned structure and hierarchy of sites and subsites, pages and document libraries is necessary.

I’ve observed analysts liaise tirelessly with a business team on their process for doing XYZ, produce exemplary flow charts and achieve sign off, then faithfully reproduce the workflow in SharePoint … only to find that it’s not really what the team imagined / wanted / can use after all.  Paul Culmsee blogs insightfully at much greater length on this at http://www.cleverworkarounds.com/2010/12/02/sharepoint-analystsstop-analysing/ if you’re inclined to explore this further.

Try to avoid making the mistake of too much planning. It wastes precious time and effort.  When planning falls short of reality it can make stakeholders nervous and can unfairly start to erode confidence in SharePoint or the project.

Prove It

I highly recommend building a rough and ready POC (Proof of Concept) environment, as early as possible in the planning process.  In a week or so, or less – depending on the number and complexity of concepts you want to prove with SharePoint – you can run up a server and build a very effective little demonstration and prototyping platform.

Recently, we built a fully-functional SharePoint 2010 POC for a client, in a standalone test environment, integrated with Active Directory, Office 2010, Lync, Exchange 2010 and Dynamics CRM.  I configured a couple of site collections and a handful of sites, libraries and lists, with a reasonably detailed enterprise term set provided by the client, plus a Search Centre and My Sites. This is allowing our client to thoroughly test many aspects of the SharePoint feature set.  They’ll have a much better understanding of the product’s strengths and weaknesses in the context of their actual business processes, and their implementation project should be better planned and more successfully delivered as a result.  At the very least, they will be making decisions with hands-on knowledge that no amount of reading – or even advice from yours truly – can match.

Summing up:

  • Planning a SharePoint project – thoroughly, carefully and in detail – is essential
  •  Design your solution for your specific circumstances.  Don’t get caught up chasing a best practice ideal (unless it really is best for your organisation).
  • Recognise when enough planning is enough, get ‘off the page’ and prototype live in SharePoint

The Vue from Chamonix

Hi, welcome to Chamonix’s company blog. Our name’s French (pronounced ‘sharmonee’), but we’re an Australian IT consulting business.  Read more about us if you like at www.chamonix.com.au.

Our expert consultants are highly experienced in all aspects of implementing enterprise IT systems and applications, on-premise and cloud-based, from project management, to systems integration and application development, to change management and user adoption.

From time to time we’ll share our views and insights on our various fields here.

Thanks for reading,
Chamonix IT Consulting