Tony Byrne Interview

In: Interviews

By Louis Rosenfeld

Published on October 31, 2005

Digital Web Magazine: Tony, what question are you surprised you’re not asked more often?

Tony Byrne: People rarely ask me the really obvious question about content management systems: “Should I really do this?” Meaning, “Should I really implement a CMS?”

Maybe by the time they find me they’ve already justified a CMS project to themselves and their boss. But the more I talk to companies, the more I feel that their real business problems concern content—their content sucks, or there’s too much of it, or too little or whatever. You can get people to acknowledge that, but in the back of their minds they keep some hope that a CMS will fix their content deficiency, or at least help fix it. Certainly, some corporate cultures require a major technology project just to justify shaking things up.

The good news is that you can find a lot of lightweight tools (WebDAV servers, authoring and collaboration tools like Macromedia Contribute, etc.) that can help automate your processes short of getting a full-blown CMS, giving you time to get your content house in order.

DW: I would also imagine that people contact you to ask who the right vendor would be.

TB: Well, people sometimes hope that I can tell them exactly which CMS to buy. They want to short-circuit a selection process, and I can kind of understand why. For most companies, a selection process entails looking at myriad confusing demos and fending off dozens of sales calls.

I try to convey that you can save time, money, and get the right solution by going through a proper competition. The trick is to develop meaningful scenarios that can allow you to take the most important step in the process as early as possible: testing the products in a hands-on way with real users. Don’t buy any solution from a vendor who won’t let you do that in one way or another.

DW: Content management, meet user-centered design. I’m glad to see this beginning to happen.

TB: User testing isn’t a walk in the park, especially when you ask content contributors to take the time to evaluate more than one offering (which you should do). They might find it a hassle, even though it’s clearly in their interests.

It will focus their minds and allow them to finally articulate just what they want and truly need with concrete examples from real software. This puts accountability back in the hands of the people who are going to use (and likely pay for) the system. It also greatly multiplies prospects for broad adoption, which is one of the most meaningful, quantifiable measures of success.

DW: Are there other questions you’re hearing more frequently?

TB: Yes, from line-of-business employees I frequently hear, “Just what is enterprise content management, and why is it ruining my day?” The enterprise has legitimate reasons to pay closer attention, but the way it can play itself out in these still-early days can cause a lot of grief among Web managers and information architecture (IA) people. Just as they start to gain ascendancy in these projects, a bunch of “enterprise” specialists come along and blow away some or most of their plans in favor of centralization, sometimes under the mantle of enterprise architecture.

DW: Why exactly is it that they’re able to blow away others’ plans? Or that they have “enterprise” in their job titles? Is it that they have language that sounds more impressive when it comes to discussions of enterprise issues? Is it that they can point to some fancy Zachman diagrams? Or is it that they’re already a part of IT, which gives them the keys to the kingdom?

Although I’ve personally invested a lot into the term “enterprise IA,” sometimes I think we’d be safer using the terms “strategic IA” and “strategic CM” rather than the “enterprise” appellation. Might help those good plans fly under the radar a bit longer.

TB: Yes, I sometimes find that she who assumes the mantle of “enterprise” tends to win because it sounds more important and on the side of the business, as opposed to on the side of a parochial department. I think you’ll see the same problem with “strategic.”

Here’s what I think is going on. On the one hand, we are seeing centrifugal information forces in the enterprise—the explosion of content, unprecedented automation, personal publishing (including blogs), and the proliferation of new file formats (for example, .PPT is huge now). On the other hand, there are legitimate centripetal forces that call for central control—enterprise liability, legal discovery, public disclosure, and regulatory compliance, as well as a desire to be consistent communicators across multiple channels and departments.

We need new covenants between enterprises and individuals (or departments) over who is responsible for what, and what the relative freedom of employees should be when it comes to content. Very often, this debate comes in the discussion of the relative merits of different software packages rather than being addressed head-on. Sometimes enterprises believe they will be more successful if they just put the clamps down—and they are encouraged in this regard by some vendors—but then come to the realization that it is counterproductive, if not impossible, to control all content from the center. To be sure, this can be situational. You will never see public blogs at pharmaceutical companies like you see at technology companies.

DW: Do we need new covenants for all aspects of content management?

TB: No, I would make a distinction between content processing and content publishing. They both fall under the rubric of content management today, but they are very different things. And vendors tend to be good at one, but not the other.

A processing scenario could be scanning and indexing forms from customers, putting them through a workflow or some other business process, then making them available to a customer relationship management (CRM) system, archiving them, retrieving them as necessary, then destroying them.

A publishing use case might have a knowledge worker drafting a case study, getting feedback offline and collaborating with others on the document on a shared drive, then putting it into a formal approval workflow, then having print and web renditions, plus syndication.

The former, processing, lends itself well to centralization because it emphasizes standard processes which can and probably should be rationalized across departments. It often involves non-salary staffers whose job is to follow standard procedures and perhaps recognize when certain content falls outside the norm. A vendor like FileNet is geared to this use case.

The latter, publishing, tends to follow a lot of informal rules and departmental norms, and—in successful companies—is very customer-driven. The enterprise is explicitly relying on the judgments of knowledge workers and their understanding of the customer. It is often counterproductive to standardize formats, processes, and content models here. A traditional web content management vendor is ideal for this use case.

In both cases, content is being managed. Both involve repository services, workflow, and some notion of records management. But to call them both “content management” obscures big differences.

DW: I think you’re really onto something quite important here: Neither centralization nor local autonomy provides The Answer. Instead, we need hybrid content management strategies that require us to examine which content and processes to centralize and which to leave in local hands. This is subtle stuff, perhaps too much so for many enterprises to tackle. Is this why content management projects are so tricky?

TB: Yes, it’s just one reason. I think enlightened enterprises are beginning to realize that they need multiple document management and content management systems—some geared toward control, the others geared towards facilitating loose collaboration. It’s like the difference between EMC Documentum and Microsoft SharePoint, which coexist today in a lot of large companies.

DW: Why else do CMS projects frequently come up short?

TB: There are plenty of other reasons. First, the software is still deceptively complicated and things always go wrong. The question is: Is your team prepared for bumps? If they tested the software first, their expectations are probably set.

Another reason content management projects are so tricky is the variety of disciplines involved and the difficulty in “handing off” requirements from one team member to the next. A lot of this revolves around nomenclature. For example, what does it mean to “publish” an “edition”? Different vendors and consultants will give you different answers.

In fact, when you bring in outside consultants and developers who don’t know your organization very well, just remember that they will inevitably have to make decisions about how the system works under the crush of the deadlines you gave them.

And finally, if no one has defined what success is, it can be hard to know when you are done. Many CMS analysts say you’re never done, and that’s true from the perspective of wanting to continually manage content better, but an experienced team will break down CMS development into a series of integral “builds” that are tied to particular business accomplishments that you can achieve and celebrate .

DW: How do you see user experience or IA professionals helping to reduce the hassles of content management projects?

TB: We need more people pushing to make things easier for everyone down the road, specifically by:

• Identifying three or four representative users and pushing for them to be part of the selection team, developing detailed scenarios (since no one else will) and advocating them as an alternative to checklist-heavy requests for proposals.
• Taking those representatives to end-user training at two of the finalist vendors, as our colleague James Robertson suggests.
• Identifying specific content types for vendors to implement during the vetting process. Bidders will appreciate this—it gives them something to sink their teeth into.
• Attending user group meetings for the finalist vendors and reporting findings back. This can be very eye-opening.
• Developing estimated budgets to identify the relative expenses of customizing the user interfaces of competing products for your needs. This too will be eye-opening to management.

DW: Tony, you’ve helped create a new professional association for content managers. Can you tell us a bit about CM Pros?

CM Pros was founded fundamentally out of envy over AIfIA (now IAI). A group of us sensed there was a large—if somewhat inchoate—community of content management practitioners, developers, and consultants, and we were frustrated about the lack of venues for ongoing discussion and sharing.

CM Pros has had the usual growing pains, but it is standing now, and I have high hopes for it.

My great wish, however, is that CM Pros can provide a more practical answer to the present divide in our industries between relativists and determinists. (I suspect there’s a similar debate in the user experience community—think Jared Spool vs. Jakob Nielsen). Relativists think that all content management systems must be unique because companies’ content models and business processes are unique. Determinists—and some CMS consultants fall into this camp—think that they have figured content management out and therefore one need only apply their governance, organizational, or technical model, and everything will be fine.

The right answer, of course, lies in between those two extremes. I hope that CM Pros can be a place where we could all work on analyzing models and patterns, then name them, and help vendors and users target them as mutually possible solutions. A public news Web site publishes to a very different rhythm than a corporate intranet and will likely require a different system architecture. The admin staffer who updates human resources pages is going to have rather different notions of usability than the mar-com executive who has to build a site for the annual report once a year.

We could enforce a single approach on all of them, or we could throw up our hands and say it’s all ad hoc, or we could start grouping and analyzing. I vote for the latter.

• Add to Magnolia
• Add to My Yahoo!
• Add to Newsvine
• Digg this story
• Add to Del.icio.us

Related Topics: Content Management Systems (CMS), Content, Knowledge Management, Information Architecture