Knowing When You Need a CMS

This article is the first part of a three-part series on content management systems ( CMS). Content management is a large topic that can be quite confusing, and may bring up many questions: What can a CMS do? What do we need from a CMS? How do I make sense of all the CMS solutions available?

In this article, TechSoup will address how you know when your organization needs a CMS.

Content Management Systems

The phrase "Content Management System" means different things to different people. Within the context of the series, I will define it as a set of processes, applications, and databases that help an organization create, store, coordinate, and publish information in a useful format, in a timely fashion, and with a consistent method.

"Content" can be confusing too. For this article, "content" is meaningful information, established in a context and formatted for consumption by an audience.

Types of CMS

Within the CMS world, there are several different types of products, and different styles of each. Elements of various CMS styles can even be mixed and matched. This article will focus on Web content management, since that's what most nonprofits appear to need the most.

Web Content Management Systems (WCMS):

This subset of CMS emphasizes managing only Web content. Products vary in functionality, complexity, and range. (You can read more about WCMS in the " " article.)

Enterprise Content Management Systems (ECMS):

ECMS emphasize comprehensiveness. They are used to manage all aspects of an organization's content publication processes, including Web, print, and any alternative outputs. The products offer a good amount of functionality, complexity, and range.

Document Management Systems (DMS):

Technically, these are parallel to CMS, but they focus on documents (such as Microsoft Word files), and are more for internal use than for presenting content for public consumption. They vary broadly in functionality, complexity, and range.

Digital Rights Management Systems (DRMS):

These are also parallel or complementary to CMS. These systems only manage intellectual property rights information for any content that exists. They vary broadly in functionality, complexity, and range, but tend to specialize in areas where Digital Rights are a priority (such as music or video).

Asset Management Systems (AMS):

These are also parallel to CMS. These systems manage so-called content "assets" (images, video, audio, and other binary, non-textual content). They vary broadly in functionality, complexity, and range, but tend to be used in organizations where assets like these are numerous (such as photo agencies or graphic design firms).

CMS Styles

Hosted:

In this style, the vendor hosts and maintains the CMS, which frees the client from much of the administrative responsibilities and reduces the initial cost. On the downside, a hosted CMS reduces the amount of control the client has and results in larger long-term costs.

Commercial:

This means that a vendor builds a CMS application and sells it to the client, who is responsible for maintenance. The client has more control, but more responsibility as well. A commercial CMS is usually more expensive up front.

Nonprofit:

There are many CMS built for nonprofits, sometimes they're even built by nonprofits. These styles may be hosted or commercial, but they tend to include features that many nonprofits find useful.

Open Source:

As with any Open Source software, there is no cost to acquire the software. The client has a lot of control, a lot of responsibility, is reliant on the Open Source community for support. In general, the products tend to be poorly documented, and focused more narrowly in their features.

Evaluating Your Needs

To evaluate your need for a CMS, look at your own situation, not the available systems or what your peers are doing. Take stock of your content, the people that are dealing with it, any organizational difficulties you are experiencing, the source of those difficulties, and any associated problems you're having.

Type and amount of content

It could take anywhere from an hour to a month to identify all the types of content you have, but the idea is to do a quick pass at it and just rough out the broad types of content. Do you have articles? Collections of small pieces of information, like lists of resources, suites of product information, groups of service descriptions? White papers? Audio recordings of speeches or presentations? Instructional videos? Images, including photographs, diagrams, graphs, and artwork?

Consider how much of these types of content you have. For example, count the number of articles you have and the average length of each. For a list of resources, count the total number of resources and the amount of information you collect for each. What you're after here is a general idea of the size of your overall content base.

Once that's done, examine all your content to determine the general nature of it. Do you find that most of your content is of one type? Or do you have wildly divergent types of content? With an objective view of the nature and size your content base, it's easier to determine how badly you need a CMS, and what kind you might need.

Who is involved?

Take some time to understand the people, or more generically, the roles involved in your content processes. As above, do a quick pass to get a general idea. Usually, the roles are:

Authors:

Identify the types, or roles, of your authors. Who does the bulk of the content creation? Are your authors internal, or do they work all over the country? Is it a consistent group of people, or do they come and go? Are they dedicated to the task, or is it something they do on the side? Is there a team or a group of individuals?

Editors:

Who does most of the editing? Do the authors act as their own editors? Is there a team of editors? Is that a dedicated role, or is it something someone does when time is available? You can examine these questions on per-content piece level, as well as on a site- or publication-wide level.

Designers:

Who works on the design of any given piece or the publication as a whole? Are they technical people or artistic types? Is there a team or a group of individuals working independently? Is the designer or team also responsible for other design tasks in your organization?

Approvers:

Who's involved in approving something for publication? Editors, of course, but what about management? Legal? Partners?

Publishers:

Who performs the actual publication of the authored, edited, and approved content? Who releases the finished Web page to the live Web servers or the final document to the printer?

Where's the pain?

Next, take a look at how these people deal with all the content in your current system. How does your content move from authoring or acquisition, through editing and formatting, to publication and beyond. With a good sense of that process, identify the points that are causing the most difficulty.

This can often take longer than the first two steps. But it shouldn't be too hard: just ask around. Listen for the things that people complain about the most, and the things they most want to change. Look for work that seems to take much longer than you think it should or involves more people that you think it ought to.

Perhaps your article authors are tired of having to e-mail multiple revisions back and forth to their editors, and edits are frequently lost or garbled. Maybe your Web producers are reworking entire sets of HTML files just to fix a typo. The most common pain point is at publishing: your technical people have to take a lot of time to make finished content pieces available to your audience, and heaven forbid you should have to make a change after it's been published.

Hopefully, there are only a few very painful problems. It's tempting to identify every little problem that exists, but you're better off dealing with the top three or four problems (or even the top one). Once you address the main ones, you'll often find that the rest of them disappear or become manageable.

Take a look at your short list of problems, and you may be able to see a consistent theme. Often, it boils down to three themes:

Speed:

It takes forever to get something published, approved, or updated. There are long gaps between requests and when the work gets started.

Organization:

Tasks and content get lost in the shuffle. The processes are overly complex, hard to understand, or full of gaps. Things move along for a while, but then they stop, blow up, or fade away.

Effort:

People have to spend a lot of time doing simple things, or they duplicate efforts. There are tasks that aren't inherently necessary, or perhaps two people are doing the same thing unnecessarily (or one person has to do it twice in two places).

You may discover that you have all of these problems, or other problems entirely. The point is to be aware of them so you know what you're trying to solve with a CMS.

At this point, I'd like to debunk a common myth: Despite what you believe, whatever system you work with is not going to actually do the work. Systems, content management systems in particular, don't create the content, organize the content, make it pretty, put it where your audience can make use of it, or, for that matter, make use of it. All the system is going to do is allow you to manage that stuff; it's only going to do what you tell it to do. It seems self-evident, but often people think that the CMS is going to solve all their problems. No. The CMS is what you are going to use to solve your problems.

Knowing When You're Ready for a CMS

I'll go out on a limb here and suggest that just because some problems have been identified does not mean that your organization is ready for a CMS. There are three main factors to consider: technological readiness, publication readiness, and organizational readiness.

Technological Readiness

Take a look at the state of your technology today. What are you using to author, store, organize, publish, and present your content now? What's the condition of those parts, individually and overall? Does your organization have a fairly cohesive technology architecture and plan, or is it more haphazard? Describe it.

In the case of this question, it's easier to be specific, and you should do so. Your answer might look like this: We're authoring in Microsoft Word, storing the files on a Microsoft Windows 2000 file server, organizing it with a folder structure there, managing workflow by walking around and talking to people, and publishing via FTP to our Solaris/Apache Web servers.

If your overall technology is a big mess, a CMS will only make it worse. In that case, you should focus on cleaning that up and then revisit the CMS question. If the mess is strictly limited to the content management area, then a CMS may end up replacing all that, and that would be a good thing.

A good understanding of where you're at technologically will help you narrow your CMS choices. Trust me, you'll be grateful for any way to limit the field.

Publication Readiness

Examine the state of your content. How well is it organized? Is it easy for audience members to find what they're looking for? Does your categorization scheme serve you, your content, and your audience well? Can your content be presented consistently, or is it a jumble of formats and looks? Does each piece relate well to others when appropriate?

It's important to be objective about this. It's tempting to gloss over publication integrity problems and assume that a CMS will offer a quick fix. However, any problems that exist at this level will just be reproduced within the new CMS if you don't address them first. You don't want to wind up with a CMS that functions as a big, expensive, complicated band-aid. While you can address publication problems during a CMS implementation, you need to go into it with your eyes open and realize that this will extend implementation time.

With a good idea of your publication readiness in mind, you'll be better able to gauge what sort of system might be appropriate. Perhaps more importantly, you'll have an idea of the things you'll need address before you implement that system, or issues that may come up during implementation.

Organizational Readiness

This is another potentially touchy subject, but the fact is, if your organization is not ready for a CMS, they won't use it just because it's been implemented. The more objective you can be about facing the facts, the better.

That said, take a look at your organization, with an emphasis on your current content management processes. How formal are your processes, and how well does your organization tolerate an increase in formality? Are there a lot of checks and balances, with many people touching everything that happens, or does everybody do their own thing? Where is the drive to get a CMS coming from, the people who do the work, or the people who manage them? How does the upper management respond to talk of a CMS?

Consider budget and resource factors. Roughly how much funding is available or potentially available, and how would you secure those funds? How much time could people make available to work on a CMS implementation project? Who in your organization would own the system, and how do they feel about it? Where would a CMS project fit in your organization's overall priorities?

Perhaps most importantly, just how important is content to your organization at a strategic level? Is it something you're willing to invest in?

If the people who do the work won't use the CMS or you lack management support, funds, and resources, then your organization probably isn't ready for a CMS. In that case, you should focus on getting it ready, and then reevaluate your need for a CMS.

Whatever you discover here, it will inform whether or not you should get a CMS, what type you should get, and how you would implement it.

So Do I Need a CMS or Not?

At this point, you should have a good idea of what your content is, who's dealing with it, and the problems you're having. With this information, you can try to answer the question: Do we need a CMS at this point?

On the surface, it's easy to say, "Of course, look at all these problems I've identified." But the real question is whether or not a CMS will help you solve them.

Take a close look at those problems. It's easy to find problems, but more difficult to see how they came to be and harder still to solve them. How did your problems come about? Usually, they're a result of moving quickly and cutting corners. Often what's lost is process management and oversight. Do people in your organization avoid looking at the way they work because they already have more work than they can do? Have they been unable to take the time to address these problems because of deadline pressures? Perhaps it's just that no one's ever taken the time to examine it at a high level as you've just done, so the problems never surfaced in a cohesive way.

Identifying the source of problems is a good way to start fixing them. But before you decide on a CMS as your solution, see if you can address some of these problems through better management. If you have too many people involved in approvals, can you remove some? If it takes too long to get an article published, do you need to make a new position that deals with that task only? If there are too many steps involved in some task, how can you streamline it?

If you make a real attempt to solve these problems with what you have at your disposal today and find that the problems still exist, then you may need a CMS.

Consider again your organization's readiness. You may need to address problems with the way you use technology, your publication process, or your organization's commitment to content before you can really address the nitty-gritty of how a CMS might help.

Conclusion

Only you and your organization can determine whether or not you need a CMS, although there are consultants available to help you with that process. Visit TechSoup TechFinder: Find Services to find more resources.

A consultant is likely to walk you through the steps outlined in this article. You need to understand your content, the people that work on it, the way they work on it, where the problems are, and what your organization is ready for.

Finally, you need to have realistic expectations about what a CMS can do. It's not going to solve your problems; it's going to provide a mechanism for you to solve your problems. If you can solve your problems without a CMS, then avoid all the hassle and just solve those problems. If you can't, then by all means, look into getting a CMS.