Every CMS fails and what you can do about it

Guest post by Robert Rose
I just spent a few days at two different clients. One is a $4 Billion enterprise that has global divisions and uses a myriad of enterprise software products--including more than their fair share of content management systems (and by the way I’m referring only to web CMSs from this point forward). The other is a small non-profit, running mostly open source software, most notably to manage the content on their website.

What did they have in common? Well, other than excellent Peet’s coffee (which seemed oddly coincidental), both had CMS implementations that failed, and both were looking to re-examine their options.

You’ve all seen the statistics: 85 percent of all CMS implementations fail. Or, is it 65 percent? Or only 40 percent? Gack--let’s get Gartner on the phone. We can actually settle the debate once and for all: 100 percent of all CMSs fail at some point after implementation.

So, the question isn't: "Is the CMS going to fail?" The question is: "How big will the failure be?" And, once you acknowledge that--feel free to go through the entire Kubler-Ross grief cycle [1]--you can address the core issues, get tremendous value out of whatever solution you deploy and mitigate the challenge of the new process you’ll ultimately put in place.

First, why do they all fail?

Wikipedia defines content management [2] as "a collection of procedures used to manage workflow in a collaborative environment." Put simply, a CMS is a process meant to grease the workflow skids for managing web content. It doesn’t matter if it is a million dollar software tool or some dude named Sergei FTPing files from Dreamweaver, every organization that updates a website has a CMS.

So no matter who handles the implementation of the CMS, the only thing that's possible is to capture that workflow process as a singular moment in time.

Now, of course, some initial implementations go well; and some don't. And there have been excellent implementation best-practices posted by practitioners such as Jeff Cram [3], Seth Gottlieb [4], and Lisa Welchman [5] and her crew [6].

But regardless of how good your initial implementation is, your CMS is only as good as its ability to change. I can tell you that almost all of the clients I’ve had the pleasure to work with over the last 10 years in web content management have answered the initial “Why are you changing your CMS” question with some variant of the following:

Our existing CMS just doesn’t meet our needs any longer.
Our IT group is bottlenecking our ability to produce content fast enough.
We need to empower our local non-technical people to manage their own content.
We are re-designing our website and our existing CMS just won’t handle it.

But I can also tell you that many times, once you dig a little further, you also find:

The initial implementation of their existing CMS was actually quite professionally handled.
Although the IT group actually is “bottlenecking” the content production process, the organization actually has zero appetite for errors, and their process, while slow, is actually error free.
They actually tried rolling out the process to the local managers and it “just never quite took”--so, of course, a new software tool will fix that.
The re-design of the website is really driving the desire for a CMS re-design, because it just feels like things should start “fresh”.

Now, I do realize that sometimes a failure is just a failure. Products fail. Implementations really do go haywire. Software companies go bust or merge, and requirements sometimes really do radically change to a point where a new tool is needed.

But that’s also the point: Whether you have a great implementation or a horrible one; or whether you chose an excellent product or a poor one; your CMS process will change. The key to how big that change will be is how much attention you paid while the change was happening.

In short, all CMSs fail and boil down to a situation where, “We’ve changed and our CMS hasn’t.”

Change you really can believe in…

Ideally the choice to purchase a new tool to manage your CMS process should be to take advantage of new opportunities--and grow into new challenges--not solve old problems.

How do we make sure that your impending CMS failure is only a small speed bump and doesn’t necessarily mean you have to switch solutions wholesale? Here are three things to keep in mind:

Recognize that your organization will change. You or your team actually might change jobs. The workflow will change. The approval processes will change, and your website had better change or you may not have a choice about the changing jobs thing. Don’t be afraid to re-examine your CMS implementation every six months or so. Does it still reflect your internal process, or have end-users institutionalized “work-arounds” based on the way content “really gets done”.

Every CMS implementation (independent of the product) I’ve looked at that was more than one year old had some of this residue. Here’s the way it works. A veteran user says to a new user “I know this is how they say to do it, but if you just do “this” it gets it done faster/easier/with less hassle. Over time, “this” becomes a problem because “this” becomes “these” and inevitably “these” seem like the product has failed to meet some core requirements. If you address those issues iteratively, your system will last longer, your tool will produce many more smiles and the inevitable failures become smaller.

Recognize that nobody *really* wants to use a CMS. A CMS is not email or iTunes or Facebook. No matter how slick the interface is, a content management system is something in which no one wants to spend any more time than absolutely necessary. It’s also a software tool that typically only a few people in your organization will use with any frequency. And those core users are who you should build your process around. I’ve seen too many clients try and make the really infrequent “end-users” really happy and end up with far too many “simplified” templates and an over-complicated workflow.

Seth Gottlieb really nailed this idea in a recent blog post: The Myth of the Occasional CMS User [7]. Remember, before the CMS, Sally in marketing used to just email the press release to Joe in IT to go up on the site. It took two weeks to get published, but Sally could move on to other things. Now that you’re “empowering” Sally and she may not be as grateful for that as you think. Interesting factoid here: If you’re in the middle of looking at new CMS software, your estimate for the number of end-users is almost assuredly too high. If you think you have 20, you probably only have six or eight core end-users. In my experience, I’ve watched almost every implementation shrink over time to be about half of the original set of end-users. In only very rare instances does the number of users increase. In fact, over time, charming end-users (you know who they are) cajole core users to manage their content for them.

Your requirements are not unique, so don't make them so.I’ve been in too many meetings where someone will say “they’ve never seen a project like ours”. Guess what? Yes they have. Every CMS implementation has about 85 percent to 95 percent of the same stuff, and then the remaining 5 percent to 10 percent are indeed, weird esoteric requirements that your organization is bringing to the table. If you’re looking at the appropriate strata of CMS tools for your business, chances are any of them will handle the basic blocking and tackling of your requirements. You may like one interface over another; or one sales guy over another, but any decent CMS will handle your basic workflow needs, and will make it easier for your non-technical people to manage web content. So, certainly when you’re reviewing CMS vendors look at the entire fit of the vendor. (CMSMyth has an excellent post [8] on this topic.)

But once you get into the implementation, don’t try using every esoteric feature of that chosen CMS. Recognize that the process you deploy today will change. It just will. And the more complex you make the implementation today the harder it will be to change it down the road. Your risk for larger failure goes up with every decision in favor of complexity that you make.

In the end, remember that implementing a CMS for your organization is not simply a successful build, install or subscription to software. That’s a very small piece of the project. The real project is designing a process for change. That’s the whole idea of a content management system. No matter how big or how small your organization is, you’re anticipating change, and building a process that supports it iteratively.

And, look at what’s happening on the consulting and vendor landscape. This is where an experienced practitioner can help you. The reason it’s so confusing is because CMS tools typically support some processes much better than others (see the fit criteria mentioned earlier).

If your process is focused on web marketing, there’s an app for that.
If it’s facilitating employee access to digital assets, there’s an app for that.
If it’s focused on compliance and governance, there’s an app for that.
If it’s global thermonuclear war...well, there I can’t help you...

Taking an iterative approach to your content management process is the best way to ensure that when you fail, you fail fast, small, gracefully and with insight on how to make it better in the future.

Robert Rose is the Founder and Chief Troublemaker at Big Blue Moose [9], a consulting firm that develops marketing strategy, demand generation programs, web technology selection, social media and content strategy. For the last eight years Rose served as VP, Marketing & Strategy for CrownPeak [10]; a SaaS company focused on web content solutions for marketers.