A typical question I get asked when assessing failing CMS implementations is whether there’s a fundamental flaw in the product or in the way it’s been implemented. Some products are more difficult to implement than others, but businesses can be hasty in wanting to throw technology away when the implementation has failed to meet expectations.

While you can make any product do anything if you have an endless supply of time, money and ingenuity, it’s useful to have some idea about whether you need to throw your core product away to achieve your goals feasibly. So I thought I’d list a few typical warning signs that might prompt you to initiate a technology selection project:

• Wrong technology stack — You’d have thought this would be obvious; but if you’re living in a Java world and you have a .Net, ColdFusion or LAMP product, you’re in trouble. This also applies to legacy systems coming out of support.
• Unfriendly URLs — You could get around this with some clever rewrite rules, but it’s extremely tricky to do this in a really scalable and cost-effective way.
• Incompatible workflow — If your CMS doesn’t allow you to implement your online publishing processes, you have a serious problem. Integrating a distinct workflow tool could be more trouble than it’s worth.
• Running Active X components on a Mac — This is a way to alienate your user base. Don’t use anything that relies on Active X. Even if you’ve locked down all your editors’ PCs to use the same version of Windows, these components can be a headache. There’s plenty of tools out there that use cross-platform, browser-based technologies, so why give yourself this burden?
• Auto-generated non-compliant mark-up — Many portals (including MOSS Sharepoint) provide you with default templates into which your content is published. Trouble is, they rely on HTML table layouts and JavaScript that are a long way off best practice for being well-formed and accessible. If this is important to you, it can take a lot of effort to fix. You have to weigh up this level of effort against the advantages the product gives you, or against simply throwing the tool away.
• Poor security — A requirement that’s more obvious to some organisations than others. Some CMS (dynamic-delivery products tend to be more susceptible than those using static delivery methods) are prone to brute force attacks, so if you could be vulnerable to DDoS you should get this evaluated. You should also ensure that your product doesn’t suffer from SQL injections.
• Lack of integration standards — If your CMS doesn’t work with your LDAP directory, you’re in for a world of pain…
• Poor version comparison — As with workflow, does the CMS provide you with versioning and audit capabilities that match your business processes? If not, there are tools you can integrate with no little effort, but why wouldn’t you just pick a CMS that does all the red-lining and version comparison for you?

This isn’t an exhaustive list. What characterises these issues is that while you could address them with some outside-the-box thinking, the problem is likely to be so ingrained in the product that dumping your current technology is a more viable approach. And at that stage, when you look to select a new technology, all the points listed above should be the technical prerequisites you have when inviting suppliers to tender. During the selection process, you can then concentrate on organisational fit. This is a subject I’ll return to later.

But what if the reason your implementation is struggling isn’t listed above? It could well be down to the implementation. Most common things people blame on the product, but are actually a problem with how the product has been implemented are:

• Performance — Hardly ever down to the product, in my experience. Can almost always be improved, if not completely solved, by improving infrastructure (not necessarily more licences) and information architecture.
• Unfriendly WYSIWYG editorial interface — There are lots of free or cheap tools out on the market which provide friendly and standards-based ways for editors to add rich content to your CMS.
• Poor classification systems — Products have limitations about implementing taxonomies and classification systems, but typically if you’ve trouble managing these in enterprise products, it’s more likely to be because of how you chose to do it rather than a fundamental flaw with the product itself. It may well require some bespoke work, but doesn’t mean abandoning your entire system.
• Having to publish in multiple places to generate a single piece of content — This problem is more often found with component-based content management systems, such as Tridion and Percussion. Editors have to publish blocks of related content that then go through independent workflow processes only to be assembled on the same page. There’s an advantage that these are re-used elsewhere on the site, or translated into other languages more efficiently, but the big disadvantage is that editors are confused by what needs to be published in order to make one simple update. In my experience, the business blames the technology when it’s just down to how it’s been put together.

Hopefully this will steer you down the right path when you need to decide whose arse to kick: software supplier or systems integrator / design agency. But more than that, it should give you an idea about where to focus your energy for new requirements: do you need to run a technology selection project or can you build on the platform you have currently? We all know that things break, but if you know whether it’s the what or the how that’ll do it, you should be able to put some contingency in place, saving some blushes and some money.