Your IT person says Joomla. Your PHP person says Drupal. Your marketing person says SharePoint.

Let’s be frank: they are all buzzwords, and the person speaking to using that system usually has an ulterior motive outside of what’s best for the users. It’s like that Linux guy that likes Linux because it’s easy for him and no one else. Does that really serve the office?

If you have a Microsoft Gold Partner sitting in your office, he’s going to say SharePoint fits the needs for anything short of curing cancer even if MOSS is completely the wrong system. And frankly, all developers have their favorites, and sales people sell, regardless of what the product is. Mac vs. PC. Windows vs. Unix. Drupal vs. Joomla. They’re all religious wars, wars I’m especially tired of.

Every product has it’s merits, and should be judged on them alone, not on a salesperson’s preference. End of sentence.

What do you do?

Picking the right content management system is a make or break situation: it can cost you hundreds of hours in development time, and may result in a poorly done implementation that costs you business. I hear of horror stories where one CMS was ripped out in favor of another, because the first selection was made for reasons other than what’s best for the implementation. Yet time and time again, companies don’t correctly assess the requirements, and the content management system doesn’t even come close to meeting the needs of the client.

I’m suggesting the following points. These are basic product management type processes, but seem to be done in very few instances.

Collect The Requirements Before Selecting A System

What do you need? Is it an intranet? Do you require e-commerce? Are blogs a necessary feature?

Collecting the requirements before selecting the system is very important, because the requirements are going to drive which CMS to select. In fact, you should do this for every pre-packaged system: figure out what you need before you select the package.

That doesn’t mean that you should wireframe out every page; make a bulleted list of what features you need, and then rank them in importance. The truth of the matter is no matter what CMS you select, none of them are going to fit your needs 100 percent, so you are making a best guess selection.

Compare The Feature Set You Need To The Systems Available

All of the content management systems have a specialty: Joomla and SilverStripe good for smaller sites, Drupal is easily configurable, and MOSS handles governance very well.There are even sites dedicated to trying them out — Open Source CMS is a great start — so there’s no excuse to see what’s out there. The truth is that content management is the kitchen sink of web applications, and the feature set among them varies so widely that calling SilverStripe, SharePoint, and Documentum the same application is a farce.

Download the demonstration examples of each of the systems, and play with them a bit. Read the documentation. Talk to experts. Bring some of them in for a day and pay them. I know this will take a little more time, but this will be time well spent instead of the usual “we’re stuck with it because we paid for it.”

The reality is that whatever system you choose will have a certain cost, and that estimated cost at the beginning will be off by 20 to 50 percent, because you won’t know the real development costs until the system is selected and the feature set nailed down. Think of it as a highway construction project: bid just low enough to get the work, and then live with the overages.

Outside og using a Documentum or an Interwoven (and if you have that kind of cash, I’m available for consulting gigs tomorrow), remember when considering feature sets is that open source doesn’t mean free and a lower cost, it just means you’ll probably spend more time configuring it. It might mean no licensing costs, but more development costs. And some organizations might need a licensed product because with that, there’s this implied support system you don’t see with open source products.

Figuring out what you need is very important, because that will lead you to the next step.

Select The System That Best Fits Your Needs, And Design To It

Why do people use content management systems? Because there’s a bunch of built in functionality that normally would take years to build, and even longer to test. For example, no one wants to write blog software anymore because there are several CMS applications that do a very good job. Why re-invent the wheel?

And the price for that functionality?

You have to do things in a way that are CMS specific. Every CMS has peculiarities that you wouldn’t expect (SharePoint’s CSS is heavy, Joomla’s UI is difficult, WordPress plays with a lot of content outside of the editor), and you should plan for them. They’re all frameworks, and frameworks have specific requirements, which means you sometimes have keep the requirements loose.

Or, wireframe to the feature set, and spend a little extra time evaluating the software, because it isn’t custom that can be built to almost any requirement.

I know this sounds weird coming from a User Experience professional, but you are wasting everyone’s time if you throw a temper tantrum when designing a feature that takes three times as long as using out of box functionality because the feature isn’t exactly how you want it. Especially if it’s an extranet or intranet. So don’t waste everyone’s time.

One of the things I did while working on SharePoint sites was designing page templates that worked with content types, and specifically called out web parts that occured over multiple pages. For SilverStripe, you might have to call out the navigation in a particular place, but form design is easy because it does the validation for you. For Plone, you might have to stay with a three column layout. It just depends.

The reality is, as an information architect or business analyst, you’re going to get 80 percent of what you want. If that means a 50 percent reduction in development costs for the client, that’s a good deal, because that means more projects. Sure, there’s less billable time for writing meta data documents and test plans, but a happy client is a good client, right?

I’m by no means a CMS expert (but I’m sure I’ll be launching into my four or fifth one this year). Here are some more resources:

• Content Here has a great series of posts of selecting one.
• Top 10 mistakes when selecting a CMS.