It would seem to be a statement of the obvious that organisations should do their planning before embarking on the implementation of their new content management system (CMS). Yet all too often this doesn’t occur.

Let’s state this more strongly: the day after the contract is signed with the CMS vendor, the vendor will show up asking: so, what are we actually implementing?

If there is not a clear and simple answer to this, the project will go poorly, and the vendor will be more than a little frustrated (which itself may have consequences).

This briefing explores the specific details that should be worked out up-front, ideally before the tender or RFP is even sent out.

Product versus project

In many cases, the selection of a new content management system is seen as a technology project with the goal of obtaining a new ‘product’ or piece of ‘infrastructure’.

When driven from this perspective, it is seen as reasonable to ‘put a CMS in place’, and then consider how best to make use of it.

The first problem is that vendors will be asked to provide a fixed-price quote for the implementation, which will then be locked in as part of contract negotiations. When the vendor turns up on day one of implementation, they therefore expect that everything will be in place for an immediate start.

At the end of the day, vendors want the implementation project to go smoothly, not least because it means that they will get paid sooner. With a 6 week implementation plan standard for mid-market vendors, there is only limited scope for additional planning and design.

If plans are not in place before the project starts, there will be lengthy delays, and the vendors will rightly agitate for extra payment based on ‘project variations’.

These problems arise from the confusion between the product and the project. Fundamentally, the project is to deliver a better site (website or intranet), and the product is merely a means towards that end.

Selecting the right product

There is another key reason for determining the project plans in advance: these details may strongly influence which product is obtained.

Products are not unlimited in their flexibility, and every product has strengths and weaknesses. This means they will be very effective in certain circumstances, and completely useless in others.

As discussed in the earlier article Separate design and the CMS, the site designs should be finalised before starting CMS selection. Many other issues (as listed below) will also influence the scope and capabilities of the CMS.

Other details required

There are many other details that should be worked out early in the project (ideally before the selection process starts), including:

• sites to be published using the CMS
• timetable through to ‘go-live’
• planned process for migrating the content into the CMS
• functionality that will be replaced with the CMS, or left as is
• team responsible for running the implementation project
• area who will maintain the CMS
• team who will own and run the sites
• design and structure of the sites
• metadata that will be used
• other systems that the CMS will need to integrate with (in specific)

Limits of planning

As a final note, it is important to highlight that some things cannot be worked out in advance. If a CMS is being purchased for the first time, it is not possible to pre-plan what the workflow will be, who the authors are, or what the governance needs to be.

Instead, these details should be determined after spending a number of months piloting and ‘tweaking’ the use of the CMS.