Why Organizations Pick CMS X Over CMS Y

At Blend, we often get involved in CMS selection projects. Usually, we’re pitching a CMS for a process run by someone else. However, increasingly, we’re being asked to help an organization pick the best CMS for their situation.

While the right CMS choice is hopefully based purely on the requirements of the project, it’s naive to think other factors don’t come into play. Two systems might both meet the requirements. Or there might be hard limits on things like budget and platform. Or people can just be a little irrational.

I decided to attempt to codify the different “axes” on which the resulting decision turns. Could I reduce CMS selection down to the major areas of differentiation? What I did was think back over all the selection processes we’ve been involved in – both successfully and unsuccessfully – and ask myself on what crucial points did the decision turn? What were the decision points that caused an organization to pick CMS X over CMS Y?

In the final analysis, I came up with six broad areas of differentiation. At the end of each factor, I’ve provided some invented quotes that represent arguments we’ve heard from organizations when justifying their decisions. In all situations, the speaker is justifying the selection of CMS X over CMS Y. (This is a rhetorical device I’m shamelessly stealing from Daniel Kahneman’s “Thinking, Fast and Slow.”)

1. Features and Functionality

CMS X might do more stuff you want to do than CMS Y.

This is the most obvious criteria, but it gets weirdly fuzzy in that what organizations think are important, often aren’t. When an organization thinks about features and functionality, they’re often really thinking about softer factors like usability, extensibility, and ecosystem (all covered below).

It’s undeniable that CMS X might do specific things better than CMS Y, but the trick is figuring out which of those features are important to your organization. And not just superficially important, but of genuine importance that will provide lasting value over time. CMS buyers tend to get fixated on things that they associate with a “good” project or a “competent” organization – things like workflow and personalization – that they struggle to actually use.

This is further warped by vendor demos. When a vendor demos a feature, many customers don’t realize how orchestrated that demo is, and how little relevance it probably has to their situation. There’s a good chance that feature will never work that well ever again.

And features don’t exist in a vacuum. You need to know how to use them, and you need to be able to staff them over time. Many a great feature has gone unused because the CMS owner couldn’t figure out how to put it work. In saying this, I don’t mean to say that features don’t matter, just that our theoretical needs and our actual needs are two different things. Many “needs” are simply a theoretical representation of where we want to be. But some features are actual and relate to concrete requirements.

Also worth considering when evaluating features is the extensibility of the platform (covered below). A highly extensible and programmable CMS might allow the implementation team to work around missing features, or even replicate them through configuration or code.

• "We need to be able to have a language fallback tree, so we can serve up French Canadian before English if we don’t have French. CMS Y can’t do this.”

• "CMS X lets us put visitors into demographic buckets and show or hide content based on their behavior. We’ll use the hell out of that.” (Spoiler: you probably won’t)

• "CMS Y doesn’t have an audit trail. And versioning is optional and up to the editor. Bob in Compliance will throw a fit over that.”

• "CMS X can automatically push article titles and links into Twitter and Facebook. We don’t want to have to build that.”

2. Platform and Architecture

CMS X might fit into your technical environment better than CMS Y.

This decision point assumes you have technical and/or architectural restraints, which many organizations do. They might have an IT department that only wants to host and maintain something which runs on Platform X. Perhaps CMS Y is only offered via vendor-hosted SaaS, and there are privacy and data safety considerations inside the organization which prohibit this.

Beyond language and execution, larger architecture considerations sometimes come into play, mainly in the relationship between the delivery and management environments. For example, perhaps the organization wants a decoupled environment. Or they want something that will support a massive delivery environment, with a smaller management environment.

These restrictions can be both arbitrary and rigid. It’s not under an editor’s control that their organization will only support .NET, but this limitation is often sacrosanct. It’s a rare technical writer that can persuade the CIO to deploy an odd web server or unknown architecture to support their needs. In these cases, the people who want the CMS often end up going outside the organization to an externally hosted solution, when possible.

• "I liked CMS Y more, but we have to develop it internally, and we’re a .NET shop.”

• "We’re going to have to serve this content from data centers all around the world, and CMS Y requires software on all the delivery servers. That’s going to be complicated and expensive. CMS X will push content to bare-bones Apache servers that we can deploy in minutes.”

• "IT doesn’t want a CMS at all. We don’t want a war, so we think a headless CMS like X will at least give us a good editorial interface, which is a step in the right direction. IT can build the front-end from scratch.”

3. Usability and Ease of Adoption

CMS X might be easier to use than CMS Y.

Editorial usage is often waved off, with the fleeting thought that editors will just figure it out. Additionally, people making CMS selection decisions are, on average, more technically savvy than the people those decisions will impact.

What I’ve found is sobering: very few things destroy the morale of a team more than a poorly-usable CMS. These things cause projects to fail is subtle ways. Yes, you may have come in under budget and within schedule, but if your editors hate their CMS and are considering a replacement six months after implementation, I’m going to call that project a failure no matter what the numbers suggest.

The least usable are the fringe open-source systems that don’t have significant user penetration or a big enough installed base to make usability a priority. On the other end of the extreme are the large-scale open source efforts (think Drupal or WordPress) which have an enormous installed base which is demanding usability, or the commercial systems that have a steady stream of license and subscription fees to both (1) fund significant usability efforts, and (2) necessitate usability to justify significant cost.

• "The way CMS Y handled media was complicated. It took, like, 10 steps to put an image in an article.”

• "I couldn’t figure out the admin interface for CMS Y. So many ‘modules’ and ‘add-ons.' Nothing was consistent.”

• "I love the editing interface of CMS X. You can edit right on the page, exactly how it will appear when it’s published.”

• "You can’t ‘dial-down’ the editorial interface for CMS Y. Every option is displayed and active, all the time. I can only imagine the Help Desk calls when Ted in Accounting clicks on something he’s not supposed to.”

4. Pricing and License Structure

CMS X might be cheaper than CMS Y.

This one seems simple, but the hidden problem is that differences in cost can be tricky to calculate, especially when pricing and subscription models are different.

First, what are you including in the cost? Just the right to use the software? Or implementing the software as well? This matters, because some systems are easier to implement than others, and there might be differences in the magnitude of implementation costs. A lower license fee can get drowned out by heroic efforts to get the software to do what you need. This is very true of open-source – no license fee at all is attractive, but commercial systems tend to be more functional and easier to deliver complex solutions with. The balance might tip during implementation.

Second, costs are calculated on different models, and this makes comparisons difficult. The “traditional” model (in quotes, because it’s becoming less and less common, and therefore might not be “traditional” for long), says that you pay a one-time license fee, then a percentage of that (usually 18-22%) each year in subscription fees.

But more and more companies aren’t calling it “licensing” at all anymore, and rather just going with “subscription” right out of the gate, meaning you pay 100% of a (hopefully) lower fee every year (some even have built-in escalators, meaning you pay a compounded 100+X% every year). Then we have SaaS/hosted solutions, which means you have to figure out managed hosting costs for the systems that don’t include and add them in to equalize the offerings.

To compare solutions on cost you usually always have to pick a time horizon. Unless the two systems you’re comparing are priced on the exact same model, then you select a time period and price each solution for that entire time period, then compare those numbers. How long do you think you’ll use the software? CMS X might be cheaper than CMS Y on a 3-year horizon, but the relative costs flip on five years or seven years.

Finally, don’t get blinded by price. CMS X might be cheaper, but is the discount worth it? A failed implementation might make the cost savings look pretty minuscule a year down the road.

• "The license fees of CMS Y would suck up 40% of the budget. It’s just a non-starter.”

• "CMS X offers unlimited authors without more license fees. That’ll come in handy.”

• "CMS X is more expensive initially, but it only has annual costs of 20%. CMS Y is full subscription every year, plus 3%. CMS X gets cheaper by Year 3, and even more so by Years 4 and 5.”

• "We have to burn the entire budget this year. CMS X will give us discounted subscription for four years out if we pay upfront. Plus, they’ll let us throw in some professional services money on deposit. We can end the year on a zero budget, and have all this stuff paid into the future.”

5. Extensibility and Ease of Development (or not)

CMS X might be easier to implement or customize than CMS Y.

CMSs exist on a range of “product to platform.” Pure products are meant to be used as-is, out of the box. Pure platforms can be little more than an API on which you build a custom solution.

Most systems are somewhere in this range. Systems are “product-ish” or “platform-ish.” The philosophy and intended user audience dictate this: some companies built their CMS for developers, while others build it for editors and marketers. The latter tends to try and pre-solve problems and assumes their users might not have access to development resources. This is referred to colloquially as an “opinionated CMS” – it has “opinions” about the best way to do something, and it imposes those on the project.

This “tone” of a system matters. Some projects emphasize speed of launch and delivery without customization, while others are heavily-developed, both at launch and over time. The Holy Grail is one system that does both. While many vendors have claimed to have solved this riddle, it’s not easy to keep both sides happy.

And here’s the opposite: sometimes people want stuff out of the box. They hate the idea of a development platform because they’ve had bad experiences in the past, so they don’t have a development group. They like the idea of something “just working,” or the idea that “modules” can be installed and used without development intervention. (Editorial comment: This is something of a fantasy and is ridiculously oversold by vendors with these systems. I’ve rarely seen these situations end well.)

• "The API of CMS Y is a mess. We tried to build a simple proof-of-concept, but there was no documentation and things just didn’t work the way we assumed.”

• "CMS Y is a closed system. You apparently just get what you get. We’d have to change our requirements to match what it offers.”

• "CMS X is more work to get running out-of-the-box, but there are so many ways to extend it. When we do the big CRM integration in Phase 2, I’d rather be using CMS X than CMS Y.”

• "CMS X offers all these pre-built components. We’re going to build the website by just connecting the dots, right before we skip through a field of wildflowers and ride off into the sunset on the back of a golden unicorn.” (Note: this one, while accurate, might be a little embellished…)

6. Ecosystem, Reputation, and Market Penetration

CMS X might have more partners, developers, usage, and freely available content than CMS Y

CMSs don’t exist in a vacuum. They have to be implemented and supported over time, and there is safety in numbers. Organizations want to be sure they can find people to work on it – both contractors and hire-able employees.

And perhaps even more than specific scenarios, customers just don’t like picking the “odd” choice. Outside of developers that like being contrarian and exploratory (hint: that’s all of you), no one wants to use fringe technology. If a CMS has no ecosystem of resources, organizations will justifiably want to know why. On the other side, if there is a wealth of contractors, agencies, and resources available, that sends a mental signal that a CMS is widely used and therefore must be widely-liked.

While I love finding and toying with new systems, that’s easy to do when you don’t have a budget or schedule to deliver on. When you have a business project bearing down on you, you want to be nestled in the warm embrace of a thriving user and contractor community. “No one got fired for choosing IBM” doesn’t help innovation, but it makes buyers feel safe and sometimes this is exactly what they’re looking for, whether they’re cognizant of it or not.

• "CMS Y has, like, five North American partners. And the biggest only has a half dozen developers. Plus, the vendor itself is a little sketchy – I can never get an email response when I send a question.”

• "I asked around at my conference about CMS Y. No one had heard of it. But I swear, no one would shut up about CMS X.”

• "Have you seen the module library for CMS X? There’s submitted code for basically anything you want to do. The ‘cmsx’ tag on Stack Overflow has 15,000 questions. And there’s about a thousand training videos on YouTube.”

• "We love Blend Interactive so much. Whenever they speak, the sun starts shining and the birds start singing. They’re really the embodiment of everything good in the world. We only get to work with them if we pick CMS X, so, by golly, that’s what we’ll do!” (Note: this is not embellished at all.)

Conclusion and Perspectives

The points on which a decision flexes aren’t considered in isolation. When you pick X over Y, you’ll likely consider these points and decide that X is better than Y in aggregate. It’s a process of give and take – X is better than Y in some areas, and not as good in a few others, but the preponderance of the difference tilts the scale further to X than Y.

Each organization will emphasize different points, some of which might not be entirely rational. One organization might look for extensibility because they have an internal development group that needs to feel invested in the project. A decision maker might have been stung by bad decisions and is just trying to pick the safest thing that everyone else is using. And we’ve encountered many situations where marketing groups are specifically looking for a SaaS architecture that coincidentally “requires” them to make an end-run around their IT staff.

I showed this list to two people I trust: Tony Byrne from Real Story Group and Cathy McKnight from Digital Clarity Group. They both agreed it was reasonably accurate, and added some other perspective.

Tony pointed out that organizations have a tendency to consider their internal capacity from a development standpoint, but not from a marketing or editorial standpoint, when reviewing a system’s features and potential:

Organizations are often missing one key component: internal capacity. What is the degree and depth of skills, experience, decision-making ability do they have to actually execute. They do that on the dev side, but few customers do introspection on the business side: editorial strategy, analytics skills required, available design resources to do constant tweaks, etc.

My experience mirrors this. Blend gets called in because organizations clearly think they can’t implement, but there’s boundless optimism for what the marketing and editorial groups will do with a CMS post-implementation.

For her part, Cathy puts emphasis on the implementing partner (“ecosystem,” from above):

It is just as, if not more so, important to put as much effort into choosing the partner that will help implement the technology. You can buy the best CMS on the market and it still end up as an epic failure if the partner isn’t the right fit. But pick a middle of the road CMS and a really great partner and they will be able to make the CMS sing the song you want and the project a resounding success.

Given the business I’m in, I’m certainly not going to argue that point.

Professional CMS selection exists for this reason: customers have a vague idea of their explicit requirements, but they don’t truly understand the relative importance of those requirements to a successful project, nor how a CMSs implementation of that requirement might help or hinder them in the real world. To that extent, helping someone pick a CMS is less a process of knowing the market, and more a process of helping them understand themselves.