Selecting a CMS
Recently I have been doing a lot of talking (and listening, and reading) about the challenges and strategies of selecting a CMS. On October 25th, Bryant Shea and I hosted Tony Byrne and Erik Hartman in a discussion about CMS selection on the latest installment of the Malcontents. Then, later in the day, we had a Massachusetts CM Pros Chapter Meeting on the same topic. That, along with countless one on one conversations I have had recently, makes two very obvious points: many people are out there trying to acquire a CMS; and many are struggling with this task. I have written on this topic in the past but it has been a while so I thought I would put some ideas down.
There are a number of reasons why selecting a CMS appears to be particularly challenging:
-
The CMS market is large (as in thousands of products) and chaotic with no clear separation between winners and losers. In fact, during the podcast, Tony made the point that there are many CMS vendors that are doing very well rather than a divergence between laggards and leaders.
-
Especially in Web Content Management, the software is really just a framework. If everything is configurable or customizable, how do you evaluate what you are looking at? A couple of years ago I bought a bike where the frame was custom built for me. As I was test riding different models, I was thinking "what is the point? Everything I like or don't like about this bike (every tube length, diameter, thickness, and angle) will be potentially different in what I will buy." Furthermore, in the case of a CMS, it is not always obvious where the "load bearing walls" are. That is, aspects that cannot be changed without compromising the product or major re-engineering.
-
Every potential customer's content management needs are slightly different. Content management is a ridiculously large topic to begin with. Even within a sub-discipline like Web Content Management, different companies will have different problems and different perceptions on how technology can address them.
-
Likewise, CMS vendors also have their own perspectives on the "content management problem" and how to solve it.
-
Most CMS products are reaching out to solve problems outside of their sweet spot. Either they are building capabilities to solve problems that they do not fully understand, or they look at the world through such a strong lens that everything looks like the problem they know ("if all you have is a hammer, everything looks like a nail")
-
Many companies looking for a CMS now are doing so because of one or more failed CM initiatives and, rightly or wrongly, have blamed technology. This raises the stakes in the selection considerably.
-
Solving a content management requires a very close partnership between the technology organization and the user community. Most companies don't have the right chemistry between these two groups. Typically, regardless of what is said, I.T. owns the software and the business owns the processes. In content management, it is impossible to separate the two.
-
Usability is such a critical factor in CM success. Bad usability causes users to either under-use or misuse the software. Most I.T. organizations practice software development methodologies that are not geared to usability. How many project plans have you seen starting with textual requirements gathering (that give no indication of what the software will be like to use) and ending with a short period of "usability testing" or "user acceptance testing?" The software development team leaves with a spreadsheet and returns with the final product. At this point, it is often too late and too expensive to make changes. Word to the wise: don't do usability testing if you are not prepared to respond to the feedback.
-
At any one time, most I.T. organizations are faced with multiple business units that are asking for tools to help solve content management problems. There is a natural tendency to try to buy one solution that answers all of these requests - no matter how diverse the needs are.
If you made it this far, you probably feel doomed. How can you be successful if you have this much working against you? Well, here is some advice that will make your life easier:
-
Cancel your Gartner subscription. There is no magic quadrant in CMS. What is important is your users and your content. The right product for another company, even in your industry, even another business unit in your own company, may not be the right product for you.
-
Don't focus on the feature lists. The software market has regressed into a conversation of checklists. Software vendors try to "check off" features that they think their customers will want or that their competitors have. Customers reading vendor brochures start to believe that they need these features. It's an ugly cycle that leads to bloated software and unhappy users.
-
Do focus on the "How." Rather than ask "does your product have this?" (you know the answer will be "yes"), ask "how could I use your product to do this task or achieve this goal?" This starts a dialog that really tests the mutual understanding of the need and the solution.
-
Use Scenarios. No matter how you define scenarios, they are a good thing (I can't believe I just wrote that). Seriously, I have heard different experts talking about using scenarios in different ways and they all seem to be good advice. The traditional term of "scenario" in software development is a flow through a use case. That relates to my prior point on "Focus on the How." Walk through usage scenarios of executing a specific task in the context of a particular product. When James Robertson says "scenario", this is what he is talking about. The latest version of the CMS Report, and also a CMS Watch feature article, discusses 12 "universal usage scenarios" ranging from a corporate brochure site to multi-channel publishing. I have taken a similar approach in a white paper on evaluating open source WCM systems. This is what I would call a "macro scenario" which describes a case of an organization with a particular need.
-
Prototype, prototype, prototype. Don't make a leap of faith based on a canned demo and a bunch of promises. While generic demos might help you narrow your list of candidates to a short list, before putting your money down, build a prototype with your content and have you your users bang on it. In some cases, especially when dealing with open source (where there is less potential for collecting licensing fees), you will have to pay for this prototype. However, the investment is worth it. If you feel embarrassed or not worthy to ask for this from a vendor, you are talking to the wrong company.
-
You are acquiring more than software. While the software itself is certainly important, it alone will not solve the problem. The software comes with an ecosystem that can either support you or steer you down the wrong path. You need to be comfortable with the systems integrator that will translate the software into your context, the customer support organization (or community) that will bail you out if you get out of your depth, the product management that sets the vision of the product, and numerous other stakeholders. In my (probably ineffective) bicycle example earlier, I was confident that I would get what I wanted because I agreed with the bicycle builder's philosophy in bike design and the sales person's understanding of
my needs. I am really happy with the results. -
Understand the user community. Ideally, you may be able to build relationships with other like-minded customers who you can learn from. Knowing the customer base may give you an idea of how the product might evolve in the future. Understand who is using the software and what they are using it for. While this is easier to do in open source, you also may be able to do this with commercially licensed software.
All of the advice that I have been giving so far has been qualitative and requires deep and active evaluation. You just can't do that for 2,000 vendors. So how do you get to a short list? There are a number of resources that will be helpful. Join an organization like CM Professionals or AIIM to get in touch with other users that have done what you are trying to do. CMS Matrix is good to get filtered lists of options although the accuracy of the reviews is very subjective. The CMS Report is a great resource that presents the product landscape and very sound advice on executing your CM initiative. CMS Review has a lot of information but some of it is dated. Bob Doyle, editor of CMS Review also has a nice and simple article in EContent called CMS Select a CMS in 15 Steps. Like a lot of good advice, it is pretty much common sense. No matter what you do, get yourself out there and start reading and talking to as many people as you can. Don't rely on a software sales team to teach you everything you need to know about content management. Talk to some independent third parties. Use the product in your own business context. Get a feel for what the company is like to deal with after the contract is signed.