management
Top Ten Mistakes in
Content Management By Rahel Anne Bailie, Associate Fellow
Y
our department, or more like-
ly your organization, is knee-
deep in content. You have
planted the single-sourcing
seed, and the beanstalk has
sprouted. You know it’s time
to take your department processes to
the next step: content management. But
unlike Jack, who found himself wrestling
with a hostile giant, you’d like to skip to
the part where you bring home the gold
and live happily ever after.
Perhaps it’s wishful thinking to assume
that, like the fairy-tale hero, you can
wrestle the giant and emerge unscathed
from a content management (CM) proj-
ect. But you stand a better chance if you
have a solid plan and knowledgeable re-
sources to draw on. I haven’t seen any
research studies explaining why CM
implementations fail, but I’ve spoken to
many business analysts, CM consultants,
information and technology (IT) con-
sultants, practitioners, and clients, and
I keep hearing the same dozen or so
reasons. Here are the top ten mistakes
to avoid when implementing content
management:
10.
Ignoring the big picture.
Just because a content management
system (CMS) is being implemented
for the benefit of one department—
say, technical documentation—doesn’t
mean it’s a departmental project.
Content management is a strategic cor-
porate direction. Today, the department;
tomorrow…well, let’s just say it’s not un-
usual for a corporation to discover that
18 March 2007
there are multiple systems—content
management, document management,
knowledge management, records man-
agement—operating across the compa-
ny. All of these systems eventually need
to share data.
Implementing a system that won’t ex-
tend, scale, or interoperate isn’t good
for anyone. For example, consider the
service department manager who chang-
es strategy mid-project by choosing an
XML CMS because he wants to incor-
porate content from technical manuals
into an existing knowledge management
system. Even with two XML systems, he
later discovers, the interoperability isn’t
as automatic as he’d hoped.
The business analysis skills that focus
on the bigger picture are hard to find.
Users tend to focus on the immediacy
of their tasks; developers tend to be daz-
zled by the technology. It’s important to
have a project leader who keeps sight of
business objectives and the consequenc-
es of implementation decisions.
9.
Conducting a cursory analysis
of your requirements.
Best practices for any kind of technol-
ogy project start with figuring out your
organization’s business goals. There
may be plans afoot in other depart-
ments or at the executive level that will
affect your strategy; some organizations
implement systems without realizing
that other systems are already in place.
At the other end of the spectrum, an or-
ganization may come up with a solution
that is inappropriate for the task. It’s
not uncommon for technical commu-

Implementation
nicators to have a Web CMS or a code
control system provided to them, with
the misguided expectation that such a
system will be able to generate technical
documentation.
Frequently, the stated business re-
quirements only scratch the surface of
CM’s potential efficiencies. At one cli-
ent site, a costly and time-consuming
manual process that could have been
addressed by CM software wasn’t in
the requirements document. Luckily, I
noticed this omission before the proj-
ect got too far down the road. If such
requirements aren’t caught until after
implementation, the organization will
be reluctant to spend the funds to re-
configure the system.
8.
Underestimating the time
needed to figure out the
content.
Many organizations underestimate the
number of places content is used, the
number of forms it takes, and its com-
plexity. A healthy mix of technology and
auditing is needed to control content,
taxonomy, and metadata strategies.
Content migration is a classic area
where resources are underestimated.
Content owners will have problems con-
verting even the most orderly content
if it’s not in a truly structured format.
Cleaning up the language, topic, docu-
ment, and taxonomy structures are im-
portant steps in adopting a migration
strategy. Standardizing content will help
automate the mass migration of content,
but is that the best strategy? Should you
instead choose an arbitrary cutoff and
convert all the content developed after
a particular date, product version, or
other corporate milestone? Or should
you follow an 80/20 rule, converting 20
March 2007 19
percent of the content while importing
only what you need from the other 80
percent? The options are many. Your
strategy should probably combine re-
evaluation of content, automated con-
version, and brute force.
A CM project is actually several sepa-
rate projects: an input project, a stor-
age project, a workflow project, and an
output project. Once the content is in
the CMS, the next steps are to discuss
options for storing the content for in-
tuitive retrieval, routing the content
through the various stages to approval,
and publishing content to multiple
channels. Figuring out the many ways
content will be managed is critical and
takes time and thought.
7.
Skipping steps in the process.
It’s likely that management has identi-
fied a specific need (“We’re launching
in the European Union by end of next
quarter and need content in all of the
twenty official languages”) paired with
a general technology solution (“Our
competition uses a content manage-
ment system.…we read about it on the
Internet”), and set an arbitrary deadline
(“You need to produce multilingual
manuals, online help, and catalogues
by the time the software is ready for re-
lease”). It’s very tempting to skip over
one or eight of the necessary steps in
order to meet unrealistic deadlines. Do
your executives recall the enterprise re-
source planning (ERP) implementation
disasters of the 1990s? Perhaps they need
to be reminded. Without going through
each step of the requirements analysis,
you can’t complete the content analy-
sis. Without going through each step of
management
the content analysis, you can’t complete
the technology analysis. Without going
through the technology analysis thor-
oughly, you can’t complete the selection
and implementation phases.
The missing steps must be complet-
ed somewhere. When the work is not
done up front, the vendor—racing to
get the software configured for installa-
tion—recalculates the integration costs
and throws a few more consultants on
the project. The consultants will work
with whatever information they have
and whatever they think to ask for. If the
requirements and content analysis were
not done thoroughly, the consultants
will gather whatever information they
can within the allotted time and budget,
and do their best. You’ll have to settle
for what you get, not necessarily what
you need.
6.
Picking the software with the
most features.
Open a conversation with the ques-
tion, “Here’s how I want to reuse con-
tent—what’s the best software to do this?”
and you’ll be a sitting duck for predatory
software vendors. Overemphasis on fea-
tures leads to feature comparisons that
yield little substantive value; you’ll likely
get very similar results among vendors.
The difference becomes qualitative. Yes,
all the vendors have spell-check, but how
does their spell-check work, exactly?
Can you do a global spell-check, or does
it work just within a folder? Does spell-
checking include or exclude the code?
Yes, they all work with an XML editor,
but can you use any XML editor or are
you confined to certain editors, or only
their editor? Does their editor do any-
thing proprietary that will prevent the
management
XML from working properly in another
editor? How tightly are you locked in to
their editor?
It’s also important to learn the tech-
nologies behind the software choices,
the differences between them, and their
advantages and constraints. The CMS
“owners” of the technical side—and this
is particularly true when a system is be-
ing built or assembled—need to be the
technical developers. One practitioner
I’ve worked with asserts that it took
several projects for his developers to
become comfortable with CM concepts
and productive when developing new
features and upgrades. Organizations
that don’t have the time or technical
expertise to make informed decisions
about a vendor’s technology will benefit
greatly by bringing in a consultant.
5.
Choosing the most economical
software.
It’s easy to be put off by high CMS
price tags or seduced by the lure of
open-source software. However, CM is
a long-term investment and needs ap-
propriate support; the cost of the ac-
tual CMS software is a small part of the
overall cost of ownership. In the debate
between buying a commercial system
and using open source, weigh the long-
term repercussions of each. With open
source, you’ll never know the road map
and getting support will be a very in-
formal process; but it could be a good
option if you have a bank of developers
who can navigate that landscape. Lesser
known vendors may not handle unex-
pected glitches—and there are always
unexpected glitches—or performance
problems with the timeliness of more
established vendors. In one memorable
situation, a client chose a system that,
on the surface, cost ten times more than
the least expensive software; to arrive at
this decision, the client weighed the cost
of implementing the more costly system
with the calculated cost of the other sys-
tem, plus the following:
• Development costs for the system to
meet functionality requirements
• Costs of tying it into the client’s exist-
ing systems
• Costs of customizing the CMS
20 March 2007
• Costs of maintaining (and upgrading)
these multiple systems
The client determined that, in the
long run, the most cost-effective sys-
tem was the more expensive one. This
doesn’t automatically mean that the
software has to be costly—but don’t
make your choice based only on the
price tag.
4.
Underestimating your
relationship with the vendor.
You use the applications on your desk-
top without giving a second thought to
the vendors behind them. In contrast,
your relationship with your CMS ven-
dor is likely to be on a first-name basis.
Much like you’d check out a prospec-
tive marriage partner, think of whether
you’d want the vendor as a member of
the family. Verify the expertise level of
its developers, check its compliance-
to-technology standards, and take a look
at its market saturation. Understand the
vendor road maps and make sure they fit
where you’re going. Also, examine how
the vendor supports its users. Does it
have an active online user group and an
annual user conference? Call references,
attend user group sessions or conferenc-
es, and call the support line and pretend
to be a customer to see how the vendor
deals with you. Read the vendor’s user
documentation and determine whether
it’s usable or just a transcript of develop-
ers’ verbal techno-speak.
The mark of a good vendor goes be-
yond software with a rich feature set.
Using a vendor that has poor documen-
tation or unfocused training could re-
quire a lot of prior knowledge on the
part of your CMS administrator. That
might work when you have an experi-
enced administrator taking over, but
not when your administrator is simply
the most technically inclined depart-
ment member you can find. For ex-
ample, I worked with a vendor whose
instructions explained many ways to
delete the database, but didn’t explain
the ramifications of each method. The
user was left in the dark about which
method to choose, or whether deletion
was even a good idea.

3.
Underestimating the
challenges of change
management.
Change management is said to con-
tribute significantly to the success of a
project, but a project’s focus is generally
on technology instead of the people us-
ing the technology. Getting buy-in and
assessing and upgrading the skill sets
of the users are key aspects of people
management. It’s important to give staff
enough time to make the mental adjust-
ment, but you don’t want the project to
drag on so long that staff get discour-
aged. Because the regular work-cycle
continues while the implementation
progresses, there will come a time when
duplication of effort becomes a real risk,
potentially demoralizing your staff.
A common temptation is to port exist-
ing processes into the CMS. This works
when those processes are efficient, but
migrating dysfunctional processes only
codifies them. For example, in one proj-
ect, a business goal was to decentralize
content creation, which turned out to
compromise the quality and consistency
of content; when that fact was discov-
ered, the process was changed to cen-
tralize content destined for the Web.
2.
Going over budget—way over
budget.
CM projects often go over budget, as
the magnitude of the task reveals itself
with time. In some organizations, the
budget is deemphasized for political rea-
sons. Sometimes the budget consists only
of the software cost. Other times, an arbi-
trary number, often unrealistic, is hand-
ed down, and the recipient runs with it.
Also, the company may want to include
ongoing costs such as annual support
costs, which are usually around 20 per-
cent. The question is not so much why
the project goes over budget, but by how
much. Can the expense be justified?
Keeping in mind that the software cost
is actually a small portion of the overall
project cost, how do you calculate the
total cost? One executive I’ve worked
with reports that the total cost of a com-
plex project over a period of four years,
including labor, has been fifteen times
the cost of the software. This cost is in
March 2007 21
It’s important
to learn the
technologies
behind the
software choices,
the differences
between them,
and their
advantages and
constraints.
line with the value the project has re-
turned—when the cost of licenses, serv-
ers, infrastructure, content migration,
consulting fees, development, and other
integration costs are factored into that
amount. Another way to anticipate the
long-term budget is to do a pilot project
or proof of concept before launching
the full project. The smaller scope gives
you a benchmark against which to esti-
mate the budget overrun before it hap-
pens. Some of the variables will depend
on the complexity of the system and
the workflow being implemented, the
state of the content to be migrated, and
organizational readiness (appropriate
infrastructure and staff skills). There is
no industry ratio of software-to-project
costs, as the circumstances are highly sit-
uational, though some industry analysts
say that five times the cost of software
isn’t an unreasonable expectation.
management
1.
Taking on the content
management project in your
spare time.
Remember the days when you could
build a Web site with a little bit of HTML
code and a place to put the files? With
today’s sites, you need a night course
just to understand the security consid-
erations for the Web services running
over the code that powers the CMS
that runs the site. Learning all the got-
chas of CM is a full-time job. You can’t
learn them by reading a book, and you
can’t do it part time in addition to your
full-time job. Almost all success stories
of do-it-yourself CM implementations
involve technical- and executive-level
team members who have been through
a prior implementation. In one notable
setup for failure, a development direc-
tor gave his documentation manager
the mandate to read a book and figure
it out for herself because their corporate
culture didn’t allow them to ask for con-
sulting help. Three years later, they’ve
never asked for help, and they still don’t
have a CMS.
Of course, each of the reasons why
projects go wrong come with a flip side—
ways that projects go right. Turn each of
these steps on its head, and you are well
on your way to project success.
Rahel Anne Bailie heads Intentional Design,
where her drive for efficient ways to manage
content drove her to use content manage-
ment technologies as a way to improve the
performance of communication products.
She combines over fifteen years’ technical
communication, usability, and information
architecture experience, with as many years
of business-to-business and management ex-
perience. She has also developed courses and
taught on content development and informa-
tion architecture topics in several continuing
studies programs around British Columbia’s
Lower Mainland, and has spoken at count-
less conferences on various topics related
to content management and performance
improvement. Rahel is actively involved
in the Content Management Professionals
Association and the Society for Technical
Communication, where she is an Associate
Fellow, and keeps current with memberships
in the other disciplines that intersect to im-
prove the various aspects of user experience.