I just published my CMS Selection Workshop handout on Scribd. The handout contains:
Examples of how to specify content types
Example usage scenarios
An example RFP table of contents
An example vendor demo agenda
Enjoy!
While it may seem counter-intuitive to listen to a supplier telling you how to buy, you should definitely read Deane Barker's article "Five Tips to Getting a Good Response to a Content Management RFP." Deane is a co-founder of Blend Interactive, a web design and development firm. That may put him on the other side of the negotiation table but, as a potential partner, he wants you to be successful in your initiative as much as you do. That is actually not so out of the ordinary. As a consultant, you want to spend your time with clients who you have a great working relationship with. The better consultants can be more selective in the opportunities they pursue and nothing sends off more bad vibes than a dysfunctional selection process.
The article agrees with all the advice that I give on my blog (it even quotes me!). The one tip that buyers are going to question is openly stating budget. I tend to go back and forth on that myself. The benefit is that budget is the best way to communicate what you think the size of the project is. Getting that piece of information out in the open early will help the vendor present a solution that is in line with what you had envisioned. It also reduces the risk of harboring unrealistic expectations of what you can do. The risk of communicating budget is that the integrator will inflate the price to maximize margin. My current thinking is that you shouldn't be working with a partner who you fear will take advantage of you. You should structure your selection process to verify the integrity as much as the skills and experience of the vendor.
If you are in the market for a development partner, read these tips. If you can get to Boston next month, you should join me in my CMS Selection Workshop at the Gilbane conference. In fact, Deane is going to be there too.
How could the RNC not select a CMS called The Red Elephant?
(this image is copyrighted by Red Elephant ICT & Internet Services)
Gregor Rothfuss sent me a link to a report about a ridiculous CMS RFP issued by the RNC. As I have written before, the traditional RFP process is totally broken. Here, the RFP asks for innovation around sketchy buzzwords that are meant to be requirements yet still asks for a fixed bid. I wonder how the RNC could avoid selecting a CMS called The Red Elephant?
In my Web Content Management Selection workshop at last year's Gilbane Conference, I told a story about a fictitious botched selection process for an imaginary website. This may be one of those cases where reality is better than fiction so I am thinking that the RNC RFP should be my anti-example when I teach the selection workshop this summer.
Last week I was a panelist in a jboye08 session called "Running a Web CMS procurement." Jarrod Gingras from CMS watch moderated the panel that also included Graham Oakes, Piero Tintori, and Søren Sigfusson. It ran for 90 minutes and, quite frankly, we barely scratched the surface. I must admit, I share the blame because I used my 10 minutes just to ask the audience a bunch of questions (see slides). Fortunately, I will have an opportunity to do justice to the topic when I present my "How to Select a Web Content Management System" workshop at the Gilbane Conference in Boston next month on Tuesday December 2nd.
Over the years of doing CMS selections, I have refined my approach to address the specific challenges that are unique to web content management. In particular:
The huge number of products to choose from and the lack of a clear market leader
The different sources of content technologies: commercial, open source, SaaS, and custom
The flexibility of these platforms
The importance of usability
The spanning of technical and organizational concerns
The different uses of web content management software
Web 2.0 and now Web 3.0
The fact that the platform winds up being a component of a larger solution that includes implementation, process, management, and support
And the wide range of processes that organizations use to manage their content.
I have written extensively about selection on this blog here, here, here, here, here, here, and here. Here is a chance to put it all together in one (hopefully) coherent session. If you are already registered for this workshop, please feel free to email me (seth "à" contenthere.net) with any specific things you want me to cover. If you are not already registered, you can do so so here. You can even get a free iPod Touch if you go for the "all in" Conference Plus package.
If you are going to be in town for the Gilbane Conference but will not be attending any of the workshops, you should consider going to the CM Professionals Fall Summit, which is also on Tuesday. I will be on an expert panel talking about the content lifecycle but I will be sure to save something for the workshop :)
A while back, I wrote a post on selecting a CMS. I have since gotten requests for more step by step instructions. While, the process is not so formulaic that it can be written into a recipe, this is the Content Here approach. This methodology is optimized for the complex content management projects. Some of the steps require a deep background in the content management marketplace or help from an expert. But here they are.
Document the content types. Before doing anything, you need to know about the content that is to be managed: its structure, frequency of creation and updates, and who is responsible for it. Usually, this is a good time to visualize better ways of structuring, organizing, and managing content assets.
Document the scenarios. Write short, narrative-based scenarios describing what the system will be used for and how. Stay away from implementation specific details as much as possible. For example, rather than say "the user clicks a 'check spelling' button and the system lists misspelled words," say "the system notifies the user of misspelled words." This leaves it open to the product to determine the best way to meet the requirement - is it with color underlining as the user types?
Document the legacy systems. Most Content Here clients require integration with legacy systems. It is important to understand them, how they are deployed, and their interfaces. A diagram showing the existing enterprise architecture and how the content management platform fits in is very helpful.
Filter by technology. While content management is all about usability, start by developing a short list of products that are technically capable of meeting the requirements. The biggest reason for doing this is that evaluating for usability is such a subjective and intensive process and it is impractical for both the customer (and the vendor) to demo more than a couple of products (you will see this later on). You might have some non-functional constraints like the system has to be customized in Java or run on Windows. To do this step effectively, you really need to be immersed in the marketplace and know the different products and who is using them for what. Buy a CMS Watch report (WCM or ECM) or hire a consultant (like Content Here) or, better yet, do both. Based on the questions that I get, I think that sites like CMS Matrix are more likely to confuse you than help you.
Filter by price. If a product is way beyond your price range, you should either filter it out or see if there alternative licensing models that meet your budget.
Engage with the vendors. If you have been following the steps 1 through 5, you should understand your content management requirements and have a short list of 3 or so products that would all probably work in your environment. The next step is to find the product that your users will feel the most comfortable using. Hopefully, the software vendor understands your needs and will partner with you to meet them. If two products are very close functionally, I tend to go with the vendor that will be more helpful in the initial implementation and beyond. This is where I think the traditional RFP process is broken. Rather than create a formal procurement process that tries to compare "apples to apples," you want an informal, interactive process that will highlight the differences between the vendors and their approaches. You want to share as much information with them as you can. If you don't trust a vendor, they should not be on your short list.
Prototype and learn. Because each vendor on your short list has a good chance of winning the deal, and you are not giving him a 100 page RFP to answer, he should be willing to invest the time to build a prototype that will demonstrate how his product will support your content types and usage scenarios. If an open source product is on your short list, consider building your own prototype or paying a systems integrator to do it (this will give you an idea of what it is like to work with the systems integrator). You should evaluate the prototype as actively as you can. Ask what can be changed and how. Ask the vendor to give you access to the prototype so that users can play with it at their own desks. Have your users think outside of their normal day to day and be innovative. Teach them about best practices in content management.Hopefully, the prototype demonstration was like a training session so the business users are comfortable finding their way around the system. If you intend to have your technical staff help with the implementation and/or maintenance of the system, now is a good time to request the developer documentation and access to the customer support site. Schedule a technical session where the prototype builder walks through the code and configuration that he did to build the prototype.
Project what an implementation would look like. To get an idea of the total cost of the solution, do a project planning exercise of what it would take to implement the solution and customizations and migrate your content. You will be better off if you plan for an iterative deployment where the first release supports the bare essentials and subsequent releases layer in more functionality. This is especially the case when your users are new to content management or have been using a limited toolset. They will learn so much about their needs from the first release and have wonderful ideas for improving and extending the system.
There you have it. Eight easy steps to select a CMS.