Look before you leap

Implementing a content-management system can be a boon to your organisation, but anticipating its benefits without knowing exactly what information it will control could end up costing you. Lynda Rathbone, managing director of Four Square Media, explains how a content audit can help you choose your CMS.

Warning: The following questions could reveal more about the current state of your content than you might realise. Has your website been growing for the past year or more without a CMS in place? Are you in the process of selecting a new CMS technology to help you manage your web presence? Have you been meaning to clean up those files on the server but just haven’t made the time? Are you about to launch a new site or portal, but don’t have a comprehensive content-migration strategy?

If you answered yes to any of these questions, then hopefully I can help shed some light on why performing a content audit before selecting your CMS can make a world of difference. But before discussing the importance of content audits, a few terms need to be defined.

Content

Content is usually defined as being all website copy. But this definition is critical in understanding what to manage and what is simply text. Content should be defined as, but not necessarily limited to: documents, web pages, images, forms and copy that is active or that allows the user to do something. Text is not necessarily content. For example, if you have too many introductory paragraphs on web pages telling users what’s there, they may never find what you want them to.

Audit

It’s important to clearly define what you mean by this because interpretations can vary widely. Do you only want to take stock of what’s currently on the site, what you’re planning to put on there, or a combination of both? What about including web-based applications – are they considered content?

Audit has become a loaded word for most businesses. They believe when they see an assessment team coming their way, it can’t be good. But in a content-audit sense, this is wrong. For a website, the procedure is essential in helping both the business and the site owners understand what’s really necessary. It also helps the web team select the right technology for future support.

An audit I once performed serves as a good example. I was working with a large consulting firm that specialises in doing audits to help my former employer establish control of over 500 websites it was maintaining in 12 languages in more than 30 countries worldwide.

In those days, it was common to see individuals creating their own sites for their businesses. My company was no different. There was no central website management within the organisation and people felt they wanted localised control. When the company decided to consolidate all the sites into one after years of uncontrolled growth, it was a huge undertaking. The project’s goal was to launch a single website with design and brand guidelines on a single host environment. This would standardise the look and feel of the site and save millions by hosting it in one place. The audit conducted at that time focused on sites and owners and left content further down the scale of importance.

Templates were developed for this new global site, brand and design guidelines were agreed and a country-by-country strategy of content migration began. A year later, a single website launched using .asp page templates but no CMS.

If you didn’t spot the problem in the above example, here it is. The audit did a great job in identifying who and what needed to come into the new global site, but it didn’t address the technology required to support it, either short or long term. At that time, just getting everyone’s site turned off and the new site turned on was heralded as a major victory.

Unfortunately, two years later the site had grown out of control without content-management processes in place and it was time for another audit. The lessons learnt here have helped me design different ways to conduct an audit.

Lesson one: understand your audience

Understand who your audience is and the nature of their relationship to your content. Knowing how and why the content is used should, in turn, dictate how you publish it. Once the publishing decision is made, it should help inform your decision on which technology to choose in the future.

Here’s an example. A company had a large internal sales database that stored all the information any sales person globally would need to know to sell any number of products or product sets. This database was only available via the intranet and was accessible by anyone in the company through a web-based interface. It was updated by the team who owned this resource via a bespoke web-administration tool. And although it was one of the first items on the intranet, it was the least sophisticated because the internal team felt it suited their purpose well enough.

The lesson learnt here was that once a content audit was completed for the public internet and customer extranet, it became clear a percentage of the information in the sales database was desirable and appropriate for publishing directly to external sites without modification. This way, the public and customers could self-serve what was appropriate and have a way to contact the sales team for follow-up service or pricing. This required a change in technology by putting a CMS in place. From the internal team’s point of view, a content audit would not have flagged up a need for publishing directly to the external site, but from a user’s perspective it did. It was valuable to learn and understand what audiences needed and then upgrade the technology to suit that purpose. This way, both the internal team managing the database and the end user were satisfied.

Lesson two: content migration

Do not underestimate the level of effort involved in content migration, an issue that often gets overlooked. Because the outcome of an audit is generally a combination of the archiving of old content, updating the current content and planning for future content requirements, it generally involves an upgrade of platforms and systems.

A good migration strategy is an essential part of any audit and should be a factor within the audit itself. Content should be flagged as ‘ready for migration’ or marked with what’s necessary to achieve it. Old systems often add pages or code overhead, which will cause problems when simply cutting and pasting content into new templates. Much of the formatting added by the software may also cause conflicts in the new environment.

You should also consider taxonomy and search during your content migration. When shifting content from one system to the next, keywords carefully chosen and put in the code may not be preserved as intended. The search engine that will be indexing your new content may not work the same way and modifications may have to be made.

When your audit is complete and the content’s migration readiness has been assessed, be sure to find out if the CMS you are thinking of buying has tools for this purpose. Many do not, which can cause costly delays if contractors need to be brought in at the last minute. The CMS market today offers specific migration tools that can really speed up the process.

Lesson three: you can get fired for choosing IBM

Choose the technology to fit the problem; don’t force the problem to fit the technology. This seems obvious, but there are still people who believe they won’t be fired for choosing IBM. I have used many of their products successfully but, as is often the case with large software packages, you get dazzled by the feature-rich environment. In reality, you often need only a basic CMS with a product catalogue and e-commerce capability.

In the case of the global websites audit mentioned earlier, the solution did not fit the problem. A year after that audit, someone who was an ex-IBM employee came into the company and spent a majority of the team’s budget buying IBM’s Websphere, Interwoven and the rest of the product suite that comes in their premium bundle. They believed if they had the best tools, the problem could be fixed.

In theory, this was a great idea. But in practice, the state of the site, its content and the business strategy weren’t ready to move into a new CMS. Furthermore, the requirements for the new CMS were unknown. Another audit was required and a large amount of work would be necessary to migrate the data into new templates. Added to this was the problem of training authors around the world on Interwoven, which involved multiple language issues and barriers.

The IBM licenses expired a year later and nothing in that product set was used. The person responsible for making the decision was no longer with the company, either. The IBM CMS technology was purchased because it was a premium product, so how could there possibly be a requirement that it would not meet? While this may have been true, the system was overkill and it was the wrong time for the purchase. While the company wasn’t thrilled at the prospect of having to conduct another audit, they benefited from past lessons and did it correctly.

Lesson four: focus on culture

The structure of a large organisation is such that there’s often a conflict of interest over who owns the content. Technically, while the web-portal manager owns the content, there are authors in the business who create, usually publish and are responsible for updating the content. When doing a content audit, it’s critical these authors are involved from the start as key stakeholders – no matter where they are or what language they speak.

While their role may be at first fairly straightforward, as you identify and archive old content and understand new requirements, authors should be more involved once the initial audit is completed and the technology choices are being made, as they will likely be the primary users of the CMS.

An example of this lesson is a company that chose Interwoven as their CMS for authors globally. This company had authors using ten languages, including Japanese. The central UK web team had its hands full keeping the Tokyo team informed of the progress of the Interwoven installation, budgeting for the migration from the old system to the new one and even doing the English language work for them. But they completely underestimated the training required for system users in Tokyo. Training Japanese speakers trying to understand English instructions over the phone simply did not work. Months of complaining and non-compliance on the part of the Japanese team were justified and the UK team began receiving notes from the Japanese vice president stating his team couldn’t make site changes that were business critical.

The lesson learnt here was to get someone to provide CMS training locally in Tokyo, before the migration, so they could hit the ground running. This finally happened but it was too little, too late – the Japanese team was already frustrated by delays and the inability to publish to their own sites. The cultural and political damage was done.

Choosing a CMS can be one of the most difficult or fairly straightforward decisions you make for your website. In my experience, this depends entirely on how prepared you are to discuss your needs, in detail, with the CMS provider or consultancy you use. Audit doesn’t have to be a loaded word – when it’s well done, it can go a long way in determining many of these requirements.