The CMS Myth

December 2008 - Posts

  • Gilbane Boston & Planning for a CMS

    Another Gilbane conference has come and gone and the Mythbusters were once again in the middle of the action to get firsthand insight.

    In fact, we’re just now gathering our thoughts from a whirlwind three days of keynotes, panels, hallway conversations and the trade show floor.

    I have to admit, it feels a little bit like the movie Groundhog Day going to this show every year. Similar vendor set, familiar formats and the same core challenges around CMS. Perhaps in 10-15 more years I’ll have this CMS bit figured out just as Bill Murray’s character became a master pianist in Punxatawney.

    A highlight of the show for me was being on the “Planning for a CMS” panel with Gilbane’s Tony White and Nathan Williams, the Interactive Director for the City of New Orleans. This was extra special because New Orleans was a project we all worked on together from CMS evaluation to strategic planning to implementation (launching soon!). It’s a remarkable story that I hope to be sharing about in more detail after the launch.

    For now, I’ll share some highlights from the panel. Without giving a blow by blow of the presentations, I’ll recap a few of the audience questions.

    What exactly does ‘out of the box’ mean with CMS features?
    Great question and a slippery slope indeed. Tony cautioned that some vendors will blur the lines in demos between core functionality and add ons that have been developed as ‘demoware’ (or by third parties). It’s essential for folks evaluating vendors to know what’s core to the product and what’s not. It will affect your implementation and your upgrade path.

    Is a long RFP format even useful for picking the right CMS?
    There is nothing like curling up with a good 100-page RFP response on a Friday night, right? Ok maybe we need to get out more. Tony shared with the panel that if done right, an RFP can be a useful part of the process. However, he also advised to provide vendors with specific scenarios to focus the demos on, and challenge them to provide real explanations of how their product meets your needs – not simply yes/no checkboxes. He’s seen RFP responses ranging from 12 to 100+ pages and faults the vendors for not having better internal processes to deliver meaningful responses.

    Are all of the user experience deliverables done before development starts?
    My presentation walked through our process for user experience planning with CMS including the information architecture, template library, content requirements and more. While there are many different approaches, we almost always advise that the core UX deliverables are done up front and used to help gain alignment between the technical and business teams. With that said, some rapid prototyping early in the process can help for certain types of projects.

    How do you justify the value of user experience inside an organization?
    This is an entire post (or book!) in itself. In general, I usually advocate that what’s good for your users is good for business. Meaning if you can increase the effectiveness of finding information and completing transactions, there are real bottom line impacts. Beyond that, smart CMS user experience planning can reduce maintenance costs and create a site structure that can scale with your business. If you flip the question around, it’s scary to think of what it will cost the organization to not focus on creating great experiences.

    Those are a few of the highlights from the panel discussion. It was a great crowd and one of the better panels I’ve been a part of. Stay tuned for more thoughts from Gilbane.

    Posted Dec 11 2008, 06:11 AM by Jeff with no comments
    Filed under:
  • 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.