The Real Reasons People Hate Their CMS

CMS Pain Assessment Tool
This post was originally published on Aug 29, 2013.

Hating your CMS is so trendy these days you’d think it was 2008 all over again. A few weeks ago, Gerry McGovern posed the age old question of why organizations hate their CMS so much and last week Fierce Content Management editor Ron Miller had a copy and paste error that broke the proverbial camel’s back.

“In all the years I’ve been doing this I can’t think of an organization that was genuinely happy with what they have,” wrote McGovern, hopefully using hyperbole to make his point. I’d like to think he’s met at least one satisfied web publisher (they exist, really).

It’s true that frustrations can easily boil over when it comes to working with CMS. It’s a primary reason we started this blog and spend time creating handy (albeit tongue in cheek) utilities like our CMS Pain Assessment Tool. We’re big fans of content management as both a strategic discipline and technology and like to see it done right.

While CMS is a favorite punching bag when complaining about website woes, the jabs are often knee jerk emotional responses to much deeper organizational issues. Sometimes the technology unfairly takes the fall, while at other times the technology deserves the blame

In an attempt to unpack the rage, we decided to explore some of the underlying reasons folks dream of going all Office Space on those WYSIWYG editors. Here are nine we came up with in no particular order.

1. CMS that’s built for buyers, not end users

Let’s face it—enterprise software doesn’t have a great track record when it comes to end user experiences, and CMS is no exception. While you can’t paint all solutions with the same brush, Karen McGrane has described CMS as the “enterprise software UX forgot.” It’s true some vendors are making positive strides but the reality is the buyers of CMS are not typically the end users. Jason Fried of 37 Signals sums this up as the reason why enterprise software sucks in his blog post on the topic:

“The people who buy enterprise software aren’t the people who use enterprise software. That’s where the disconnect begins. And it pulls and pulls and pulls until the user experience is split from the buying experience so severely that the software vendors are building for the buyers, not the users. The experience takes a back seat to the feature list, future promises, and buzz words.”

This disconnect causes significant friction (a slippery slope to hate) with end users who care less about shiny new features and more about getting their routine tasks done day in and day out. In an attempt to provide ultimate flexibility to all types of users (most things are truly possible in most enterprise platforms), many platforms cater to none.

2. Short changing the implementation 

If you hear a chorus of CMS vendors calling foul on that last reason, they do have a point. While software vendors bear the brunt of the negative vibes, the reality is that the implementation is far more important to the overall success than which platform was selected.

Scott Liewehr, President of Digital Clarity Group has been focused on the importance of implementations with his new report on the Guide to Service Providers for WCM and CEM (download a complimentary excerpt). In talking to Scott he says that organizations often undervalue what needs to get put around the software to succeed.

“Our experience and research has found that 75-80% of the web content management challenges faced by organizations can be attributed to the implementation rather than to the [technology] itself.”

While you can nitpick on the percentages, our experiences have been similar. If an organization plans, implements and manages the CMS as a technology-centric project, it’s almost certain to leave a trail of dissatisfied end users, authors and editors. Companies that get CMS right pay careful attention to selecting partners, investing the right resources, sequencing the right initiatives, and framing the overall project within a larger digital and content strategy. The implementation and approach make all the difference in the world.

3. Delusions of decentralization 

A fundamental promise of any CMS worth its maintenance fee is the ability to decentralize publishing responsibilities to non-technical users. This was as true in 1998 as it is today. While this is a real (and realized) benefit, the most vocal critics of a CMS platform are often the ones who use it the least. As Margot Bloomstein recently tweeted, “A tool alone does not alone create a culture…of distributed ownership.”

We’ve explored this issue before in our article on Stop letting people use your CMS. It’s unrealistic to expect anyone would enjoy using a complicated piece of software, however nice the interface, if they have to relearn it every few months to accomplish very basic tasks.

The people we’ve met who are happiest with their CMS are typically the power users who are in it day in and day out and have learned to use the system. What makes them unhappy, however, is having to deal with the dozens (or hundreds) of angry end users who (with pitchforks and rakes in hand) are demanding better tools and training and threatening to “go rogue” with their open source platform of choice.

Thankfully, there’s been a shift toward larger, more experienced centralized content teams who help enable the broader organization and work with decentralized users. Figuring out how to support distributed authors with the right governance model and effective editorial processes go a long ways toward having happy end users—wherever they may live in the organization.

4. Trapped in a website management paradigm

It’s unfair, really, that this whole mobile thing came along just when CMS vendors, service providers, and end organizations were starting to really understand how to make CMS work.

The inconvenient truth is that most modern web content management systems have been organized around web publishing, not the management of content independent of channel or presentation layer. The urgency of this shift is highlighted in Karen McGrane’s book Content Strategy for Mobile and her overall point of view on the role of adaptive content.

Some see this trend forcing a great decoupling (or re-decoupling depending on your years in the industry) of content management’s core capabilities from delivery functions. At a minimum it is forcing vendors to re-evaluate product roadmaps, author experiences and the overall approach to multi-channel publishing.

These changes, however, aren’t happening fast enough to meet the demands of marketing and web teams racing to keep up with their customers voracious appetites for everything mobile. Nor are the processes for planning user experiences and content strategy evolving fast enough. A content strategy to support highly personalized experiences across multiple devices isn’t realistic when most organizations are struggling to get through the basics.

This awkward in-between period is causing a lot of pain, and yes hate, from end users of CMS who are feeling the pressure to deliver on the mobile mandate yesterday and wondering why their tools, service providers and colleagues aren’t yet ready.

5. Forgetting to consider the author experience

For as much as we trumpet customer experience and user-centered design, CMS implementations almost alway fall short in thinking about the author experiences. As Rick Yagodich said in his post The experience alphabet: AX comes before UX, “authors are people too.” He goes on to write:

If we fail to make it easy for our authors…to provide the engagement mandated for those interactions with the customer, they will behave as any other user. They will avoid the chore of dealing with us.

Don’t fall victim to what we call the ease of use myth where everyone agrees that the CMS author experience needs to be simple, but fails to do the work necessary to define it and implement it.

The out-of-the-box authoring tools provided by a CMS are like a big ball of clay that need to be molded for the unique needs of users dealing with specific content structures, metadata and relationships. These workflows are best assembled in packages more often than pages. Many author experiences should be custom designed the same way you map out the pathways and use cases for external users on a website.

We recently developed a large custom authoring experience for a life sciences company that needed to have scientists and laboratory assistants managing highly complex data. The standard content editor and in-line page editing tools would simply not work for these audiences. Paying attention to the needs of your end users is a fantastic way to stop (or at least slow) the hate mail rolling into the central web group.

6. CMS as an innocent bystander in a political war

It’s important to remember that sometimes frustrations with a CMS have nothing to do with the actual platform. The change management involved with a CMS overhaul is a rough and tumble business.

We’ve run into individuals that hate the CMS because they disagreed with the platform choice or resent decisions made around governance and access. There’s also a vendor fit necessary between end organizations and the CMS vendors and sometimes those relationships are simply not compatible. A poor support and maintenance relationship can sour an experience that had been positive to that point. Some relationships also never recover from the promises made during the sales process that didn’t meet expectations.

We’ve consulted with organizations that know their existing platform can work for them but are forced to replace it because it carries so much political baggage and ill will inside the organization. These are unfortunate situations that can be minimized by proper expectation setting and a good governance structure.

7. Failing to put a content strategy in place

Unless you’ve been off the grid for a bit, you’ve probably heard a thing or two about the importance of content strategy  (here’s an epic list to catch you up if you’ve been away). While a content strategy doesn’t equate to your overall digital and customer experience strategy, it is a prerequisite for success with any CMS.

The most unhappy organizations we talk to have not taken the time to put a content strategy in place, and more importantly have not assigned any dedicated internal resources to helping manage the content post launch.

With all that said, a content strategy alone isn’t a silver bullet for eliminating frustrations with the CMS. Often times the content planning is done in complete isolation from the CMS platform and technology strategy. The folks who care about content need to be willing to roll up their sleeves and help make the technology work better.

In some cases organizations with mature content strategy capabilities are the most vocal with their CMS pain because the authors and editors are sophisticated enough to know what they actually need from the technology. This can be a nice problem to have if that energy can be channeled for the greater good.

The prolific Deane Barker, who blogs at Gadgetopia, highlights this gap in a recent blog post that advocates for the role of a content management strategist to help fill the void between the content strategy and the CMS implementation. He writes:

You see, there’s a murky space between the idea of content, and the hard reality of a content management system. We’re seeing situations where a content strategist has come in and developed a undeniably great plan for content — how to organize it, or develop it, or present it, or whatever — and then left.  The organization now has a solid plan, but no idea how to implement it, technically

However you decide to staff the many different roles, it’s critical that you have folks who can work across the disciplines.

8.  Selecting a less than ideal CMS

All too often organizations unfairly point to the technology as the reason for their struggles. Seasoned CMS professionals know that the tool (and the selection process) are rarely the primary issue (see the other eight reasons in this post).

While it’s true that you can get almost any CMS to do anything you want with a little elbow grease and room full of developers, the reality is that some will fit your organization better than others and you can make a poor selection. The CMS you select will make a big difference if it’s not aligned to your business model and overall company culture.

A large multi-national company putting 30 sites onto a single platform across 20 languages isn’t well suited for a simple CMS product geared toward single site management. A marketing-centric organization focused on demand generation will struggle with a platform unable to help connect content to revenue and support at-scale marketing functions.

Go too much against the grain of how the platforms are intended to work and the cracks in the dam will start to surface before eventually giving way to a tidal wave of frustration from the users and the overall business.

There are several additional reasons the CMS selected may not be working out. Perhaps you were sold a CMS and feature set that doesn’t exactly line up to reality (Spoiler alert: sales folks are good at selling). Or your business model has evolved and the CMS no longer fits or scales. Often times swapping out the technology is the only way forward to fix fundamental problems.

But when you have to go through the process of finding a CMS, be sure you don’t fall victim to what we can the CMS Selection Myth. Spend the time to make sure the organization is prepared to be successful with CMS before you make the leap.

9. Setting the wrong expectations

Perhaps the biggest disconnect between ‘happy’ and ‘I want to throw this platform off the roof’ comes from the  expectations set for the CMS to begin with. In our article Are you making the right CMS promises?, we examine the expectation gap that exists between the promise of CMS and how it actually works when implemented. While organizations tout benefits like streaming efforts, decentralizing teams and saving money, the reality is that a new CMS usually takes more resources, not less as we write in the article:

In most cases, a CMS actually adds cost and complexity and takes more effort to maintain and run. Often times enabling more users to edit content means creating a less flexible system for the power users and developers who spend the majority of the time maintaining the site.

This rosy stories we tell ourselves set us up for a much harder fall when that worldview doesn’t align. There’s enough blame to go around here as software vendors, agencies and end organizations are all trying to share an end vision that excites the organization and gets buy in for the hard work needed.

Turning those CMS frowns upside down

While it’s easy to hate on the technology, it’s only part of the story when it comes to CMS challenges. There’s a lot of lip service given to putting the right people and processes around a CMS platform project, but organizations ultimately vote with how they allocate resources. It’s on all of us to do a gut check and make sure we’re prioritizing the right elements for success. In looking at budgets for CMS projects technology almost always gets the lion’s share of the upfront investment. When is the last time you saw a $500,000 line item for a content strategy rollout?

The good news is that now more than ever vendors and end organizations understand the value of content and the role of CMS in the overall business and customer experience. While it’s unrealistic to think people are going to love their content management systems overnight, we are optimistic that the next wave of tools and disruptive thinking will help improve the overall experience for both authors and customers alike.

To that end, we’re currently conducting research for our second CMS Wisdom Report and would welcome your feedback via our short survey.

Did these 2,500+ words capture all the reasons people hate their CMS? Probably not. Share your own ideas in the comments as well as any lessons learned on how you’ve been able to overcome these challenges.

About the Author
Jeff Cram

Jeff Cram is Chief Strategy Officer and co-founder of Connective DX (formerly ISITE Design), a digital agency based in Portland, OR and Boston, MA. As the Managing Editor of the CMS Myth, Jeff is passionate about all topics related to content management, digital strategy and experience design.

More articles from Jeff Cram


11 responses… read them below or add one.

  1. David Hobbs says:

    Great post!

    In some ways, people fall into the content OR technology camps, but the two need to be combined together.

    Fundamentally, I think people don’t 1) define what they want out of their CMS, and 2) don’t manage their implementation to meet that vision if they set one in the first place. My next handbook will be on website PRODUCT management, arguing that project management isn’t enough: everyone needs to run their website (and the underlying implementation) as a product that must be managed for high quality over the long term.

  2. Jeff Cram Jeff Cram says:

    I think we’ve had this conversation before David. :)

    I think there’s a risk of reducing the problem down to requirements gathering around a new CMS. IMO it has more to do with the lens through which you view the entire project. I’ve see a lot of long, drawn out CMS selection projects with tons of requirements gathering and business scenarios but they are framed so narrowly that it is essentially wasted planning. Having a vision for what the CMS needs to do is very different than having a vision for a larger experience strategy that the CMS will support. But the folks that really know the tools don’t often have the frameworks for the bigger picture strategy – and vice versa.

  3. Aaron says:

    Great stuff as always Jeff. As someone who has had to define those requirements on multiple occasions, that is a really hard process for business users to go through. Even with a skilled Business Analyst on the team, distilling it down to the salient points with out ending up with a feature checklist a mile-long is a huge challenge. And not surprisingly, requirements change, and expectations around what a requirement means change even more rapidly.

    As you know I am personally (And until recently, professionally) a huge proponent of flexibility. I expect my strategy to change. I expect my requirements to change, I expect my needs to change. The tools that deliver the greatest amount of flexibility to adapt in an ever-changing environment are going to be the winners. And that does not necessarily mean open source. It really means that whatever system you choose, make sure that you have the functional ability, and the technical skills required on staff, to change rapidly. If not, I promise you that you will always be unhappy.


  4. Rick Cabral says:

    A fun post Jeff, but I think you’re missing a key point: Organizations expect CMS to deliver an “accessible, amateur-proof” authoring experience, but the reality of modern website design (and here mean user experience & graphic arts) requires professionals. This expectation is the equivalent of an organization asking everyone to maintain their own business cards or print materials using Microsoft Word (or worse). I’ve always thought it interesting that management typically understands the value of contracting a professional for their offline marketing materials, but they fail to invest in the same level of expertise on the web.

  5. Fred Bals says:

    “Companies that get CMS right pay careful attention to selecting partners, investing the right resources, sequencing the right initiatives and framing the overall project within a larger digital and content strategy. The implementation and approach make all the difference in the world.”

    Hear, hear. Jeff, what do you think of Jeff Conway’s contention that hosted WCM solutions might be the answer to much of the pain people have with their CMS…

    … allowing people to focus on the content of their website while removing the burden of managing the infrastructure and software?

  6. Jeff Cram Jeff Cram says:

    Thanks for the comments. Agree Rick, that it’s a headline that orgs need to upgrade internal capabilities which is an embedded theme in 3 and 7. Fred, I think the migration toward hosted platforms is inevitable although the article seems to suggest putting the technology in the cloud is the answer. Looking at the nine reasons above, I’m not sure what that actually helps.

  7. Great summary of CMS woes :)

    I would also add that many CMSs are designed as frameworks and development tools, more so than publishing tools – Built by developers for developers. Drupal and Joomla are prime examples of this, although they are getting better. End users usually don’t think or act like developers, so their experience can be extremely frustrating.

    I agree about the implementation being 50% or more of the success of a project. It is as true today as it was in 2011.

  8. David Hobbs says:

    Re: your first comment Jeff, I strongly agree that shock and awe requirements aren’t the way to go!

  9. If developers and designers had a more enjoyable experience working with the CMS, the resulting product would be a lot more palatable and enjoyable to the end-users.

    Most Drupal, Joomla and WordPress developers I have known in my 15 years of web-development can be roughly divided into two groups: beginners, and those who have worked long enough with one of these systems to grow to hate them. Needless to say, neither one of those groups are going to produce great work, since they either don’t know what they’re doing (bad) or they hate what they do (worse).

    I can count on one hand the developers I have known in my career who actually enjoyed working with one of the mainstream CMS, and as a rule, then, only one of them.

    I think this is the real fundamental problem, and the real reason CMS projects don’t often end up with three cheers and years of end-user joy.

    That is not to say a content strategy is something you can neglect, and it doesn’t make anything you said in this article any less true or important! But it does mean that, even if you have a brilliant content strategy, your chances of finding developers who work with these CMS for reasons other than profit, are slim, and the chance of ending up with a great solution are equally slim.

  10. John Gildred says:

    I agree that most people who have worked with Drupal and WordPress for a while start to hate the structure they impose. I just wanted a CMS to: A) store my pages in a DB, B) give me a decent full-screen code editor, C) leave my pages alone. Surprisingly very few CMSs can do this easily.

    I also never understood why there is no CMS which has a built-in DBMS (like phpMySql but much simpler). When you create a table, the CMS could automatically create a REST API to access it. Lot’s of possibilities.

    In the end, I gave up and just wrote my own CMS. Sometimes, it’s the only way to get what you want.

  11. Meaty article and great thinking here. Can get so depressing getting stuck with a beast of a CMS but some good food for thought here.

Leave a Reply to Fred Bals
  1. Fields marked with * are required.
  2. We will not publish your email.