While each implementation has unique goals and intricacies, here are some common themes we see on a regular basis.

Expectation #1: A CMS should solve the most urgent business problem at hand without regard to specific department, person or function.

We have a saying at Bridgeline, “Good politics makes bad websites.”  I think too many people go into a CMS implementation thinking it will solve everyone’s problems across the entire organization.  So rather than focusing on the most troublesome areas, people tend to open the implementation to everyone’s requests.  In the end I believe this does a disservice to your organization.  Because the truth is that while every department or group may have a need, from a more corporate/macro view those needs have different priorities.

One of the things we do first is to assess the business problems or pains of the organization.  Two key questions are asked:  What are the drivers to “want” a CMS and what happens if no action is taken?  These two very simple questions can certainly help prioritize and let organizations focus on what is truly important.

So expect to be asked these questions and be ready to juggle priorities to get work done in phases.

Expectation #2: Content owners should take control of their content.

Too often we see a CMS be implemented only to have IT still heavily involved (e.g., adding a new navigation element, search index updates, publishing schedules, etc.).  I’m an IT person at heart and I fully understand the logistics and realities of managing secure web applications.  But at the end of the day (unless you’re in an IT  business), the technology group is a business enabler.  Content and business unit owners should expect that their site is theirs.  You own it, you manage it, you add to it, you change it, etc.  If there are workflows needed for approvals, no problem.  That should be part of the CMS implementation.  But it should be everyone’s goal to not have IT part of the day-to day operations of a site.

Expectation #3: The CMS technology “tail” should not wag the user experience “dog”.

This goes along with expectation #1 above.  The CMS is a means to get to the end goal of solving a business problem or alleviating a pain point.  It is not the driver.  So expect to do some upfront user experience design before selecting a CMS.  Information architecture, design and overall user experience should always come first, then choose a CMS that is flexible enough to implement that vision.  For smaller projects without a great deal of functionality, many CMSs may be just fine.  But for larger, complex application development managed by a CMS it’s important that you understand not just written business requirements but also how that translates into the user experience and visuals (not design, but wireframe flow).  Whether internal or via a development partner, someone can help mock the user experience from a high-level to drive CMS requirements.

Expectation #4: CMS is a marathon, not a sprint.

Just like anything you buy, it needs service.  It needs to be cared for, upgraded, enhanced and managed.  As your business grows, so do your needs.  We often see people say things like “let me get the site up with 2010 dollars and then I’ll think about what to do next year”.  While it’s great to see people take action, it’s important to understand that if you leave it alone it will not be successful.  By no means am I saying every 3 months build a new web application.  But just understand your business (e.g., keeping up with competitor cycles and the overall business’ corporate goals and timelines) and expect to make continual investments.

Don’t discount the above because of its simplicity.  It’s quite often these things taken for granted and people set themselves up for missed expectations.

A CMS can be a great tool.  Make sure it’s implemented successfully.