Know Your Requirements Before Shopping for the Right CMS

(Publishing Executive, 3/20/09, by Joe Keenan)

As many publishers have found out the hard way -- i.e., wasting their time and money -- identifying the right content management system (CMS) for your business is no easy task. As a prelude to a session he'll lead at next week's Publishing Business Conference & Expo in New York, CMS Forum: Identifying and Implementing the Right CMS for Your Magazines, Han Huang, principal and founder of Counterpoint Analytics, offered up some tips to help save publishers from the frustrations of a CMS implementation gone bad.

INBOX: What factors should companies weigh when determining whether to build or buy their CMS?
HAN HUANG: The first thing to do is look at their business objective. What functionality do they want on their site? Do they want blogs/forums? Do they want polls? What kind of reporting do they want? Do they want lead reporting? Look at what their Web site is trying to do -- what their business model is.

When they work out what that is and what functionality they want -- they literally want to list it out -- then it's a question of looking at CMS companies. Look at whether the build vs. buy question is favorable one way or the other.

For example, if all they have is basic article content, one could argue that they could build that themselves. But the moment you start wanting to have blogs/forums, it's pretty rare now that one could build it themselves. But there's a proviso on this: You have open-source CMSs. So it's not always a question of build vs. buy. You can actually get an open-source CMS. There's still a cost to it, and that's in development costs to integrate it. But essentially the short of it is: Know what your requirements are, know what your budget is and then shop around for the right CMS.

INBOX: What are the outside expenses that publishers need to budget for when implementing a new CMS?
HUANG: I'd argue that most CMSs are quite intuitive from an editor's point of view. There's not a huge cost there. The most significant cost generally with publishing is the development cost itself and the managing of it. It's one thing to get the CMS, but then you've got to integrate it. One thing to bear in mind is if someone's buying a new CMS, normally they're going to be doing a site redesign at the same time. It's pretty rare for someone to say, 'I just want a new CMS,' and then not use it on the front end. They normally get a CMS because they want to change something on the front end. There's a redesign process; it's not just about getting a CMS.

INBOX: In your experience, what are some common mistakes publishers make when implementing a new CMS?
HUANG: The first one is not laying out your requirements in detail. If you do that, you've got a road map for completion. The second one is the resources -- how you manage the execution of the project. Are you resourced properly? Most publishers implementing a CMS will outsource. It's very common to outsource the building of it and the integration because there's only one upfront cost for integration and redesign, which isn't the same as doing maintenance. Managing the outsource relationship; there's definitely a skill [required] there. If you get the wrong people to implement it or there's poor communication between the core people who are buying into it and the developers through the project managers, then that can cause problems.

And then you have some technical issues going live. A typical one that causes real problems is you have editors who are using the old CMS until the day it goes live, so managing the live date is quite tricky. It can get technical, but it's difficult to do the transition to live because sometimes editors have to double enter the content into both systems. And if there are any technical problems, then that can extend out. It's very common that as you approach the live date, it gets more and more complicated to execute it well. So the live date gets pushed back.

INBOX: What are the latest trends with CMSs that'll help provide publishers tangible ROI?
HUANG: First, from a user perspective I'd say Web 2.0 functionality -- blogs, forums, reviews. For users, especially younger users, social networking and interactivity is becoming much more important. They're moving away from the idea of just reading an article. Now for most publishing companies, orthodox print publication companies, it may be too early for social networking, but a lot of their users are using social networking. That's one thing that CMSs can provide -- relatively out-of-the-box solutions for those things. You don't need to build them yourselves. You have to tweak them, but you don't have to build them.

The next is reporting systems. Publishers are realizing -- some publishers, anyhow -- how to leverage their user information online, especially if they have subscriber databases. How do they monetize it? How can they not just provide clicks but qualified leads? CMS has helped with that because you don't have to build your own login and tracking system. It's already there. So it's easier to integrate with all the other functionality. You really don't want to have to build that yourself. Those two areas are the two opportunities on the revenue-generating side.

And then the other thing on the back-end, the trend is definitely toward open-source. In the mid- to low-range CMSs, open-sourced CMSs are incredibly competitive because you're not just factoring in the buying of the CMS, you're looking at the build and the maintenance.

Content on Demand

What do POD and digital have in common? Content on demand. What I mean by this, is that the modern consumer wants their content, and wants it now in whatever format they prefer.

As was repeated several times at the Book Business Expo hosted a few month's back, "content is king." How does this translate to the publisher trying to stay on top of the ever-evolving new media trends? How does this translate to the overwhelmed production professional trying to make all this work? It's very simple: let the consumer choose.

Develop good content, tag it with XML or whatever other format works for your CMS, and make the content available in all formats--simultaneously. Let the consumer choose whether they want to buy the book as a traditional print product; a pdf to be read on their laptop; or for their Kindle or Sony Reader (or whatever the next generation e-reader will be). Price these products appropriately, make it easy for the consumer to choose, and they will and will probably keep coming back.

It's obviously not that easy to get to that point, and this may vary from publishing sector to sector, but the more I read about what works and what doesn't, the more I believe it's really about "content on demand" and allowing the reader to choose.

Another example of this is in the educational market. Instead of professors having to create student reading packs to be copied and bound by the university copy center, they can now choose "custom" textbooks. Although only Wiley offers this now, I'm sure that others will soon too, since this is the "content on demand" trend at its best.

So for your given sector of the industry, what are the choices your reader is looking for and how will you make these more readily available to them?

New Web Authoring Tool

Since the web is here to stay, and publishing veterans can't necessarily learn all the new technology fast enough to help their companies compete, where does that leave them?

Aptara has come up with a solution, as Marketwire announced today: PowerXEditor, a user-friendly Google Doc-like web authoring tool that any publishing professional can use and that can be easily integrated into the company's current of future CMS.

Although being familiar with web basics is still necessary and helpful, user-friendly web authoring tools will help bridge the gap for those less tech savvy and will therefore keep publishing moving in the right direction.

"Management" Systems

I remember when about three jobs back, the company I was working for at the time invested in a "digital asset management system." Since they were a medical publisher who often reused images, this made sense. By the time I left the company, which was more than half a year later, several trainings had been held but DAMS, as they called it, was not up and running. I hear that they're finally using it.

At my most recent company, they invested in a "file management system" called K4. K4 is product supported by MEI (Managing Editor, Inc.) that is being used by more publisher all the time. It works with Adobe InDesign and InCopy and allows files to be trafficked via the K4 File Manager as opposed to manually, via paper, as was traditionally done.

After working with K4 for two years, I can say that there are pros and cons to this as to all content management systems. For the company I worked for, the major benefit was version control and file security: many little files and/or packets were being trafficked and often lost, necessitating work to be redone and more time and money spent. So in this sense, K4 allowed process streamlining and efficiency.

On the other hand, since the company was a custom publisher dealing with client demands and last-minute changes, and many non-tech savvy editors, in order to make a deadline we were often forced to revert to the tried-but-true paper trafficking. We were also a cross-platform company--editorial were on PCs while art/production were on Macs--which caused needless font and art problems.

I am still a proponent of CMS and held repeated K4 trainings for my staff and the rest of the editorial department. And although day-to-day workflow will be affected by deadlines, one should not give up on long-term efficiencies that can be improved with new technology.