I can’t tell you how many times we’ve seen organizations buy a CMS, take their same content structure, and simply distribute authoring ownership to every far flung corner of the organization. And let’s not entirely blame the organizations. It’s how CMS is sold. And it’s a myth, straight up.

ECM is an aspirational term for many, one that suggests a single layer/platform/system/methodology that will address your enterprise content needs no matter how complex, diverse, or voluminous. Some major vendors promote this approach, and buyers for such systems also exist, but they make up only a small minority in this market. So, though it may seem a little dull by comparison, from now on we will use the terms Document Management and Records Management where they apply, and will reserve the exotic ECM moniker for that rare breed of big, complex, and typically very expensive platforms that actually merit such a grandiose term.

“Our department is different!” This is a common and legitimate response from groups used to managing their own websites. They argue that their needs are so specific there is little chance a common template can work.

I going to try and impugn one of the great concepts of content management: metadata. I’m going to argue that in the world of Web content management (WCM), it doesn’t really exist. Well, it might, but if it does, it’s awfully slippery to define and defining it doesn’t give you much value anyway.

Often, one of the big justifications for a CMS is removing the webmaster bottleneck and delegating content entry to the people who have the information. The implicit assumption is that everyone wants to directly maintain their portion of the website but technology is standing in the way. But if you visit a CMS customer a while after implementation you are likely to find that the responsibility of adding content is still concentrated in a relatively small proportion of the employee population.

It is easy to get excited by this functionality. But then you think of the difficulty your average organization has with even the basic aspects of content production and you wonder if they ready for these tools. How can you do an A/B test if getting someone to write option “A” is a struggle and option “B” would be a miracle? Of course, not all companies suffer from these issues. The more sophisticated publishers and eCommerce companies have been doing these advanced site management activities even when the technology stood in their way, much less facilitated them. But your average marketing site is still in the dark ages when it comes to managing content.

They have an incumbent provider of enterprise solutions, one of the large vendors, who they’d like to evaluate alongside other offerings. (And no, being strictly vendor-neutral, I’m not going to mention the vendor in question, or the client for that matter.)

It’s been a while since I’ve seen this product, so it seemed like an ideal reason to get in touch to obtain a full demo of their current CMS offering. Looking through my records: no, don’t have a specific contact person for this vendor.

Ok, I guess I’ll just have to ring them up. Now the fun really starts.

The call is answered by someone clearly not in Australia, who asks me the nature of my call. “I’d like to talk to someone on the <product x> team.”

“Well, I’m going to have to ask you some questions first.” I then get the 20-questions treatment, asking me the nature of the project, the budget (can’t tell you), the name of the organisation (can’t tell you), when the decision will be made (hopefully early next year). I explain our role in the marketplace, and highlight some of the notable clients I feel should grab his attention (such as Westpac, BHP Billiton, federal government agencies, etc).

20 minutes later, he’s written all this down, and promises to “pass it on”. Two days later, he rings me back to “check on the details”, and we go through the whole lot again.

A week later, I get a phone message from someone at the vendor. I return the call, and go through the 20 questions again, asked in a different way. I’m informed that if I can’t reveal who the client is, it’s “difficult” for them to provide me with an actual contact. They’ll look into it, and will get back to me in a few days. I’m assured that they “aren’t trying to be difficult”, but that isn’t the way it seems to me.

So a week-and-half later, I don’t know anything more about their product, and the clock is ticking. Fail.

It seems this vendor has very carefully put in place processes to prevent potential customers from talking to them, unless they’re deemed “important enough”. I certainly felt like I was the one who had to prove myself, instead of them trying to sell to me.

It’s a funny way of doing business, and it makes me wonder:

Are the big vendors hungry enough for new business?

I get one-hour responses from most vendors within Australia, and regularly receive demos from them. I’ve had vendor CEO’s showing up to walk through products. But not from the really big enterprise vendors, where it’s consistently hard to even find someone to talk to, let alone to get information from.

What have your experiences been?

In one case there was a comprehensive site redesign that included digital strategy, re-branding, and information re-architecture as well as implementing new functionality. In another case, the client was shifting to an outsourced model where a partner was to maintain the full infrastructure and assume all development responsibilities. In situations like these, while the software is important, the biggest risk is choosing the wrong partner to work with.

Drop-in labs are a great way to make the rollout process smoother. A drop-in lab is simply a set time where you invite users to a working session with staff on hand to help. Not only will the labs help reduce support calls and e-mails, but they can foster community among your web authors and encourage peer support.

A truly great idea! Everyone should be doing this…

Their needs were fairly straightforward:

• Take documents stored in the RMS, select the desired ones via the CMS, and publish them seamlessly to the public website.
• Locally cache copies of the documents to reduce the impact on the RMS, and automatically refresh the local copy when the RMS version is updated.
• Allow site visitors to fill in online forms, and store this data directly in the RMS to meet recordkeeping requirements.

It’s lucky that this project has been going very slowly, as a year ago (when they last had time to consider getting a new CMS), there were almost no products in the market that could meet this need out of the box. Thankfully there are now a (small) handful of solutions that can do this, mostly Australian-developed products.

This is a common requirement, amongst government agencies, local councils, and compliance-driven firms. This would be slam-dunk during the sales process for these types of organisations. At yet, capabilities in the CMS marketplace are weak at best.

Why do more CMS products not offer simple integration with records management systems?

When they do have this capability, why don’t they market it?

Many Web CMS products tout “in-context,” wiki-like content editing as an important feature or enhancement. In-context means letting contributors create or edit content from within the context of the site, without actually having to retrieve a content item from the back-end and filling in long forms.

If you’re following the content management space closely, but aren’t a Java wizard, the JSR (Java Specification Request) numbers can become a bit of a puzzle.

I’ve recently had several conversations that went something like this. A vendor told me, “we’ve added JSR-186 support,” (confusing it with JSR-168, which is not uncommon). So I replied, “you mean the JCR?” (guessing they may have meant JSR-170.) To which they said “yes, the JSR.”

Over the years, I’ve seen a large number of web site functional designs, technical designs, requirements, wireframes and mock-ups. But usually, the one thing missing from the planning of a WCM-driven web site is what’s most likely to shoot the implementation in the foot: the functional design of the CMS back-end. The form & function of how the CMS will work, look and feel for the end-user of the system, not the visitor to the web site, is too often overlooked.

The technical infrastructure underpinning web sites has also evolved significantly since WCM was born. We have moved far from the early days of HTML pages and CGI scripts that add dynamic content often from a single database to platforms providing presentation templating and layout, content creation and editing tools with content aggregated from multiple sources both text and digital media. Expectations have changed as well with content creation and management being readily available to non-technical users.

(A few years back I wrote on the same topic: Dynamic or batch publishing?)

Regardless of which type of evaluation process is being followed, there is a final short-list of typically three vendors. These vendors are asked to give a structured demonstration, and then the final decision is made.

Too often I’ve seen shortlists with remarkably different products on them, and if the requirements and selection criteria are working properly, this just shouldn’t be possible.

Having worked on dozens of CMS selection projects, this is a good “sanity check”:

The products in the final CMS short-list should be similar, or the selection process is in trouble.

This means:

• All shortlisted products meet core CMS requirements.
• All products should be strong candidates.
• They should be the same “type” of products (and not a mix of web CMS, collaboration tools, IT platforms, portals or document management systems).
• The products should be roughly similar in size and complexity (eg there should not be an “enterprise” CMS alongside a small-scale offering).
• They should all run on the same (preferred) technical platform (IT can easily knock out products because of the platform they run on, leaving just one or two).
• They should all be affordable within the budget, or close thereto.

Now, this is not to say that there can’t be some variation. There’s no problem with having a mix of closed source and open-source options, as long as it’s managed well. There can be both “mid-market” and “upper-market” offerings, as long as this is done deliberately to help understand what paying more would get you.

At the end of the day, you want three strong candidates to pick from so you can be confident that the best solution has been found. If the final short-list fails the criteria listed above, double-check the whole process, and if necessary, get some outside expert input.

Your thoughts and experiences?