the kdmcinfo weblog

Hundreds of journalists have moved through KDMC's digital media training programs, in which we show them how to produce cutting edge news content in non-traditional formats, from video to map mashups, custom widgets to slideshows, social media integration to standalone multimedia packages. Once the journalists return to their home publications to put their new skills to work, they often run up against technical "limitations" in their content management systems that prevent them from being able to publish certain media types to their sites. 

Many publications are sitting on top of content management systems that are either antiquated or weren't thought out well to begin with. Journalists may be told by their web teams, "Sorry, we don't support that kind of media" or "No, you can't use a custom template for your standalone package" or "We do not create custom database tables for data-driven reporting stories" or similar.

So journalists are being told, on one hand, "Go forth and innovate - we'll even pay for your training," and on the other, "Our systems don't support anything but simple text-based stories and images."  In these cases, technical limitations in the publishing system become the bottleneck limiting progress. But technology in journalism is not standing still, and publications that can't deliver new media content quickly and without friction will lose traffic to those who can.

To be fair, I know how complex content management systems can become. Some of them represent hundreds of thousands of lines of code, with delicate interdependencies that authors and editors never see. It can be difficult to make significant changes without affecting old content, or affecting related systems, or stepping on the toes of another department (like advertising). Not all CMS changes are easy, and I don't automatically blame the people who build and run them.

At the same time, there are many cases in which the technical staff is the problem. They may not realize how critical it is for the organization to have a flexible system, or they may lack the will to take on risky or difficult programming challenges. Often, management doesn't understand how the CMS really works, and may not be able to ask the right questions or give the right orders.

In fact, many organizations are dependent on the CMS of a parent organization. For CMSs that drive multiple publications, changes can have  even deeper ramifications on shared data structures, templates, etc.  In these cases, the publication may not have the ear of the decision makers who could make a difference, and control over the CMS is even farther removed, making change even more difficult, if not impossible.

The key is to ensure that upper management understands the real-world market ramifications of being saddled with an inflexible system. While the challenges of making CMSs more flexible are genuine, the expense of not doing so can be great, especially as smaller, more nimble news startups appear on the scene. Startups have the advantage of a clean slate, and are able to build new CMSs that are more flexible to begin with. They're able to learn from the mistakes of the past and get off on the right foot. Which means they can produce more innovative content more quickly and more easily, without having to work through multiple levels of bureaucracy to get things done. 

Here are the things I think have to happen to prevent or eliminate the CMS bottleneck:

• Decision makers need to appreciate the importance of providing modern, flexible publishing tools for their staff. Even if it means spending more on technology for a while.
• Web staff who manage CMSs need to work closely with journalists, not be cordoned off in the basement of a building in another state. Web staff need to be invested in the needs of the organization. Make sure web staff are working side-by-side with journalists - this should be a partnership, not an adversarial relationship.
• Someone with both knowledge and power needs to be in a position to respond to "NO" answers from technical staff. Often those "NO" answers are unfounded, and really mean "We've never done it that way before" or "That's going to be too hard."
• If you have the luxury of starting with a fresh CMS, consider building it yourself on top of a framework like Django or Rails. Frameworks are inherently more flexible and accommodating of change than off-the-shelf or custom content management systems.

Is the CMS a bottleneck at your publication? What steps are being taken to improve the situation?