Contrary to what some people think, incompetence is not a bad thing.
Have you ever witnessed an attempt at organisational change and thought to yourself, “How could they have possibly thought that would work?”
Are you thinking about launching into a BI project soon?
Enjoy the Journey
The best advice I can give anyone for success with SharePoint over the long term is to embrace it and enjoy the journey. Journey?
It’s All in the Planning. Up To a Point.
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?
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.
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.
- 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