One question that often arises early in the process is whether the same CMS should be used for the website and intranet, or whether two solutions should be deployed.

Historically, this question was often driven by a desire to reuse the public-facing CMS for the intranet. These days, the question is equally likely to relate to reusing the intranet solution (such as SharePoint) for the website.

While there are advantages to having a single solution, this is not a ‘slam dunk’ option as this article will explore.

[May article, read the full article]

I am more cynical about quantitative methods of evaluating vendors. It makes me think of people who buy wine simply based on what The Wine Spectator rating is (without considering the food they might drink it with, or what they actually like vs. what Mr. Wine Critic likes), or my single friends who have a checklist of what they will or won’t accept in a mate. “He must be this tall, have this color eyes, and make at least this level of salary.” Well, the world simply doesn’t allow you to pick partners based on a checklist, perhaps unless you’re Tiger Woods.

CMIS (Content Management Interoperability Specification) has been ratified as a standard by OASIS. What is it and what does it mean to buyers and users of ECM and Document Management technology? Well put simply, CMIS is the most important new standard in the ECM world in decades; it is critical for any enterprise scale RFP.

We strongly advocate a test-based approach to procurement, based on the value of scenarios; nevertheless, many enterprises want to apply a quantitative, spreadsheet-based assessment approach. In some cases these can become really quite complex. We have advised on dozens of scoring spreadsheets, and like to think we have seen them all.

This is a good post, and I agree completely with Alan’s recommendations. In the work that we do, we encourage our clients to use a super-simple scoring approach. This is enough to put some shape around the evaluation, without falling into the trap of over-complex formulas.

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.

“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.

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.