By Rahel Anne Bailie, President, Intentional Design Inc. for TheContentWrangler.com
Lately, I’ve found myself talking about content management tools – specifically, the functionality of software meant to manage product content. By product content, I mean everything from data sheets to user guides, installation manuals to maintenance manuals, product inserts to online product descriptions, online help to knowledge base contributions, the type of information products that typically fall within the domain of technical communication departments.
These conversations tend to begin with ways to make the right choice when buying a CMS. The focus may shift to making sure that the features for translations will support double-byte languages, or whether the check-in and check-out features will prevent two writers from editing a file at the same time, and inevitably becomes a comparison of a system’s feature set.
This week, I created a listing of over one hundred functionality points, by vendor, in a side-by-side comparison. There were only a handful of features that one vendor or another said they didn’t have, or didn’t currently support. Import multiple file formats? Yes. Got spell check? Yes. Keep an audit trail? Yes. Allow re-use of content chunks in multiple documents from a single source? Creates outputs for multiple channels? Supports XML? Yes, yes, and yes again.
When we put together a Request For Proposal (RFP) for a client, the features we request reflect the requirements of the organization. Realistically, however, meeting the publishing needs of the typical department producing product life cycle content can be extrapolated from a generic feature superset. Of course, this is somewhat of a gross generalization, but the reason for this will become clear in the next couple of paragraphs.
Checking the feature set is important, but that’s only a fraction of the exercise. If all of the packages do the same thing, what are their differentiators? How can you tell which of the systems is right for you?
The first critical question to ask is whether the functionality is built in, or whether the software needs to be customized. It’s easy for the vendor to answer that yes, their system can do that, and for the vendor to forget the little phrase that makes a big difference: “with customization.” This means that they can figure out how to create the feature the potential client wants, by writing some extra code. The implications generally include extra cost, extra time, and extra effort during the debugging phase, which needs to be put on the table for discussion during the technology analysis phase.
The next question to ask is how each software package handles each feature. When a CMS claims to support XML, does that mean it stores the content in a native XML database or that it only exports to XML? Can it round trip XML – in other words, if you import XML content from the repository and manipulate it, can you easily save it back to the repository, or does the software add code that makes the round trip a painful experience? When the vendor says that their software has spell check capabilities, does it mean that you can spell check by content chunk, by folder, or globally? If it does a global spell check, does it check only the human-readable content or does it go through the code at the same time? In other words, could you inadvertently change code if you do a global search-and-replace?
Vendors generally play their cards close to their chests, not elaborating much in their answers to RFPs. It’s almost as if they assume that whichever way their software works, we’ll consider their method is a shortcoming, so by keeping quiet about how their features work, they’ll make the short list. Or perhaps explaining how their software functions takes too much work. [You have to appreciate the humor in that last statement. After all, shouldn’t vendors be able to use their own content management tool to store descriptions of each of their features that can be used to populate RFP responses?]
It’s a shame, really, that vendors take a defensive stance; at some point, the client is going to find out how the system works. It would be better to know before installing a system you wouldn’t be happy with, right? Or is the idea to get a client to adopt the software at any cost, with the expectation that the adoption and switching costs will discourage the client from going to another vendor?
Before I’m accused of tarring all vendors with the same brush, let me say that I have encountered vendors who are completely up front about how their software works. They take the stance that if their CMS is a good fit, they want the client; if their CMS is not a good fit, they’d rather know up front, before everyone puts lots of energy into trying to make a match that’s not meant to be.
This is where it becomes the buyer’s responsibility to become educated about how content management systems work. Whether the buyer gains the expertise personally or by bringing in a CM consultant, someone with a knowledge of the industry should be involved. There is no absolute best way for a feature to work, but there are best ways for a certain set of circumstances. The aim is to make the trade-offs that will support a particular set of publishing processes by understanding not just what the software can do, but how the software does it.
About the author:
Rahel Anne Bailie operates Intentional Design Inc., a Vancouver, BC consultancy focused on content management, content development, and user experience services. Bailie has many years as both line staff and management in technical communication and usability environments, and her perspectives, both about content use and staff management are informed by her experience and studies. A self-identified geek, she is drawn to technology like a moth to flame, and works hard to stay current with the technical side of content management. She is a member of CM Pros, IAI, UPA, and the IEEE-PCS, and an Associate Fellow of STC.
