One of the things I encountered recently during my journey as a Web Developer was the fallout after another developer failed to implement a CMS properly. I won’t go into detail about the systems attempted but I do want to discuss the takeaways from the failures.
Many times larger companies or institutions will view a Content Management Systems as a end all solution to all of their web problems. This is the wrong way to let people look at CMS. CMS (in all of their varying capabilities and architectures) are primarily designed to solve one problem.
Content authors don’t know (or are not good with) code.
It is our job as professionals to correct this view within organizations or when proposing a solution.
There are several things I would recommend in order to prevent a failure to launch a CMS.
Know your staff
One of the first mistakes some companies make is not leveraging their internal strengths when selecting a system. For example it does not make sense to select a PHP based CMS when your company has a full IT staff and most of your developers work within the Microsoft stack of technologies (.NET, C#, SQL Server, ect…). Yeah maybe you’ve got one developer who knows enough PHP to get you buy but remember most PHP based system were built to run on LAMP (or some variation of LAMP) servers. I’m not saying you CAN’T install PHP based systems on Windows servers but they will never operate as well as they could if put on their native environment. This point applies conversely to other languages as well (i.e. you don’t want to use a .NET system if you primarily run a LAMP architecture).
In many cases companies will outsource the implementation of a CMS completely and just accept whatever system the contractor has decided to implement. If you have any internal IT people of any kind make sure that they are part of the selection team when evaluating proposals.
If you don’t have any IT staff then make sure that you intend to form a lasting relationship with your contractor. Even though there are plenty of people out there that use CMS systems finding a replacement who knows the one your using and is familiar with developing for it might be harder than you think. You could find out that your contractor is the only person in your area that utilizes that particular CMS and is certified or experienced enough to implement, develop or extend it.
It is very common for me to work with people who at one point hired a web developer for a one time web site, where the developer builds the site then moves on. 6 months or even a few years later the company is looking for a new person because the old developer is long gone and they have a critical issue that needs to be resolved. Don’t put yourself in that position as a business and make sure you retain a good relationship with the developer, have a maintenance contract or someone on staff who can develop for your system.
Be wary of selecting or using fringe CMSs
CMSs are literally a dime a dozen these days. The market has been flooded with options since the concept was established in the late 1990’s. And since they have been proven to be such a lucrative type of software developers have been cranking out new ones ever year to try and compete.
You have to ask yourself, “Will this system be around in 10 years?” Make sure you select a system that has a well established update cycle. That new CMS may have “The First Drag & Drop Responsive Grid in A CMS” or be “The World’s Best Platform for Designers” but at the end of the day if they are only around for a year then it’s not worth your time.
Establishing YOUR requirements
Undoubtedly when selecting a system you are going to do some research (probably why you’re reading this). And I would expect that your going to read a bunch of articles. When you do here is a tip, IGNORE THE ARTICLES THAT TELL YOU TO FOCUS ON THINGS THAT ALL CMSs DO. Most of the articles I’ve read where largely unhelpful because they would say things like “Make sure it has good core functionality” or “choose one with a WYSIWYG editor you like”. All CMSs (that are worth their salt):
- Have a WYSIWYG editor
- Can create pages
- Can manage assets
- Can reuse content
- Can be customized
- Have roles and permissions
- Have versioning
While it’s good to get an idea of what your requirements should be from articles like this it shouldn’t be the driving force behind your decision. Does it really matter if one CMS uses TinyMCE for their editor and the other uses YUI? From my experience it doesn’t matter because your end users won’t know the difference anyway. If you go onto CMS Matrix.org and put in basic things like this as your requirements your result will be all of them.
Also don’t let a “designer” type pick which one has a “better UI” because guarantee you or someone else in the company is going to be providing training on how to use it anyway. It won’t matter if the UI is “the most intuitive one they have ever seen” because it will still make no sense to someone else. On this point you should still not pick one that has a UI that is complete garbage, my point here is that “prettiness” (or the more PC term “ease of use”) should not be a primary factor in your requirements list because it is subjective.
When you are listing out your requirements be practical. Establish ones that make sense for your organization. Things like total project budget, technology requirements, identifying the “addons” (like eCommerce or event calendars) that your company actually needs and whether supports your authentication model. There are tons of other things that might apply to your industry as well like multi-language support, web standards enforcement, marketing tools (like persona support). These other bells and whistles should be identified as requirements from the beginning.
Make sure that the department or person “requiring” something plans to use that feature. Often people see something as an option (like persona marketing) and say “Ohh hey that would be nice”, but then after the system is implemented they never actually use the feature. They are called “Requirements” not “Things that would be nice to have”.
Do your homework
Once you’ve narrowed down your selection to the final few, request or build a demo with of you site data (not just a sales demo). Most places will skip this step but if your about to invest $25,000 – $100,000 on a new system you better get into that system and test it out. I’ve seen companies piggy backing on other contracts to get a system they think will work purchased only to find out later that they can’t even get the thing installed or don’t have anyone on staff who knows the language it’s built on.
I’ve also seen developers try and take shortcuts and after watching a sales demo say, “it looks great let’s just buy it”. Sales demos will always look great but sales people will never show you the parts of the system that don’t work very well. With out building your own demo (I’m talking to developers here) you run the risk of finding out after selection that the one you recommended has some serious issues that you didn’t notice in the demo.
I could provide more examples but here is the point: if you don’t get a proof of concept demo before you invest your money and more importantly your time, you could be setting your self up for failure. You need to remember that you are not only spending money up front to get this going but you are probably going to have this system for the next several years (if you choose correctly). You do not want to be in the position of finding out that half of the promised functionality doesn’t work as expected or that the system has some very noticeable bugs after you’ve already made the purchase/selection.
Even if you decide to use an open source system (open source = free) you still to take consulting and training costs into your budget. If you are working with a consultant require, a proof of concept demo before buying in completely (especially on larger contracts).
Tell me what you REALLY think...