Cleve Gibbon

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?