March 3, 2013
Whether you are evaluating a CMS application as part of an overall website redesign, or your business is scaling up and you are ready to jettison your excel spreadsheets, I wanted to share a few common pitfalls that you might want to avoid.
Choosing a Geek friendly CMS
In an effort not to alienate my IT friends, let me clarify the title: allowing an IT person to be the sole decision maker in the CMS purchase is a bad idea. Please, don’t throw your mouse at the screen- it’s nothing personal! However, it must be stated that, at the end of the day, choosing a CMS is a content and technical exercise – not strictly IT. Although it is essentially a software application, members from both the technical and non-technical administrative team should to be included directly from the initial requirements definition phase. IT should be involved throughout each subsequent phase, however, with slightly diminished input, up until the actual purchase. The point being that you need to make sure that the content team and other end users are brought on immediately as well. Side note: make sure that the other end-users are clearly defined– depending upon your needs, this could even include HR or even the CFO.
What I’ve seen play out, when this wasn’t the case is twofold. If the content team is excluded early on, then requirements tend to be based solely upon the needs of the technical team; and invariably what happens is that the actual admin interface and workflow concerns tend to be minimized. Conversely, if the technical team is excluded early on, than the needs of the users are reflected and the technical requirements get left behind, only to be brought to light during the implantation phase. Either way, it’s much easier to move forward as a united front versus trying to dance backwards. In some worst case scenarios, I’ve seen the CMS take months versus weeks to implement, with the net result being a loss of potential revenue.
At the end of the day there should be a nice compromise reached between the two sides. The IT department will get a robust, scalable system and the administrators will get an easy to use interface whose workflow capabilities will mirror those already in existence. And as a result, the end user – your audience – will win, because their needs will be satisfied by brilliant, engaging content that is easily accessible at all times.
Thinking that pre-built is better
A fundamental part of building usable systems involves understanding the day-to-day workflow of the staff that will be interacting with the site and how it relates to the tasks they need to complete. This desire to provide a system that accommodates the end-users actual needs, is often at odds with the pre-built systems currently on the market (e.g. Joomla, Drupal, Wordpress, etc.). These platforms promote an overload of features in an attempt to portray the everything to everybody ideal. The problem that I’ve seen crop up is that only a small percentage of features ever end up being used. I’ve looked through some Admin panels that looked like they could be used for navigating The Space Shuttle Atlantis. But, after scoping out the actual day-to-day workflow, it became apparent that these features tended to distract and frustrate due to lack of use and understanding. A perfect analogy is MS Word and all its multitudinous functions that keep staring at you in the face every time you open it to start a new document. Go ahead, look up at the top of your screen and start poking around – what percentage of the actual features do you use on a daily basis? It’s cool that they are there, but if your revenues were tied to MS Word’s efficiency, how many of them would you keep?
Bigger (more functions) is not always better. That’s why so many companies ultimately go the customized CMS route. In the end, it boils down to your needs - your workflow, not someone else’s preconceived notions of it.
Yes, I get it, many large companies use pre-built CMS systems to start; and it’s always reassuring to be in good company. What you might not realize is that those companies also have internal teams reconfiguring those systems to meet their needs, run the actual day to day functions and applying frequent security updates. Translation: they got a free template because it’s easy, but still end up spending big money because of a need to tailor the systems and keep them secure.
Although I’ve maxed out my analogy card, I am going to play my bonus analogy for the freeware mode of thinking: the open source Linux OS. There are a huge amount of organizations who insist on running Linux – if only because they don’t want to be tied to Windows. Yes, it works for them, but at the end of the day they are all paying developers to customize it to their own needs – only the download was free.
Being Short Sighted
It is important to consider not only what you need currently, but what you will need the CMS to support in the future. Do you have plans to include more content – or build online forms, or surveys? Perhaps there is a goal to include additional e-commerce functionality to your site within a year. Maybe part of your organization's strategy includes frequent mergers or acquisitions (and therefore requires a CMS that scales easily and offers a sound methodology for repository aggregation). Make sure that you define known (and some speculative) future requirements as part of the requirements gathering process. Otherwise you may find yourself out shopping for a replacement CMS well before you've gotten the return on investment out of the first.
Asking ‘how’, not ‘what’ questions
The selection process must focus on asking 'how' questions rather than 'what' questions, with the aim of building a clear understanding of the products' strengths and weaknesses. In general, this is best done by taking things back to the underlying business need, and asking your development partner to outline how they can build that CMS to fit that need.
In practice, the success of the CMS project rests on how well the solution fits the day-to-day requirements of the authors and site administrators. This comes back to how the product actually works, in detail. While stating: "The CMS must provide powerful and flexible workflow capabilities" on your RFP - or internal documentation - sounds desirable, but in point of fact, how do are the workflow features really going to be used, and by whom? Flesh it out, be specific – take a survey in your office and chart out the answers. The funny thing is, that this process might actually expose any redundancies or expose any weaknesses prior to the purchase. How does the blog actually get written, and then placed on the website? How does the person responsible for graphics find, store, retrieve items. How does your Facebook page get updated?
Asking the ‘how’ will help clear away some of the smoke and mirrors often associated with pre-packaged CMS applications. It is the best way to get the full benefit out of customizing the CMS to fit your workflow, and not get bogged down with features that might end up being redundant (and expensive).
Writing requirements that fit your needs
Yes, you want your CMS to fix all of your current problems, and any unforeseen future ones as well – I understand. But, fundamentally, writing more requirements actually makes it harder, not easier, to find - or build - the right CMS. The reality is that writing too many requirements tends to lead to significant problems, including:
- Confusing key needs with 'nice-to-haves'
- Forcing the selection of a larger and more expensive CMS to meet all stated needs
- Increasing the time and effort required to move forward with an SOW
- Increasing the time and cost for vendors to respond promptly
- Discouraging many vendors from responding entirely
RFP documents should instead focus on the key selection criteria that will drive the evaluation and differentiation of the products. In general, there are rarely more than a dozen key selection criteria, along with supporting requirements (documented as being of lower importance) – stick to them.
Are there more issues that can crop up? No doubt about it, and that’s not even considering the technical issues relating to integration. While this wasn’t meant to be exhaustive, it should get you thinking in the right direction and hopefully reach a solution that drives your business forward and makes the lives of those behind the scenes easier.
Authored by: Attila Sary