CM Pros Canada West Community Meeting Notes

How can content management projects go wrong: let me count the ways

1. Underestimating resources needed for scope of content migration. The options are many and should be a combination of re-evaluation of content, automated conversion, and brute force. A healthy mix of technology and audit is needed to control content and metadata.
2. Understanding the technological constraints. The CMS "owners" of the technical side need to be the technical developers. It takes until the third project or phase for the developers to really become comfortable with the concepts.
3. Purchasing a tool before requirements are set out. Have a project plan, bring in consultants with design modelling experience and have them work with best practices in mind, the take enough time to do usability testing for both the end users (if the CMS supports a Web site) AND for the authors, and train people just before they need to start using the skills they learn. And don't underestimate the cost or time it takes to migrate content to the CMS.
4. Not appreciating the depth of where and how technical documentation gets used throughout the organization. Rolling out a CMS for technical documentation is, in effect, several separate projects: a managing input project, a storage project, and an output project.
5. Using a vendor that has poor documentation and other support materials, or unfocused training, because they assume a lot of prior knowledge on the part of the client's new CMS administrator. Ask to see their support processes and support documentation before choosing. For example, one vendor's instructions explained how to set up access for authors in various ways, but didn't explain how to decide what the ramifications of each method were, so left the user confused about what to do.
6. Underestimating the psycho-social challenges in getting everyone on board. Assessing and upgrading the skill sets of the folks involved in CM is an important aspect of people management, along with getting their buy-in. The tendency is to engineer the software too much and the people too little, when it should be the other way around. Also, make sure the implementation is stabilized before letting users into the repository, as it's too frustrating not to be able to complete the publishing cycle, which can lead to unintended consequences.
7. Going over budget. Do a pilot/proof of concept before launching into the project full tilt. The smaller scope gives you a benchmark to estimate the budget overrun before it happens. Some of the variables will depend on the complexity of the workflow being implemented and whether existing content is already structured. Don't forget the twenty percent annual support costs, too. The complexity of the system (number of users, servers, etc.) tie into licensing costs, but there's no real fixed ratio of software to project costs. On one project, the total project cost (including labour) has been fifteen times the cost of software over a period of four years.
8. Bringing dysfunctional processes into the CMS. Bring improved processes to the table ASAP for the best chance to fix them. For example, on one project, a business goal was to decentralize content creation, which turned out to compromise the quality and consistency of content; upon discovery, they changed the process to centralize content destined for the Web.
9. Lack of content standardization. Content owners can range from Web or conent developers to business people from various departments, which can be handled with decentralized content creation combined with centralized approval. Content contributors must prove they have good writing skills. On the other hand, the restrictions of a CMS can keep people from trying to do import some of the content ideas that deviate from set standards.
10. Not grasping the big picture. Business analysis skills focusing on the bigger picture of content management are hard to find. Developers focus on the technology, and lose site of the business objectives and the related consequences of development decisions. Relevant factors could be: centralizing or decentralizing content creation, reducing head count (which never happens, though a realistic goal is for staff to spend less time on publishing and more time on their core work), quality control of content, technological compatibility with existing systems or platforms, system flexibility.
11. Choosing a content management system based on price. The software cost is a small proportion of the total project price. Smaller, cheaper vendors may not handle unexpected glitches (and there are always unexpected glitches) or performance problems with the timeliness of a larger vendor.
12. Lack of due diligence in vendor selection. Don't get caught up in the survey wars. Look for a good development pool, support with user groups, standards compliance (XML is critical), and market saturation. Call references, attend user group sessions or conferences, call the support line and pretend to be a customer to see how they deal with you. Understand the vendor roadmaps and make sure they fit where you're going.
13. Not thinking through long-term implications. CM is a long-term investment and needs long-term support. In the debate between buying a commercial system or using open-source, weigh the long-term repercussions of each. With open-source, you'll never know the roadmap and getting support is very informal, so decide if you can live with that.