Your Online Presence > Managing Content

Knowing When You Need a CMS

By Rob Prideaux, TechSoup

< Previous | 1 | 2 | 3 | Next >

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, and is reliant on the Open Source community for support. In general, the products tend to be poorly documented (although this is not always the case), and focused more narrowly in their features (for more on Open Source Software see the knowledgebase article Going With Open Source Software)

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 organisational 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 organisation?
• 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.
• Organisation: 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, organise 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 organisation is ready for a CMS. There are three main factors to consider: technological readiness, publication readiness, and organisational readiness.

Technological Readiness

Take a look at the state of your technology today. What are you using to author, store, organise, publish, and present your content now? What's the condition of those parts, individually and overall? Does your organisation 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, organising 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 organised? Is it easy for audience members to find what they're looking for? Does your categorisation 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 realise 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.

Organisational Readiness

This is another potentially touchy subject, but the fact is, if your organisation 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 organisation, with an emphasis on your current content management processes. How formal are your processes, and how well does your organisation 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 organisation would own the system, and how do they feel about it? Where would a CMS project fit in your organisation's overall priorities? Perhaps most importantly, just how important is content to your organisation 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 organisation probably isn't ready for a CMS. In that case, you should focus on getting it ready, and then re-evaluate 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.

Copyright © 2004 Compumentor

< Previous | 1 | 2 | 3 | Next >