Are You Making the Right CMS Promises?

With the primary elections officially upon us, candidates are making promises that they will be expected to keep if elected. 

In the same spirit, web content management projects are full of promises. More so than a lot of web initiatives in fact.

We talk a lot about the expectation gap between vendors that beat the drum of ‘out of the box,’ and ‘easy’ compared to the reality on the ground of a complex implementation. But it’s time to take a closer look at what promises we’re making internally inside the organizations before deploying a CMS. Some common promises include:

  • Enable anyone to easily publish content
  • Save time and money
  • Create better experiences
  • Remove dependency on IT staff

Are you keeping those promises to the organization? Probably not.

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.

In my experience, the CMS is often to set up to fail from the get go by the way that success is promised.

What if you change the promise? What if the project lead says:

“Our new approach to content management is a paradigm shift for the organization and is going to be a difficult transition. It will require significantly more resources and added cost for training, new staff and new technology.  However, if we can make an organizational commitment, the payoff and long term return on investment is tremendous…”

Changes the picture a bit doesn’t it?

Sure it may stop a few CMS projects before they get started. But that’s not a bad thing for an organization that doesn’t have the stomach to see it succeed.

What it will do is help you start to better define success before you start and set proper expectations. After all, it’s better to be the hero at the end of the project than the beginning.
 

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

Comments

3 responses… read them below or add one.

  1. I think these are all great points, highlighting that expectations often exceed reality when it comes to a CMS.

    That being said, I also think your list highlights some areas where we can more activitely try to deliver on these promises when selecting a CMS. For example:

    * In my work, I get clients to include a specific requirement called "Self-sufficiency", to explicitly evaluate where it does eliminate the need for IT support.

    * The usability of the CMS for general authors can also be directly evaluated, such as by having the short-listed vendors run their standard end-user training session with someone plucked out of the organisation. This allows quite a few things to be assessed at once, not least, whether the end-user really can use the CMS by the end of the session.

    I think there’s a long way to go for CMS products before they fully deliver on the promises you list, but we can start to hold them to a higher standard as part of the selection process. Without this pressure, I don’t think we’ll ever get there…

    Cheers, James

  2. Jeff Cram Jeff Cram says:

    Great comments James. Love the self-sufficiency requirement concept. Thanks for reading.

    - Jeff

  3. David Hobbs says:

    Thanks for the useful post.  This especially resonated with me: "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."  I think a discussion something like the following would be helpful at the start of a CMS migration project: "Everyone, one purpose off this project is to standardize our web pages.  This means that you won’t have as much flexibility in designing the look of your content as if you worked directly in Dreamweaver or some other advanced HTML editor.  This is by design."  (And if that doesn’t fly then perhaps don’t continue on the project.) I think another related issue is that the power users may find a way to work around whatever standard tools/templates you give, and then not as advanced users want that capability as well (which they aren’t as equipped to do).  

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