Technology & Engineering December 06, 2011
CMS application and operational governance
Everyone wants to join the party if a new CMS is launched successfully and it receives positive internal feedback. But beware – this is where things can start to go wrong.
If a clear application governance model has not been put in place, then as more business units start to come on board, each team can start to do things different ways. Problems like:
- Enhancements are added that directly benefit one business unit, but adversely affect others
- Teams find different ways of doing the same thing – duplication of CMS assets and effort starts to creep in
- Items get named inconsistently and the system starts to become very fragmented
- Teams start to fight between themselves for system or staff resources
- The teams don’t communicate and so start stepping on each others toes
When these issues start occurring the support and maintenance effort of the system increases, release cycles slow down (due to the amount of work, conflicts and regressions issues that occur) and CMS software upgrades become drawn out and painful.
Unfortunately this isn’t usually thought of until after go live. Everyone has been busy getting the implementation up and running and the ongoing operation of the system is a little bit of an afterthought, or something that can be put off until later.
So what to do? Well like most things it’s down to communication and clear roles and responsibilities.
Who’s the owner?
First of all we need to understand who the owner of the CMS application is. Sometimes the ultimate owner isn’t crystal clear. For example – it’s hosted on the IT department’s infrastructure but the marketing department pay for new developments as they often effect the public website. And of course there’s the usual clash of priorities and working speeds – IT prefer structured and planned changes and release processes to minimise risk, but marketing constantly need to reduce their time to market for key communications and promotions – so time is of the essence!
If this is the case then there may not be a single person responsible for the ownership. So form a group of people who act as an owner or a CMS “steering group”/”board”. This allows the decision making to include representatives from all key stakeholders while still having an entity who can make final decisions.
Clear, documented processes and procedures
Before the system goes live, define responsibilities and put in place processes and procedures that everyone agrees on that explain how the system is going to be governed post go live.
Simple policies like ensuring that changes and enhancements need to be approved by a central team or owner and that best practice guidance is documented and adhered to are useful.
Communicate who is responsible for each area of the system – who do people need to escalate issues to?
How long should things take? It helps to set expectations and reduces the chance of stakeholders expecting work to be done in unreasonable timeframes.
CMS stakeholder meetings
Try holding regular (e.g. monthly) CMS meetings to discuss the current state of the platform, new developments or changes that are being worked on or are soon to be released.
How’s the CMS performing, is it stable – how’s the IT infrastructure coping? Try reviewing helpdesk tickets or support requests regarding the CMS to try and spot problems or issues.
It’s important to hear different party’s views – so invite representatives from all groups involved with the CMS from across the business. Try and include 3rd party suppliers to participate too. This way everyone knows the current status of the system, what other people are doing and they have the opportunity to proactively communicate any concerns.
Central repository/knowledge base
The best CMS operations I have seen have a central knowledge base, accessible from the CMS that contains items such as:
- Announcements – new templates, possible maintenance downtime etc…
- Explanation of processes – how do I request a new template?
- Training manuals – and possibly videos
- CMS documentation – specifications, designs etc…
- Wikis – for documenting how people achieve tasks
- Forums – so editors can discuss issues and answer questions. This is particularly important when content editors are geographically dispersed.
These resources help to reduce the number of helpdesk or support enquiries that can effect a CMS operations time.
Example website implementation
If multiple websites are hosted within the same CMS, then it’s useful to create an example site that demonstrates all the features, functions and templates available within the implementation.
It allows teams to see what’s possible and how it was put together.
It’s great for test teams too, allowing them to see the effect of new features in a “safe” environment.
Defining a clear operations model for the CMS should be one of the key deliverables in the initial implementation project. Putting these actions in place before the CMS is live really goes a long way to keeping your CMS in a fit state and puts you in the best position to maximise the investment you have made in the platform.