Helping Clients Select a CMS Solution

We have an extremely diverse client list, from the Fortune 500 to funded start-ups to two guys in a spare bedroom with a great idea. Many of our clients have web initiatives powered by large-scale custom built/modified back-end systems. However, almost all of them require a CMS, Content Management System, solution of some sort – whether just to power their blog or to power their front-facing non-application informational site (think ‘the marketing website’ vs. ‘the actual web application’). We highly recommend that our clients keep their non-application informational site separate from their actual web application – just because the web app crashes is no reason your sign-up process, blog or contact information should go down as well. Because of this separation, the CMS selection process now has many more options; it can be powered by any programming language, platform, third-party service and can even be hosted on a different server (probably should be regardless). So, in this endless sea of options for selecting a CMS, how does one filter through it all? Whether the CMS is powering your entire business’ web presence and handling mounds of data in a variety of formats or simply powering a blog, the question as to which CMS solution to use is a common one.

Like with everything we do for our clients, we try and boil it down to just answering a few simple questions; in this situation, we really only care about three:

1. What type of content will be present today and tomorrow?
2. Who will be adding, updating and maintaining the content in the CMS?
3. Who will be customizing, developing and maintaining the code of the CMS?

This is all that actually matters in selecting a CMS solution; or at least the base for what really matters.

What type of content will be present today and tomorrow?

The first question is the most complex, we need to understand the type of content that will be present and from that we help our clients figure out the best format to present that content to their audience. In understanding the content, content types, content hierarchies, and the relationship between content we get a better sense for what functionality the CMS requires, how robust, flexible and scalable it needs to be – as it relates to the content (and remember, content is king). The objective is to recommend a solution that has ‘out-of-the-box’ as many of the features the client’s content requires as possible. And to ensure the solution is flexible enough to accommodate the features that are not ‘out-of-the-box’.

Who will be adding, updating and maintaining the content in the CMS?

This is a critical and often overlooked question that plays a huge factor in our recommendation. In understanding who will actually be using the CMS on a daily basis from the administrative perspective, we really get an understanding for how the CMS will be used by the organization rather than its audience. It is important to understand the organization and the members of that organization when analyzing their content and technical objectives. For example, if the organization internally can’t grasp the concept or applicable use of a wiki then we cannot certainly expect them to manage a proper wiki for their constituents. We need to problem solve how to accomplish the same objectives as a wiki format might without using a traditional wiki – we do advocate changing functionality and altering behavior based on the resources within the organization. We don’t believe in trying to change the organization; especially when it is that organization who will be maintaining and using the CMS on an ongoing basis. Another factor to consider is the technical proficiency of the editorial team. If the word ‘HTML’ scares a content editor and that same editor is candidly not very tech savvy, then we know we need have a very easy to use and intuitive CMS, from the perspective of the admin side of it all. The goal is simple: make sure the recommended CMS solution is a right fit for the organization’s internal team that will be working with the content directly.

Who will be customizing, developing and maintaining the code of the CMS?

Much as to the previous question, this one still focuses on the organization’s internal resources, but more so on the technical team. We must identify if the organization has an internal resource for working with the code-behind. If that the technical team has PHP experience, then it makes the most amount of sense to pick a PHP based CMS. Often times our clients don’t have internal technical resources and also have restricted and limited budgets for ‘on-going maintenance’. In a situation such as this we tend to recommend open-source PHP solutions; primarily because the development community behind them are much larger, making finding reasonably priced freelancers/contractors easier; most everyone can work around WordPress for example. We agree that open-source doesn’t ultimately matter, especially when talking about something as robust and affordable as ExpressionEngine, which has a very strong developer community behind it.

Answering these three questions lets us develop a requirements document. A document that essentially tells us what the CMS needs to do as it relates to the content, the user-base and the internal organization itself. When creating a requirements document, we work to establish what the client needs out of a CMS solution to get them to a successful launch. However, we also discuss what the client might have in store for phase two or phase three in the next six to nine months. We want to ensure the solution we provide can accomplish the objectives desired within the first year with a theoretical ‘flip-of-a-switch’. It is about ensuring the solution is flexible, scalable and robust enough to get there.

This is essentially ‘how to select a CMS 101’ – for the clients that need help in selecting a CMS. Our goal is to consider the client above all else; their content, their resources, their limitations, their budget, their audience – select the CMS that is right for them over the CMS that is most convenient for you. As a designer/developer, you may have an unnaturally strong distaste for Drupal, ASP .Net or DotNetNuke or you may simply not be proficient with Rails or experienced with Ruby based CMS solutions – that doesn’t mean that isn’t the best recommendation for a particular client. On many occasions our assessment has lead us to a recommendation that ultimately doesn’t make us the best suited team to execute. In situations like these we happily inform the client of what we believe is in their best interest and why, and also supply them with a strong list of capable resources that might be better suited to execute the recommendation. When selecting a CMS solution for a client it isn’t about closing the deal or getting check-in-hand; it is about ensuring the client has a solution that will get them to a successful launch as well as be flexible for the on-going use of the CMS and its anticipated short-term evolution.