Feature

posted 11 Sep 2006 in Volume 3 Issue 3

Content management

Twelve implementation pitfalls to avoid

Tony Byrne of analyst group CMS Watch has seen and heard it all. Here, he advises on how to avoid the twelve common pitfalls of content management system implementations – and the best practices to follow instead.

Having led several content management systems (CMS) implementations and after debriefing dozens of practitioners, CMS Watch has seen many CMS projects go wrong – and much go right. Here is a distillation of the common pitfalls organisations fall into, together with best practices to follow.

Pitfall one: Selecting a CMS package before developing a solid business case and requirements.

Best practice: Gather requirements thoroughly – but only after establishing a business case to shape and discipline the process, then select a package that truly meets your needs.

Talk to ten software integrators and nine of them will tell you that the biggest single predictor of a failed implementation is when a company chooses a specific package before requirements have been adequately established. And the second biggest? A requirements phase that drags on because no unified business strategy exists against which tough choices can be tested and measured.

When companies select CMS packages before they agree on business objectives and adequately ascertain stakeholder needs, the technology inevitably ends up driving the system – the people, business rules, editorial processes, even the content itself – rather than the other way round.

Perhaps more important, they encounter critical forks along the implementation road, which raise a number of important questions: Should they compel authors to use forms-based entry or focus on conversion from Microsoft Word? Should they integrate their catalogue content using special connectors, or not? There are no simple answers to such questions, but a clear business rationale will help organisations to make solid choices.

Pitfall two: Not getting a clear mandate from the top.

Best practice: Obtain strategic direction, a suitable budget and a mandate for necessary changes.

Like anything in business with potential to yield a strategic payoff, implementing a new CMS is hard and potentially expensive. It can bring change to many parts of an organisation and, however felicitous the improvements, change unnerves most people most of the time.

Leadership is therefore required to see a CMS project through to successful completion. When difficult choices arise, being able to refer to the business rationale will lead to faster and more effective decision-making. This may require carrots as well as sticks and you will surely need senior management to provide both.

Pitfall three: Thinking a web content management (WCM) package will provide a CMS.

Best practice: Model your existing and prospective CMS using building blocks of people, content, practices and infrastructure.

CMS software is just one part of the infrastructure building block in your CMS. If it is like most others, it will consist of 20 per cent technology and 80 per cent process. This is actually good. You can control and modify a system, but you can’t always control and modify packaged software as much as you would wish.

Pitfall four: Not involving internal stakeholders from the start.

Best practice: Involve system users in the design, implementation and testing of the system.

There is a temptation among IT departments to shield domain specialists from key decisions on information architecture and workflow. However well intended, this is a mistake. Only the content owners can put meaning and context to the information that will be published, so they must be engaged in design of taxonomies, site maps and even page component layouts. The more they participate, the more enthusiastically they are like to adopt a system and the more actively they will market its benefits to the rest of the organisation.

Also, there is a growing consensus that the most usable applications result from a truly user-centric design process, with users involved from the very beginning in the shape of the ultimate solution that will be rolled out.

Sometimes, however, there are inherent conflicts between capability and usability. For example, the distinction between ‘power users’ and ‘casual users’ touted by CMS vendors can become problematic within any organisation. Is a power user an author who needs an efficient interface to accomplish the same thing repeatedly – and often – or a managing editor who needs a control panel to do a variety of oversight tasks, such as moving pages and sections or to administer taxonomies?

Those are two very different personas that will likely require very different interfaces. But very often, simple will work better, which is good for the developers, but places a premium on finding the specific product whose orientation matches your organisation’s needs.

Pitfall five: Involving only internal stakeholders throughout the project.

Best practice: Integrate content end-users early and often.

The purpose of investing in taxonomies, search engines and the content itself is to improve the user experience, helping them to realise greater value as a result. Test the likely return on investment by including your best customers and partners in the planning and debugging of the system wherever possible. Do this early and often.

Pitfall six: Spending insufficient effort describing and organising content and understanding migration times.

Best practice: Invest in mapping the structure of your content, building workable taxonomies and creating user-centric information architectures. Then clean the data.

Inadequate work up-front in information design and mapping will inevitably mean leaving key architectural decisions to engineers or graphic designers. How will news articles, for example, be linked to your product line? Technicians and designers need to be involved, but ultimately it is a business decision.

Also, don’t overlook the challenges of content migration. If you already have a website, you already have content and migration of at least some of it will be required by relaunch. Most engineers quite properly view content migrations like an extended trip to the dentist. Some packages have migration wizards to import existing HTML.

But such tools will work well only to the extent that your existing content is structured and consistently organised. Migrating databased content would appear somewhat less painful on the surface, but in practice it brings its own headaches, particularly if the new system employs a radically different data model. Some good ‘cleaning’ to do early on is to make sure that all existing pages are XHTML compliant.

Pitfall seven: Picking a CMS package that doesn’t play well with other corporate applications.

Best practice: Identify the broader IT environment for your WCM effort and anticipate integration needs.

Since your CMS may evolve into the prime public gateway into your legacy systems, the ability to integrate successfully is critical. What languages can you or your consultants use to customise the system? How much of the underlying structure and logic contains open application programming interfaces (APIs)?

One way to help yourself is to follow industry standards. Open database models, separation of data and logic, and adherence to industry standards can all help protect the investment, whether the package is unexpectedly discontinued or when the time comes to upgrade once again.

Remember, however, that adherence to standards is relative, not a state of being. Find out how the vendor adheres to standards that are most important to you and map that against the goals you are trying to achieve through standardisation.

Pitfall eight: underestimating hardware needs.

Best practice: Get more server power than you need today.

CMS packages are notoriously resource intensive. Also, if you are being creative with features like personalisation and metadata, your database will fill up with all kinds of interesting and potentially useful records that could grow to dwarf the storage size of your actual content. That’s why clustering and load-balancing are no longer just for enterprise implementations.

Pitfall nine: Underestimating integration and other processional service needs.

Best practice: Anticipate the need for outside help and budget for it accordingly.

The famous last words in any CMS marketing materials are ‘out of the box’. Even the most pre-packaged solutions require some level of integration. Behind some of the stories, we have heard of failed implementations where the entire budget was spent on software licensing and maintenance, leaving nothing left for the most crucial part: getting the system to work.

If content is important to your organisation, then how it is managed, organised and presented will differ from the way that other organisations do it. Working out what needs to be customised can take as much effort as the actual integration. And bear in mind that the complexity and dynamic of your organisation’s business rules and processes will be key determining factors in terms of the extent of integration required.

Also, someone will need to code work-arounds for the inevitable bugs and undocumented product shortcomings (even the best software will contain both). The key, of course, is to closely involve enough of your own technical specialists, if available, to make sure that sufficient expertise transfers in-house to make updates and changes to the CMS going forward.

You should also seriously consider who will take care of other tasks that have everything to with unleashing the value of your content, but are only tangentially related to implementing a CMS package – such as outlining a meaningful site information architecture, creating value-add visual presentation schemes and developing user-centric navigation.

Pitfall ten: Looking solely at the product and not enough at the vendor.

Best practice: Perform as much due diligence on the vendor company as you do on their product.

When you purchase software, at some level you are ‘marrying’ your CMS software vendor. Companies, like people, have personalities and software companies often have strong personalities. Understand how your prospective vendor generally behaves because you are going to be living with them for several years. How do they treat their users groups? How can smaller customers get their attention? How many mergers have they experienced in the past two years? This last one can be a predictor of possible internal disarray.

Moreover, you may be working very closely with their professional services and support staff. Do they mesh well with your team? That chemistry alone could well have a greater impact on the success of your project than the suitability of the product.

Pitfall eleven: Missing or underestimating internal change-management issues.

Best practice: Recognise and make explicit how new systems and tools are likely to affect people’s jobs and enlist their support for productive change.

Providing publishing tools to line-of-business managers will be exhilarating and liberating to some, horrifying to others. Some content owners might not want to

take direct responsibility and control for the timeliness and detail of their part of a website. Workflow tools and detailed auditing mechanisms in particular bring a whole new dimension to accountability. Others may resent finding themselves suddenly unable to dictate the look and feel of their content, as they used to.

Of course, that’s just the idea. If the internet is central to the way you do business and content lies at the foundation of your web efforts, then you will want a system of incentives and controls to make sure content is managed well. You are not necessarily eliminating people’s jobs, you are just asking staff to focus more intently on their particular areas of expertise. Involve your best people in the design process and the new system should work well.

If you have successfully devolved content maintenance to content owners, one of the first people who may need to reinvent themselves is the corporate ‘webmaster’ – a job title that did not exist until 10 years ago and now likely to disappear. There is, however, a good specialisation story to tell to win them over. Instead of spending time shovelling content through HTML converters or tracking down the correct versions of the latest press release, webmasters can free themselves to focus on higher value-add specialties, such as:

Content-oriented webmasters can focus on the editorial quality, web suitability and the substance of the subject matter itself;
Technically-oriented webmasters can grow to manage a true online publishing system;
Design-oriented webmasters can focus on the visual effectiveness of the presentation and multiply the value of their efforts dramatically be propagating their designs through broadly-used (and enforced) templates.

In any event, many people’s jobs are likely to change. Some will have much more work, while others will have much less. On the whole, though, you should be able to manage more content, faster and with better results. But leadership will be needed to address the inevitable individual winnings and losses along the way.

Pitfall twelve: Not preparing for a potential content expansion and change.

Best practice: Anticipate future content expansion in your site architecture.

When people find publishing easier, they will often generate more content. That can be a good thing if you’ve put in place a solid quality-control system. But just make sure that your systems will scale accordingly.

One system that can get stressed very quickly is the site information architecture and navigation scheme. New types of documents and heavier volumes of content can tilt the balance of the user experience away from ease of use towards clutter and confusion. Debrief content owners during the prototyping phase to anticipate and address future information flows.

To contact Tony Byrne and CMS Watch, please e-mail Kristie Hughes, hughes@cmswatch.com or visit the website www.cmswatch.com

Summary:

Work out what you need the CMS for before selecting a package – but don’t let the requirements phase drag on for too long;
Once the requirements document – the business rationale – has been done, get a clear mandate from the very top of the organisation;
Web content management software does not equate to a CMS;
Involve all stakeholders as much as possible – within reason – from the very start;
If the engineers building the system have inadequate information about how content needs to be organised, they will make those decisions for themselves – decisions that the business needs to be making;
Ensure that the selected package will integrate with other corporate applications;
Don’t underestimate hardware requirements. If implemented well, demand will increase, so plan accordingly;
Likewise, don’t believe vendor claims that the software will work ‘out of the box’. All good software will require some degree of customisation;
Don’t underestimate potential internal change-management issues;
Perform due diligence on the vendor, as well as its product.

About The CMS Report

This workshop is extracted from The CMS Report, a 400+ page special report examining all the issues and options in content management. Now in its ninth edition, it features evaluations of 32 different content management systems (CMS), including offerings from EMC Software, IBM and Open Text, as well as a number of the most popular open source CMS software packages and hosted services.

In addition, the report also covers a wide range of the most important issues involved in CMS procurement and implementation, including how to articulate the business benefits and tips on negotiating with vendors.

The CMS Report costs from $895, is updated every six months and can be purchased from www.cmswatch.com.