CMS reputation
Don't let your CMS get a bad rap
by Sara Redin
22-Jan-2007 --
CMS project managers face a dilemma. For a project to succeed, contributors need to embrace the system. However, when confronted with a new CMS your business colleagues are, understandably, not interested in understanding the system but in getting their job done. When things go wrong, negative experiences can quickly turn into a bad reputation for an entire Web CMS project, diminishing the possibilities for future success.
Don't underestimate the power of reputation. Bad raps form quickly, unexpectedly, and most often when you are not around to ease the trouble that caused them. Annoyed authors will retell the stories of the system's insufficiencies to others, and bad news travels fast.
You may never hear about gripes from their source but they will catch up with you eventually, maybe when arguing the need for more resources or a broader roll-out. Or sometimes, a bad rap becomes positively fatal: upon traveling upwards within the enterprise hierarchy they can become justification for avoiding automated content management in lieu of a return to previous, manual processes. Or a bad rap can lead to calls for different tools -- even though technology may not have been the root of the problem.
Successful project managers must work to stave off a negative reputation, especially in the delicate early phase of a CMS project. What follows are some thoughts on how to do that.
When good CMS projects go bad
Many project managers underestimate content contributors' sensitivity to set-backs. Remember that in a typical web publishing regime many authors spend less than 10% of their time for writing and publishing to a website or intranet. They will never become super-users, but still work under very specific schedules for when, where, and how to upload new content.
When web content authors are assigned part-time and involuntarily to a project they may be unhappy, insecure, or simply intimidated about their role -- and hence more likely to grab any problem and turn it into a reason why your project shouldn't be prioritized. But what are the likely problems?
Frustration is the mother of slander
There are 3 main sources to the bad raps that can ultimately ruin contributors' relationships with the CMS:
1. Poor Usability
Poor usability is endemic among modern IT systems. But CMS tools in particular seem to confound authors and editors. Among the problems:
- Vocabulary
The CMS has its own words for common functions such as "edit," "save," or "publish," making the system less intuitive to use. - Rich text editors
Text that is copy-pasted from a common MS Word document looks funny when pasted into the WYSIWYG editor of the CMS. - Slow performance
For any number of reasons, contributors have to wait too long in-between "submits," making it difficult to focus and finish publishing tasks. - System time-out frequency
Authors whose daily work features frequent interruptions have to login repeatedly.
All Web CMS packages fall victim to problems like these. Yet, in many organizations these disappointments come as a rude shock, because functionality gets oversold to the authoring organization in order to fund the project.
2. Insufficient training and support
Even though project managers generally have good intentions around training and support, they typically underestimate the effort required in terms of resources, timing, and planning.
Training often gets postponed or forgotten when project staff move on after an initial implementation. Generic end-user training that hasn't been customized to your actual application is worthless and will just reinforce fears that the tool was not built with authors in mind.
Support organizations rarely get established in the beginning of a project, instead usually coming into place -- ready or not -- once the system gets implemented. Support staff may be completely new to the system for which they are supposed to provide support. In many organizations the CMS support function falls to an IT person with access to the systems manual.
3. Lack of organizational communication
CMS projects usually touch many internal departments, which puts a premium on intra-organizational communication if all groups are to find value in the new system. The classic example here is the relationship between marketing and IT. Marketing is concerned with authoring text and IT takes care of the system.
However, what is perceived as a priority to one department is rarely a priority to the other. In many cases IT chooses a CMS without participation from the business units, such as marketing, or business units in turn have abdicated their responsibility to participate in system design.
Operational challenges can continue throughout the life of the project. One failsafe method to build distrust towards a CMS among authors is to let IT execute a system upgrade in the midst of the process of producing websites, which usually sets back work and creates confusion as to what pages are truly finished.
Preventing a bad rap
Preventing a bad rap means putting energy where you can make a tangible difference to most authors. It is impossible for any system to become ideal for all authors, and as project manager it is equally impossible to prevent all negative experiences with a new CMS. But the potential for a poor reputation and bad vibes can be minimized by a savvy CMS project manager who pays careful attention to the critical early stages of the effort. Here's how:
1. Get contributor feedback at the outset
At a minimum, you should alert authors to alternative tools under consideration and get their input into the inception phase of a project. Ideally authors should sit in on vendor demos. This way it becomes visible to a broader audience that no single system will abate everyones' pet annoyances, and consequently, contributors will be less likely to blame the system (or you) when inevitable glitches arise.
2. Invest in usability
There are no usability standards that all CMS tools follow. And because different enterprises bring different processes and understanding of what it means to manage content, CMS usability is situational. However, most CMS interfaces can be optimized, and it is worth considering the benefit of investing a bit in this part of your implementation.
You have several opportunities to save your authors' time:
-
Apply intuitive wording
For part-time authors learning a whole new vocabulary to work in a CMS is not the best use of their time. If the software employs many proprietary words for commonly used functions as "edit" and "publish," you should investigate changing them to save you from answering the same questions repeatedly. -
Allow default settings for common author situations
Make it easy to choose the right content type, template, and workflow. If most authors should only create content in one template, then make sure that it is impossible to accidentally choose the wrong one. When contributors can navigate through options via either list or a tree structure -- but they consistent elect to use the tree structure -- this should become the default presentation going forward. - Reconfigure drop-down-lists
These should always be sorted in a way that makes the most frequently used choices the first ones available. The all-too-common alphabetical list sort is rarely the most efficient way to navigate. -
Build in answers for common problems
To reduce support calls, measure and address the most frequent problems. Many tools offer the option to add or modify help text on various screens. Testing a system function by function is not the same as using it to build a real web site. Getting developers to work as authors for one or two days might be the easiest way to bridge the gap between user needs and development priorities. -
Cut the clicks
Reducing the amount of clicks needed to perform common tasks and finding the most intuitive way to present a list or navigation tree will eliminate much contributor frustration.
3. Build Community
Sometimes project managers fear the advent of an organized group of contributors, misapprehending that their collective power will make the project more difficult. In fact, the opposite is true.
A community of authors and editors can more effectively and openly elevate legitimate gripes, and provide you a more efficient forum to communicate challenges and opportunities to the team. If contributors are complaining to you first, you can contain negativity before it totally snowballs. A real community can also facilitate peer-based learning and support; messages and suggestions from you will never work as well with authors as those from their peers.
A community among part time authors rarely happens by itself so you may need to provide a structure for it. A typical community-building toolbox contains:
- Regular meetings or phone conferences for discussing and sampling features and challenges faced by different authors
- Newsletters on best practices and success stories among the authoring network
- Regular distribution of relevant statistics with concrete suggestions for improvement
- A sounding board where common problems and issues can be addressed -- open and honest communication is critical here.
4. Arrange for decent support
Availability when your authors need you and providing quick answers keeps frustration from building up. Therefore, a support organization should build explicitly on your contributors' needs and prioritize authors' problems.
Part-time web authors are likely to work odd hours on your project. Being available on a hotline number for a few hours after regular office hours doesn't have to involve a lot of work, but it will yield much good will and prevent small frustrations from escalating to a level where bad vibes start spreading. Remember that time differences between offices -- even just one hour -- define the time frame for support availability.
Create FAQs on an ongoing basis by shortlisting the most common questions you get and sending out updates of them is an inexpensive way to keep authors informed. It will also help you track which problems and questions that are eating the most time.
If you cannot customize a task-based user interface, then at least publish a task-based content management guide. Make it possible to work in the CMS without knowing the whole system. This means creating a manual for authors that describes working in the CMS task-by-task: "creating news," "add hyperlink to information box," "place product description on product," and so on.
5. Communicate effectively
Above all, steer expectations realistically. Authors will discover the limitations of any system eventually. Stay candid about what the CMS will require, rather than selling a rose-tinted vision. Most authors can accept an imperfect system if they haven't wasted their time envisioning something that proves infeasible.
Reporting honestly on system development, set-backs, and successes alike positions you as someone to trust and your project as an important one. Authors should be the first to know when something new or unexpected happens that affects their work. It allows them to plan, and shows them that you respect their limited resources.
Bridging the gap between departments is an important part of protecting contributors' interests in any system upgrades and migration projects. Everyone associated with the CMS should receive your honest project reports regularly.
Cultivating a good reputation
Even if humans are prone to wallow in the setbacks of others, most colleagues like to be part of a success. When an author does something well, reaches a milestone, or comes up with a good idea, take the opportunity to let the world know about the success.
In the meantime, focus on solving practical problems for contributors, and a bad rap will not ruin your project.