Should you throw out the CMS or just the implementation?

Most organizations we talk to are often looking at their second or third CMS implementation, so by no means are they strangers to the promise of web content management.  But almost half the time the specific CMS has nothing to do with problems that are prompting them to start looking for a new one.  In these cases we most often find the issues center around the following:

  • Poor Planning
    • Incomplete IA
    • Bad content modeling
    • Incorrect/Poorly implemented workflow/permissions
  • No adoption strategy (or also known as the 'Field of Dreams' strategy)
  • No or poor end user training and ongoing internal support
  • Not using the CMS features correctly
  • Poor technical implementation
  • Change in core requirements

The hard part about this is often so much emotion is invested into blaming the platform for the problems it is hard to take a step back and recognize that the problems are often of their own making by either rushing through an implementation or choosing the wrong implementation partner.  We will often encourage them to do a compressed CMS selection process while keeping in mind what the true costs of switching are (A discussion about true switching costs is a post unto itself) to ensure the platform is still a valid option.  After that and some CMS therapy to work out their product issues most people come to understand that the product itself is just a tool and given the correct planning and training they can be successful with it.  In most cases they are excited by the amount of time  and money they can save since they are already familiar with the product and already have a licensing agreement in place.

So when should you consider a new CMS you ask?  The following is the my list of most common reasons:

  • Change in core technology platform (from JAVA to .NET for example).
  • Product mismatch.  The most common scenario here is using ECM (Enterprise Content Management) for marketing driven WCM (Web Content Management)
  • CMS Company issues.
    • Poor support
    • Licensing costs
    • Product end of life
  • Missing key features
  • Using a home grown/ custom CMS

So remember if you are starting to look for a new CMS, take stock of what your real reasons are for doing so.  You might be surprised to find that you already have the right CMS but you just might be missing the right implementation.

About the Author
George Ross

With more than a dozen years of experience leading enterprise web projects, George has seen the good, bad and ugly when it comes to CMS deployments. George brings an objective eye and a healthy dose of cynicism in evaluating the role of technology in the enterprise.

More articles from George Ross


9 responses… read them below or add one.

  1. David Hobbs says:

    Nice post.  The technology does often seem to be an easy scapegoat for larger issues.  In fact, I would argue that one of the main reasons to even go through a CMS selection process is to refine the requirements/need for even using a CMS (and trying to prioritize and not just throw in a bunch of buzzwords or laundry list).  Of course, another broader issue of CMS success is whether the organization has strong Web Operations Management (…/wom-primer).

  2. George Ross George Ross says:

    Thanks for information David.   I agree about the requirements side.  It is a big focus for us when helping a customer to find a CMS  We talk about it in terms of ‘Fit Factors’ that cut across a lot of areas.

  3. All excellent advice. I would only add:

    Something I hear all the time from organisations: "I think the CMS is fine, but our implementation was poor". This is well and good, but when I hear this for *every one* of the sites from some products, you have to question the CMS.

    So I would advise checking around: if no-one else has had success with the CMS, this may point to a new product…

  4. I’ve had a few ideas in the past in a similar vein:…/is-it-what-or-how-that-broke-it

    I disagree with James Robertson though. Most of the time I hear it’s the technology that’s poor, when actually people just don’t know how to exploit it.

  5. George says:

    James and Phillppe you actually are both right in a sense.  You have to remember every CMS was originally created to ‘scratch some itch’ and then adapted over time to try to serve everyone under the sun (or get every checkbox on CMS Matrix).  That simple fact alone predisposes each CMS platform to be stronger in some scenarios and almost useless in others.

    A big part of our jobs as CMS professionals is helping people see past the shiny demo and understand how the CMS works specifically for the customer and their key scenarios. (Please queue Matchmaker from Fiddler on the Roof).  

    Now don’t get me wrong there are some CMS platforms out there that are more marketing hype and slick demos than tangible product. Yes you can build a site on on them, and yes it will work but in truth they kind of suck and should be replaced.

    So to wrap it up you have to also make sure the CMS matches intended site usage/scenario as well as the customer’s specific requirements and make sure the product viable (and about 1000 other things that are not specific to this post).

  6. The habit of blaming the technology is not restricted to CMS. I’ve seen the same processes occur around search tools and other applications.

    The challenge is lifting the debate from the technology (tool) to the desired outcome s and the necessary processes used to achieve them.

    If discussions can be refocused around outcomes people can often begin identifying the real issues, which are often very addressable within the technologies in place, or can be added with a third-party add-on, rather than by throwing the baby out with the bathwater.

  7. Cleve says:

    Interesting article.  I’m approaching this from the perspective of a solution provider  implementing the site using a customer selected CMS product.  The reality is that when we are engaged by the customer, the cat is already among the pigeons.  The IA is a works in progress, the designs incomplete,  the content model wobbling like a jelly, the content strategy is vapourware and the due date looming.  It’s my personal recurring nightmare.  

    From your list, I think planning and the lack of strategy are real killers.  Changing requirements are the norm and a poor technical implementation works if it meets that requirements.  So third the prize would be training.  Always vastly underrated…

  8. JB King says:

    I’m somewhat new to using a CMS but I think there are generally 4 groups that have to be considered when bringing in a CMS that I’ve seen:

    1) The site designers.  This is the creative side that come up with how a site should look, what the navigation is, and other front-end parts.  This is usually an agency contracted to help with re-branding a company or product line.

    2) The CMS consultants/integrators.  This is the side of experts with a CMS that come in to help a company get an implementation done though this isn’t necessarily done well.  Note that this is also a party outside of the company wanting the site(s).

    3) The IT department of the company.  This is the group that has to learn the CMS through a combination of experiment and using the expertise of the previous group in supplying the platform ultimately.  This is also those that run the servers, handle scaling the solution up over time and are a key point not to forget in this.

    4) The business itself.  This is really a combination of content authors/editors and web visitors that actually use the web sites built using the CMS.

    Each group has their own interests which may differ from another though they all have to work together to deliver the web site and all its requisite applications and databases and other bits and bytes.

  9. I love this post — it points out the ugliness that’s uncovered after a sloppy job is complete. I just find that one of the primary issues with WCM implementations is that the business needs change within 6 months of the implementation and Marketing becomes upset that they can’t do X with the system. I believe that integrators have to think about the marketplace and future needs at the onset of the project.

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