Top 10 CMS implementation risks

A common question we get asked when talking to organisations embarking on a new CMS implementation is “what are the biggest risks to getting a successful CMS?”. Of course this varies massively, but we do have a set of risks that we consider for every new project. Some are specific to CMS — but some could be applied to any project.

I’ve picked out 10 below (not in any particular order). There are more and I could write an entire post for each one, and will hopefully have some time soon to do just that!

Organisations sometimes get in contact with us when they feel they haven’t had a successful CMS implementation. They often start by saying “{platform name} isn’t working for us”.

But what has changed since they selected the platform (usually after a very thorough process of demos and POCs) and decided it would be perfect for them?

It’s the implementation. How it’s been installed, set up and customised to meet their unique needs. And how the team have been trained to use it (or not as the case may be). Most CMS products are generic tools – purposely so they work for as many types of organisations as possible. But the websites that are built on top of them are highly unique and customised — as are the teams put in place to manage them. So the CMS needs to be configured properly to support their specific challenges.

Spend time thinking about what needs customising — and what is possible — and it will save many headaches once the system is live. And if you do make that customisation, think about what it will mean for future upgrades.

It sounds obvious, but I’m often surprised when we request project documentation and there are no documented requirements. Surely to design a successful system you need to understand what all the problems you’re looking to solve are?

Clear requirements allow the team to create an audit trail and benchmark design and architectural decisions against them. They also allow the team to communicate why decisions have been made across the business – which is important with the number of stakeholders involved in an enterprise CMS project.

Capture all the requirements and record what priority each one is. This allows the team to focus on the most important issues, whilst giving the business reassurance that all their requests have been listened to — and that there is a long-term and coherent roadmap for the platform.

And remember, each requirement must be measurable — otherwise how can you actually determine whether the implementation has been successful?

The most vocal critics of any system will be the people who use it on a day to day basis, so we really need to speak to them at the start of the project to find out how to make them happy!

Often the majority of the implementation focus is put on the new features and functions of the public facing website. But if the content management processes and tools aren’t set up to support getting the content published in an efficient manner (while respecting corporate processes) then the shiny social media buttons are pretty useless.

Speak to internal users and find out what they like about the current system, what they don’t like and what their frustrations are. What would their top 3 wishes for the new system be? Make sure all this feedback is recorded in the requirements documentation and prioritised accordingly.

One of the most insightful exercises you can do is a contextual enquiry — sitting with them while they actually use the current system, asking them what they are doing and why, and actually see them in the context of how they perform their day to day work.

It’s often small enhancements like clearly named templates or clearly labelled content entry fields and validation messages that really help drive usage of the system internally – and you’ll learn a huge amount about how things are actually done internally!

As I said in the previous point the internal users will have a lot of say whether the CMS implementation is seen to be successful.

The internal users (just like the external users first looking at a new website) will form opinions of the CMS as soon as they see it — and what they see will affect their relationship and acceptance of it. Don’t scare them with ALL the new features and new ways of doing things. Introduce them slowly to the tool and allow them to build on their knowledge.

Make the steps to complete common tasks as clear and simple as possible. Try and automate any stages that are repeatable and don’t need manual intervention — and ensure that the system notifies them if things aren’t right or they need to do something.

Modern CMS platforms are so flexible that there a number of ways to achieve a single task. This isn’t a positive thing for the internal user. They want to know how to get the job in hand done as quickly as possible — so standardising the way things are done is very important.

Don’t underestimate this risk — I once interviewed an internal user of a CMS system to find out why they weren’t using it and was told, “the colours are too masculine and it looks intimidating, so I don’t like using it.” Simply changing some colours in the CMS style sheet completely changed her perception and she started regularly updating content and telling colleagues how much better the system was to use!

This one is more relevant to component based content management systems, rather than page based ones.

However, it’s very important that when modelling your content types/document types/data structures/schemas (choose the term relevant to your CMS) that you organise them according to the types of content you’re looking to store in the CMS — and not to model the data to support the features, functions or how the pages will be displayed on the website. Introducing new content types to support new features can cause a number of longer-term issues.

The main problem caused by adding a new content type is the increased chance of content duplication and reducing or removing the opportunity of content reuse.

The true power of a component based CMS can only be realised by centralisation of content and applying different views (templates) to it to get the required output.

E.g. All details about a particular product should be found in a single content item ‘component’, and a variety of templates used to format the content (e.g. Full Detail, Summary, etc…). This allows a single update to the product information to affect all the instances where the content is referenced or used on the website.

Also increasing the choices of locations to store content also increase confusion with the internal user base — and as we’ve learnt earlier, we don’t want to annoy them!

I often get questioned on this one — but not all content should be stored in a WCMS platform.

One of the biggest issues we generally have from a customer perspective is their over ambitious timelines for entering their content into the new CMS.

Additionally, they often decide to take the opportunity to re-write their content or at least do major revisions including looking at the structure (a very good idea), but don’t account for the amount of effort that is required to do that job.

“We’ll get all the content done within XX weeks — no problem — which allows you to bring in the go live date”.

Our usual rule of thumb is to double that amount of time as we are hugely conscious of the amount of effort content preparation and population takes. There are brand new templates and features that need new content to work too — content that has yet to be thought about, let alone written.

It’s not just the ‘copy & pasting’ into the CMS — it’s the questions that are raised about the content itself — “is that up to date?”, “is it in the right place?”, “do we offer that service or product any more?” and the time it takes to get their management team to review and approve the changes (and to process any feedback). And with other tasks to do before the new system is ready it is the preparation of content that is left until the last minute.

So start preparing the content straight away — create a content plan, get it into a format so that anyone with basic CMS training could enter into the new system, as when you’re approaching the planned go-live date you’ll be asking anyone who can help.

Be sensible about the time you think this will take otherwise you’ll set unrealistic expectations for the go live date and the project will be seen as a failure.

There’s a reason why the CMS has been constructed in a particular way, and it’s usually to solve the very specific problems you identified earlier, that you’ve selected the platform. So embrace the changes and the different way of thinking that the new CMS brings.

And finally, not wanting to sound like a sales pitch (yes we’re CMS implementation experts!) you’re never going to get a useful CMS unless the team implementing it are experienced and know what they are doing.

Most CMS platforms contain a large number of features and functions that allow organisations to manage ever growing web presences — and this means they contain a level of complexity.

Make sure the team implementing the CMS understand this complexity and the reasons for it, as well as having experience using the platform — what issues have they faced in the past, how would they stop them from happening again?

Having an experienced team who can point out the potential problems and bring ideas that have been successful in the past will increase the chance you’ll get a system that works and meets the needs of the business.

Finally

Well that’s a selection of the risks we think about when working with CMS implementations — there’s a few more that I can think of but will save that for another installment (if anyone is interested!)