Deft Design Delivers Dividends!
Part B of a two-parter that starts here at Part A.
Yeah, about time we had a heading with some groan-worthy alliteration.
My next tip for success with SharePoint is a deceptively simple one. While accepting that SharePoint has its weaknesses, success accrues from deliberately playing to the application’s many strengths. Well d’uh, I hear some of you say. Bear with me – my point is acceptable I think, because many deployments I’ve seen simply don’t do this. They do the obvious – for example, “we’ve installed Team Sites for collaboration” or “we’ve rolled out SharePoint for document management” – but usually they haven’t moved far beyond this and found ways to leverage the platform’s strengths to truly make SharePoint a great fit for their environment.
So what are these strengths? Well, they’ll differ from place to place: what’s a product strength to one SharePoint manager might leave the next indifferent. My list of SharePoint’s best attributes may not be yours but, having got that qualification out of the way, here’s what I think are some of its greatest assets.
My absolute favourite feature of SharePoint has always been, might just always be, Lists. They are incredible. IMHO, they can offer a great deal of value-add in many business information scenarios.
SharePoint Lists are…
List Views are…
Since Lists are very similar to Excel, and most organisations I’ve worked with appear to just about run on Excel, I’m not sure why it can be so hard for SharePoint administrators to translate the List concept into business usage – and value – in practice. I’ve always found that putting in a bit of up-front effort to resolve common business issues by building a simple List solution or two is an extremely powerful way of demonstrating SharePoint’s business value. And of encouraging staff to think laterally about exploiting Lists for their own circumstances. Here are some very simple examples that have worked well for clients in the past:
Learn more about 2010 Lists on the Microsoft SharePoint Help & How To site: start with this great overview http://office.microsoft.com/en-us/sharepoint-server-help/introduction-to-lists-HA101782476.aspx and a number of introductory videos, commencing here: http://office.microsoft.com/en-us/sharepoint-server-help/sharepoint-lists-i-an-introduction-RZ101820091.aspx
Little tip – it can be hard for end users to orientate themselves quickly in different List views so, for every List and every View I create, I like to modify the web part’s appearance, in order to make a meaningful title visible on the page. Step by step instructions here…
My enthusiasm for the following out of the box is a little more qualified, but still quite high:
As an information management specialist who spends her working life thinking about content structure, usability, findability (what a word), etc, I really like this impressive new feature of the 2010 version for so many reasons.
As always, you can find extensive detail from Microsoft, though I think Chris O’Brien’s overview is a great introduction to the subject: http://www.sharepointnutsandbolts.com/2009/12/managed-metadata-in-sharepoint-2010-key.html See also: http://office.microsoft.com/en-us/sharepoint-server-help/introduction-to-managed-metadata-in-sharepoint-server-2010-HA101859256.aspx and don’t forget the Managed Metadata and Taxonomy Resource Center: http://technet.microsoft.com/en-au/sharepoint/ff924923.aspx
Sadly, there are a few gotchas with Managed Metadata in the context of some other SharePoint features. Thanks Paul Culmsee for such a good write-up there’s no point doing anything but cross-referencing his findings: http://www.cleverworkarounds.com/2010/10/28/un-managed-metadata-a-couple-of-gotchas/ Michal Pisarek has also collated several other issues to be mindful of in this great article: https://www.nothingbutsharepoint.com/sites/eusp/Pages/Managed-Metadata-Column-Limitations.aspx
At this point in time therefore, I think you need to carefully choose to exploit managed metadata or not, depending on the priority and value you attach to InfoPath forms and/or offline access in your SharePoint deployment, both now and in future. If neither is on your radar now, or in the near to medium term, then I’d definitely advocate leveraging Managed Metadata to help classify and retrieve enterprise content (while hoping Microsoft addresses the underlying problem in future service packs or versions, or someone blogs on a brilliant workaround).
There are many proven examples of basic processes automated in SharePoint that reduce handling time, streamline and simplify business workflows and create efficiencies. The loquacious Bjørn Furuknap provides a simple, accessible overview of SharePoint workflow creation options here: http://blog.furuknap.net/sharepoint-workflow-what-you-need-to-know
While the out of the box workflows in SharePoint Foundation or SharePoint Server may not be extraordinary, they’re perfectly useful in many basic business scenarios – like, for example, routing a document to your manager for authorisation. Start here: http://office.microsoft.com/en-us/sharepoint-server-help/CH010372671.aspx and here: http://office.microsoft.com/en-us/sharepoint-designer-help/understand-approval-workflows-in-sharepoint-2010-HA101857172.aspx?CTT=1 I also like this clearly presented, and very clearly enunciated, 11 minute video overview from lynda.com: http://www.youtube.com/watch?v=KzXtp996ciA
Using SharePoint Designer 2010 or Visual Studio, or even a third party workflow solution, you can extend SharePoint’s inbuilt workflows and create highly ‘custom’ automated processes that fit seamlessly into your organisation.
Why yes, there’s a Resource Center! Albeit not for the faint-hearted.
You can also make a good start with the SharePoint Designer 2010 Help & How To articles at http://office.microsoft.com/en-us/sharepoint-designer-help/CH010373544.aspx
The Drop Off library and the Content Organiser, which I’m currently exploring with a technical colleague for a client, is great in the right context.
The 2010 enhanced Records Management feature set is a huge improvement over 2007.
I really like the Calendar Overlay – that is, the ability to ‘overlay’ one calendar with colour coded events from up to 10 others. It’s a great way to bring multiple business units’ calendars together in one master ‘enterprise calendar’.
I could go on and on, but you get the point I’m sure.
I’m keen to hear your views and, better still, examples of what comprises a SharePoint strength in your workplace … Go on, add a comment…
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:
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/)
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.
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.
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.