Top tips on “How to make SharePoint projects a success”
Many (and seemingly most) SharePoint projects in the NHS fail to an extent. The reasons for the this are complex (and the subject of another article). On the other hand we have gathered a sizable body of knowledge about SharePoint itself and also what seems to make a difference to successful SharePoint projects. The list below aims to share some of the things we can think of.
DO:
| Download the full PDF version: Top tips for successful SharePoint projects |
Develop a careful and well considered Information Architecture – This is probably the single hardest thing to do in a SharePoint project and is ABSOLUTLEY NOT a technical task. It will involve deciding what site structure to have; what libraries and lists are needed and where to put them; what Content Types need creating and what the global and specific metadata requirements are. If you spend less than a week on this then you either are receiving great advice or are likely to get into trouble down the line
Emphasise SIMPLE visual design – The SharePoint User Interface might not be perfect, but it is effective and it rightly emphasises usability over visual appeal. Don’t let the design people get carried away. Also note that changing the User Interface in SharePoint is VERY HARD and any decent SharePoint redesign is going to cost £10k+ (we know of companies that have spent more than £50k). So stick to a few colour changes and images or invest in a predefined theme if you must.
Manage the training carefully – users need to be trained to really get to grips with the new ways of working that SharePoint offers. Look for a course that doesn’t just offer the basics, but also includes hints and tips, workarounds etc. Train the stakeholder team before go live, or even earlier.
Select a partner who really understands the technology and the NHS – and then trust them to give you good advice, to know what they are talking about and to guide you. Challenge them, test them, but trust them.
Keep the permissions model simple – and everything else you can. Don’t build complex structures that require more management than the value they deliver
Build a server infrastructure appropriate to the scale and value of the application – ensure that you either have or plan for resilience (a good intranet etc. will become a vital application sooner than you expect) and make sure you have a granular backup technology in place (make sure it can do item level restores, not just farm level).
Understand the technology – develop your baseline SharePoint knowledge so you know what it does well, what is hard and what it won’t do. That way you’ll “sweat your investment” and won’t waste time getting it to do things it doesn’t like. Identify what is really easy and use it for that wherever possible.
Accept that SharePoint is huge – it’s not (just) a document management or a team collaboration technology and it can address a very wide range of needs in a business. This means that no one person really understands it all and that no one can be expected to quickly get up to speed on it in order to make informed capability, specification and project decisions. Get help!
Invest in Admin courses – a SharePoint administrator is the key support person for a deployment; they can add sites, help users, manage permissions and keep the platform healthy. Find someone, or two if possible, get them properly trained and keep them current. Do this before you go live.
Empower users and delegate – don’t be afraid to hand down rights to author content, create sites etc. to staff, it’s what SharePoint is for. Then use version control, publishing control and workflows to make sure you have the control and auditability you need to ensure the quality and policy adherence the organisation needs.
Be prepared to take some risks with users – don’t just give them some authoring rights, let them have MySites and permissions to do some interesting things. See if you can enthuse them, get them to solve their own problems, develop their own solutions.
Monitor usage – take an active interest in how the suite is being used, what areas are hit most frequently, what isn’t being hit at all. Also look at numbers of documents, storage consumption and search index size. Then take action on this – change stuff, move stuff, set quotas and buy hardware.
Develop a go live plan, with launch activities, support – “Build it and they will come” just doesn’t work. Advertise, proselytise, expect, insist & even incentivise. Put vital information on the intranet (staff directory for example) and remove all other sources of the same (ignoring the protests of the luddites). Have someone to walk the floor during go-live week to offer ideas and help.
Identify the broad stakeholder group and establish a project board – not only do you need to elicit the opinions and needs of various areas of the organisation but you need to get them to help with roll out and take up once the site goes live. Also you will need to find ways to balance the different views that will emerge: Communications will have different expectations and priorities from Governance and these need working through and some consensus reached.
Understand what is available for free – there is a large amount of free stuff for SharePoint, including the ‘Fabulous 40’ templates from Microsoft, the NHS CUI Enablers, a variety of tools on Codeplex and more. It’s also worth finding out what other trusts have that they may be willing to share. However also accept that some things are going to cost proper money and decide whether there is good business value in it or indeed, any choice but to make that investment. Doing things the free or easy way should release resources to take on the expensive and resource heavy components.
Use standard functionality wherever possible – This is a golden rule! Don’t code when you can configure. SharePoint is hugely powerful and flexible, but far too many non-SharePoint experts think it is just a .NET application and immediately write code to deliver functionality. In our experience every need in a phase 1 solution can be met without coding; if you need code you probably have your priorities wrong. As with the free stuff, doing things the easy way will free up resources to spend on other elements of the project… and make the site much easier to support and to upgrade when the time comes.
Come up with a decent name for the site – it is worth giving the intranet a memorable name that expresses the personality of it and the organisation. Devote at least an hour or two to this – or run an in house competition as part of the marketing for the new site. Visit our list of names for some ideas.
Don’t:
… Overwhelm the organisation and users with too much, too soon
Develop a roadmap so stakeholders can see that their needs will be met in future even if not in phase1; plan for the journey and make sure there are way stops en route that let stakeholders review what has happened so far and can review where to go next.
… Re-invent the wheel
Share / absorb learning with other trusts and partners
Start with coding
Configure OOB capabilities
… Accept the defaults when building the servers
E.g. SQL Server defaults will result in autosizing sizing and growth settings that will make the server work flat out just to keep up with resizing
… Point search at many websites that are very large
Although it may be attractive to have your intranet search results include information on the NHS Information Centre, for example, note that there is no way to limit the amount of data SharePoint Search catalogues – if you tell it to index Wikipedia it will do all million+ pages and then bring your server down
… Build the spec without engaging with the delivery team first
Use a consultative approach, take advice from people who know how to deliver SharePoint projects and challenge them to guide you.
… Assume that one person knows it all
Even if they have had a course! SharePoint is huge and no one knows it all. If someone says they are an expert, ignore them. You need a team that knows the technology, Information Architecture design, administration and related technologies.
… Believe everything Microsoft (and their partners, even us) say
It might be legally true, but no one knows it all and just because a thing can be done with SharePoint doesn’t mean it should (for example, websites usually should NOT be built in SharePoint, in our opinion). Also Microsoft have an endearing habit of taking all the toys out of the SharePoint toy box and inviting you to play with them. That’s a lot of toys and definitely more than you can enjoy playing with all at once. We advise putting most of them back in the box (despite what Microsoft say) and picking the handful you want to play with to begin with.
… Assume you can do it in house
Most of the projects that are delivered entirely in house have a high degree of failure – see the previous tips for reasons why. Unless you happen to have a decent sized team with direct SharePoint experience chances are you won’t know enough to do a god job. Please don’t fall into the common trap of giving the development to a .NET developer.
… Use contractors without a strong knowledge transfer mechanism in place
Contractors tend to finish a project (eventually) and then leave with all their knowledge intact plus some of yours, but without leaving much of their knowledge behind. Once they have gone it is very difficult to get the same person back. Make sure you have strong methodologies for knowledge transfer in place and that you have good documentation on anything that is not standard SharePoint.
… Give any individual absolute, full control of permissions
Inadvertently (or otherwise) users with full permissions can do absolutely anything to your SharePoint site:
- Add too much content
- Delete sites by mistake
- Give other users inappropriate permissions (inc full control)
Ensure you have a process for allocating control, backed by a clear set of working principles
