Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

Making Your Content Management System Work for You: An Interview with Jeffrey Veen

by Christine Perfetti
on September 29, 2004

Adaptive Path’s Jeffrey Veen is a recognized expert in the area of
Web Design and Content Management Systems. UIE’s Christine Perfetti recently
had the opportunity to talk with Jeff about the reasons why many content
management systems fail and what designers can do to avoid the common
pitfalls associated with CMS installations. Here is what Jeffrey
had to say about his experiences.

UIE: You’ve described the web as a medium for
publishing content and recommend designers view and treat their public-facing
web site like a publication. Is this publication model a mindset change
for most designers?

Designers? No. Most Web designers still have roots back in the world
of print. They are familiar with editorial processes, quality content,
and visual design’s importance in communication. Most designers I’ve worked
with know how publications come together and understand their own role
in the process.

Most often, I find that businesses don’t treat their web site as a publication,
especially those organizations developing standard content, such as product
and service descriptions. Instead, they view their site as a software
project — a product that undergoes a development process and needs to
be "released". Parts of a web site development project work
this way, such as search engine upgrades. Yet, most users aren’t concerned
with these parts — they are focused on the content.

For example, I recently helped a company migrate to a new content management
system. In my interviews with the content creators, they told me that
problems, such as spelling errors and fact changes, required them to open
a bug-tracking system ticket. Once the issue was report, they typically
had to wait four to six weeks before the problem was "resolved."
Like many companies, they consider their web site a software project and
not a publication.

We’ve seen in our work with clients that many websites don’t
need a CMS to be successful. At what point should a development team consider
moving to a CMS?

For many companies, they should probably never consider installing a
CMS. After looking at the resulting implementations of dozens of CMS packages,
it’s pretty clear these systems are grossly bloated with complex features
few sites need.

Most CMS software evolved from the Document Management process, which
involved the development of large, complicated documents that hundreds
of people collaborate on. These Document Management systems were excellent
at enabling collaboration for situations like new drug approval or oil-drilling
exploration. These documents are often thousands of pages long, with a
complicated legal approval process. You don’t want to screw that up, for

However, 90 percent of the web sites don’t need the complex features
of a CMS. Most only need a way to move the page maintenance to the responsible
people. For example, if an organization wants the marketing department
to control the site’s press release area, the marketing folks need a mechanism
to get content online immediately, fix mistakes, and take down outdated
information. They don’t need to contact the technical services department
for this.

You’ve seen that most CMS installations fail within the first
year. Why?

For two reasons, really. First, a CMS is almost never a piece of software
that you can buy and start using right away. Rather, they are platforms
— frameworks for building custom content applications based on an organization’s

Second, the editors, writers, designers, and managers who run departments
are not software engineers. They don’t speak the same language as engineers.
They don’t know (or care) what the "content-module lifecycle parameters"

So a big CMS project gets developed as a software project rather than
an editorial process and the technical folks point fingers when it fails,
"Well, we didn’t have good requirements from the content people."
That’s not true. They just didn’t ask them the right questions.

The perceived costs have kept many development teams away from
installing a CMS. Does content management have to be expensive? Are there
inexpensive tools that provide robust content management?

That’s actually a pretty big misconception in the industry. Content management
isn’t a software problem at all. It’s a process problem. By solving process
problems, you often find you don’t even need software. Many companies
buy software thinking that it will fix their process problems. But that’s
like buying Microsoft Word hoping that it will make you a better writer.

Rather, development teams need to create a content strategy that answers
several questions:

  1. Why are we generating this content?
  2. Who is the content for?
  3. What is the current user workflow?
  4. How do we get the content into a database?

If development teams have good practices for answering the first two
questions, then it’s not important what database or template language
they use. Inexpensive solutions, such as PHP and MySQL, are fine for 90
percent of sites.

What factors should teams consider when choosing the right CMS
for their needs?

My most-frequent response to this question is, "What’s the absolute
least you can get away with?" Initially, teams should get the super-simple
solution working and, only then, start adding complexity.

What roles does the development team need for a successful CMS

Development teams should remember: a CMS installation is an editorial
project, not a technical project. The team needs an engineer, but only
as a consultant to provide reality checks. The most important roles on
the team are the editorial director and the metadata specialist. It’s
also essential to have a project manager to keep the project on track
and to ensure everyone who uses the CMS is involved in the process.

Many of our clients are currently trying to personalize the web
experience to create unique experiences for each user. Do you believe
there’s a need for content management systems to personalize pages?

This is another strategy that will result in a CMS project failing. It
is really hard to install a CMS. The CMS migration is expensive, intensive,
and risky. But so often, I hear from designers, "Since we’re tearing
everything apart for this project, why don’t we redesign and add personalization?
We can also get a mobile device strategy going and hook it into our accounting
systems." Suddenly, a project, whose purpose is enabling people to
edit web pages, evolves into a multi-million-dollar corporate web strategy

My advice is to do the simplest thing first. When that works perfectly,
do something a little harder next. Then just keep repeating. But the quicker
you launch something, the more internal buy-in you’ll start to get.

Adaptive Path has conducted in-depth research on the ROI of User
Experience. Do you have any recommendations for how a design team can
justify the investment in a CMS?

That’s a difficult question. It’s hard to measure the value of getting
your pages online quickly and keeping them accurate. Of course, there
is tremendous value as an out-of-date web site reflects terribly on an
organization. But measuring the value isn’t as easy as watching shopping
cart abandonment go down.

One major value of a CMS investment is the increase in employee efficiency
and efficacy. If employees get their jobs done faster because of a streamlined
process, then an organization will definitely save money. But, according
to managers that I’ve spoken with, saving money and making money are very
different things. Increased revenue shows up as a hard number on balance
sheets. Efficient employees don’t, at least not explicitly.

So your employees are empowered to do good work, they stick around longer,
get their job done faster and with fewer errors, and your web site does
a better job of reflecting your company’s leading position in the market.
Pretty good, if you ask me. I just can’t give you a dollar figure for
all of that.

Thanks, Jeffrey.