Content Management is sometimes just management

By David Walker (Google profile)

Hotwired founder Jeffrey Veen notes how the great management IT cop-out manifests itself in content management systems (CMSs): too many managers decide that if since there's something called content management software, they can just use that to automate the management of a public Web site.

Big mistake. Content management software enables the managing of content, the same way word processing software enables the processing of words. When you're writing words, your word management software matters far less than the decisions on what you write. So too in content management. What matters is what content goes where, how the user gets to it, what they can see, what they can do.

Jeffrey Veen's full article is here. Highlights:

Companies swallow the enterprise software pitch of decentralization. They think that by distributing content creation they’re empowering business units to manage their own areas of the site ...

I’ve spoken to a number of Web teams that have used a CMS with varying levels of success. One problem I heard repeatedly was that the project worked fine, but nobody used the software once it was available ...

So how come nobody actually uses these systems once they’re in place? ...

Even the most thoughtful projects may be misguided. Over and over I’ve heard the same complaint about these projects, "Turns out, after all the budget and time we spent, we really didn’t need a content management system at all. We just needed some editors" ...

Publishing is a skill set that most organizations have never needed, but one that’s integral to producing a quality site.

Bingo. Key processes need managers - owners, people with an intellectual and emotional investment in the process and the outcome it achieves. They work with their own staff and the rest of the organisation to achieve that outcome. They have a mission. Good ones have a vision. When you publish content, the person who manages that process is an editor, or a content manager, or a site producer.

(Veen likes the traditional "editor", which probably works if your site is Slate or Crikey. In many sites, "content manager" or "site producer" may better convey the role these managers play in crafting the user experience through not just through text but through navigation, imagery, interactive server software and everything else you can do on a Web site. Such a manager is to some extent an IT project manager, which is a long way from what a magazine editor does.)

Veen refers sceptically to "the enterprise software pitch of decentralization". As Google tells us, content management system vendors love telling prospects they can eliminate the "webmaster bottleneck". But this 60s-nostalgic flowers-blooming verbiage wilts under the glare of organisational reality. Companies, government bodies and non-profits are all established because they can do more as one disciplined organisation than they can as a collection of individuals. It is a necessary corollary of this that bottlenecks are often a good thing.

Consider a modern-day newspaper. Here the original content producers (journalists) actually are publishing-industry professionals. Yet those professionals are matched by a back-office team of editors and producers who impose discipline and enforce standards and make judgments. They're a bona-fide bottleneck. They're not a technical bottleneck; this has nothing to do with technology, because almost all newspapers have effective publishing technology. The back-office newspaper managers are there, bottlenecking away and getting paid by the profit-loving, paycheque-hating newspaper company each month, because publishing requires discipline and standards and judgment. As Web publishing expert Gerry McGovern puts it, "quality publishing is about saying no".

Because content decisions are hard work, asking individual departments to assume the full burden of this task on a Web site may have two not-so-obvious effects.

First, it may not save time. Someone still has to make decisions and exercise judgment. Individual departments probably know more about the subject, but less about making publishing decisions. So it's not actually obvious that you save time by moving the decisions from one point to another. In an organisation which doesn't hold people accountable for results, you may hide some costs. But you won't get rid of costs.

Second, a smart specialist who doesn't know much about making publishing decisions will probably back away from making them at all. If and when this happens, you'll find you're producing less content than you did when there was a bottleneck.

Mind you, that may be the right result. If the organisation can't justify giving the site an owner, it probably isn't very important. Strip it back to its bare essentials, update whatever needs to be update using simple tools and data feeds, and leave the rest alone. If you don't want to be a publisher, don't be. No existing law requires corporations to create or maintain thousand-page Web sites. To quote McGovern again, "many Web sites are still publishing content that is not core to their business.".

But have the guts to make a decision. Don't decide to be a publisher, and then pretend that software will make it all happen right. Old-fashioned management will and management discipline will make it happen right.