Cleve Gibbon

An on-going challenge for CMS build projects is that they are pre-dominantly design led with the primary focus set on publishing content. With less attention paid to users in content producing roles, editorial needs are rarely catered.  The new solution goes live and “The CMS” quickly becomes a dirty word because it has not been deployed to effectively create, understand and manage content.  Sound familiar?

Content producers do a lot of things – Create content, Find content, Re-use content, Value content, Review content, Tag content. The CMS also pulls its weight with content: storing, indexing, auto tagging, displaying, recommending, publishing and workflow. This requires us to think really hard about how we intelligently structure content. And that’s where the battle is waged today for both time and effort to do editorial thinking on CMS build projects.

Instead, what typically happens during the early stages of a web content project and leading through into the build is that focus lies almost entirely on the customer-facing aspects of the web-site: the simple publishing challenge. Unless we start turning our focus inwards and shining the light on the difficult editorial challenge, CMS projects will forever be slated as those projects doomed never to deliver on business expectations.

The first post in this series highlighted the issues CMS projects faced following the build path above. Today, we’re going to add another path to the project that gets us thinking more about authors.                                                                                                                                                               

The three stages above map onto the way creative agencies tend to engage on content projects. This is no coincidence.  A CMS build will always take creative assets as outputs. However, we need to ensure that these outputs make sense as inputs to the build process. And in order to help shape the quality of creative outputs, technologists need to step up and into the creative design process to:

•  Explain how creative outputs impact the build.
•  Demonstrate the CMS art of the possible/impossible.
•  Highlight gaps in the outputs that the project needs to plug.

For a simple site, with authors, we need to work with both paths in parallel: creative and content. Whether it’s a short-lived digital campaign, a long running micro site or the corporate web site itself, we need to consider both paths if the content is going to end up in the CMS. In doing so, intelligent value decisions can be discussed in an open and transparent way, at time when they can be acted upon:

• Should we invest in building tailored authoring interfaces that both simplify and enhance the content creation process, or rely upon the “out of the box” CMS interfaces?
•  Do we really need to single-source content for re-use across the business, and do we have the skills and backing to do that?
•  Where is the web site going? Does it need to evolve to better support multiple channels, multiple devices, multiple sites, multiple languages, multiple business units, multiple products, multiple authors, multiple blah?

Based upon these decisions, you can get a feel for how much effort needs to be placed into the content stream. It’s funny (not really) how many of these decisions are encountered during the build. It’s scary (really scary) just how many of these decisions are made by developers, unbeknown to the business, in order the get the CMS projects delivered. Why?

Instead, open the box. Look inside what goes on it a CMS build. If you’re on the creative side, re-visit your outputs and see if they are catering for content producers. For CMS folks, are you holding the line and waiting for the right outputs?  Why aren’t you rolling up your sleeves and getting involved to help mould them into something you can really work with.

This is where I see content strategy playing a vital role in pulling these two streams of people, process, and products together. The reality is that this is a really hard sell because it requires change on both side, and for the client to buy into it (literally).

It also has a lot to do with the digital maturity of the organisation, and to a certain extent, their content maturity. For media folks, where content is their product, there is no sell. They get it. They know the value of content.  So for them it’s more about their ability to execute, which points more to their digital maturity. Where we are dealing largely with marketing content, it’s a much harder sell. But with mobile firmly on the executive boardroom agenda, multi-channel content and all its disruptive challenges, things are starting to change. And with that change, maybe, we can better communicate and take these additional paths during CMS builds projects.

The importance of digital content to an organisation is growing year on year. At all levels, we’re hearing people asking for better ways to manage their content. Not as fast as we hoped, but this has led to advances in the way content management projects are run. The reality is that the success of content management projects depends heavily upon a company’s digital and content maturity, and the degree to which they are amenable to organisational change within that project’s timeframe. As an expert, consultant and/or supplier brought in to help deliver a content management project, the chosen build path is somewhat pre-determined.

This post is the first in a series short posts that looks at some of the common build paths content management projects take when delivering web sites. Not every project is the same but they do tend to follow a set of common delivery patterns. Let’s start at the beginning with the simple site.

Simple Site, Design-Led

You want a new website. You have a vision and plan for how to get there. Maybe it goes something like this:

1. Brief in the creative agency.
2. Do some information architecture, interaction design and user experience.
3. Create outputs in the form of site maps, personas, user journeys, wireframes and PSDs.
4. Perform several rounds of usability testing.
5. Maybe create some HTML, supporting content (video, case studies, imagery), SEO, etc.

Great, now we have some deliverables and it’s time to get this site built people. Your project plan tells you it’s time to select a CMS (if you’re lucky) and find a solution provider to bring your site to life.

This is how the majority of web sites were delivered 10 years ago. Some still are today. Here, the CMS Build project path is a design-led effort where success is measured around just getting it live and the web site is only concerned with one channel: the web. This is CMS Build 1.0.

You’ll notice from the 3 simple steps above that all the focus is entirely on the end customer and the published site. There is little or no consideration for those folks responsible for creating and curating site content. This is not an oversight. To quote a past client:

Cleve, it’s not that I(a marketer) don’t appreciate authors. I do. But I’m targeted on end customer stats. It’s a tech problem to kept the site up to date. (Cira 2007).

CMS Build 1.0

Today, digital content projects expect more than what a CMS Build 1.0 project can possibly hope to give them. The build has to take a different path for some, if not, all of the following reasons (and more):

1. The Web is not the only channel.
2. The target audience is mobile using an incredibly diverse set of devices.
3. Digital publishing is iterative and incremental, no longer print and go.
4. Equal consideration for both content and design is required for effective user engagement.
5. Editorial tasks need to be super low effort if they are going to be useful at all for authors.
6. A CMS operates on a Garbage In, Garbage Out policy for content. Don’t put crap in and expect meaningful stuff out. Think semantically!
7. Content is no longer static. It needs to be wickedly dynamic, searchable, discoverable, customisable, personalised, localised, translateable, and so much more. It needs to be intelligent.

Every journey has a starting point, but not necessarily an end point. That’s okay. But it’s important to understand where you are before you embark upon a CMS Build. This goes beyond the content audit and into getting a better feel for an organisation’s level of maturity around digital content and it’s appetite for change. For a CMS Build 1.0 this is not really a concern, but in later posts, as the builds requirements become a little more involved, there are some things that are just not possible. The organisation is not mature enough and/or capable of achieving certain digital content goals. Understanding and accepting this early, something we techies refer to as failing fast, saves precious time and money, and sets you on a realistic build path for success.

CMS Build 2.0

CMS Build Projects needed to get smarter. They have. Technologists have to reach out to all manner of content folks within a CMS project. Techies need to step up and clearly articulate what their desired outputs and outcomes are from upstream activities, as well as communicate the art of possible with the technology they so deftly wield. We’re not there yet with CMS Build 2.0, but we’re getting closer by thinking about:

• Content Strategy: Get involved. Understand more about planning, delivering and governing digital content.
• Content Architecture: Invest time and effort in determining how technology can be used to support the content strategy.
• Author Experience: Focus on the tasks content producers perform and build structured authoring interfaces to manage that effort.
• Content Technology Platforms: Bringing all the required best practice, standards, policies, content, and processes together under a platform(s), using technology as a facilitator where appropriate.

We do this, and the business gets all things we know they want; reduced costs, lower time-to-market, optimised resources, and increasing customer satisfaction. We give them means to be more profitable. We’re happier as a result. Win-Win.

What shape is your CMS Build Project in? Are you 1.0 or moving towards 2.0?