I’ve been delivering web content management solutions for a while now and like a lot of folks out there I still find it extremely challenging. It’s never a walk in the park. No two are the same. And the results lie between the two extremes of weird and wonderful. The bigger the customer, the more intriguing the experience. Customers definitely come with baggage, others with wild expectations. So when a couple weeks back, at the Janus Boye Conference Jon Marks crowd sourced opinions using the twitter hashtag fixwcm on the “How to Fix WCM” track I followed with keen interest. Firstly because I didn’t think for one moment that WCM was broken. And secondly, I thought it was just a distraction from the underlying fact that we are broken!
It’s not the tech
For the last five years, I’ve found that web content management solutions have not been technically challenging at all. I don’t think we have a problem with tools. I don’t think there is a problem with vendors bigging up their solutions. That’s marketing and that’s here to stay. I welcome analysts providing vendor-agnostic feedback to assist customers in their selection, but they too add to the decision making uncertainty. Also, we should not lay all the blame at the doorstep of the poor implementation provider. Shit just happens. So that leaves the customer right. Although they pay my wages (and thanks for that), they not without fault either. So if no-one is to blame, what’s going wrong with WCM?
Jon’s post conference blog captured the mood. But the following tweets were right on the money:
[jdavidhobbs]: I think the lack of common vocabulary / architectural model of CMSes is a pretty big issue.
[chrisregan]: Differences in vocab and architecture, common even within a single vendor. Either get consistent quick or slow down cross-selling.
It’s us
This is not a riddle, but answer me this, sitting in your CMS world:
What is a template vs a component?
Guaranteed, as both David and Chris allude to in their tweets, and I continue run up against is ‘The Attack of the Assumptions’. I bet you already have an answer in your mind and it will most definitely be different from mine. Better still, you’ll hit back questions.
Now everyone knows there is a skill to asking the right questions, to elicit the appropriate answers. But it’s the questions you don’t ask that come back to bite you. The unasked question leads to assumptions, which in turn manifests themselves as expectations. Unmanaged expectations leads to unhappy customers. Unfortunately, because there is no shared vocabulary between customers, analysts, vendors and implementation providers, there is a high probability that the wrong questions are asked and right answers are never provided.
This is what is broken. And we can make steps to make this better. But we will never completely fix it. Because broken is imperfect, and nobody’s perfect.
That said, this is what I’d love to see, and maybe its out there, somewhere, but I just haven’t seen it:
- A WCM shared vocabulary that is owned by the industry.
- A set of user scenarios based of this vocabulary for doing the WCM business as usual stuff.
- Vendors mapping their product capabilities against these user scenarios.
- Analysts rating them by how well they do it.
- Customers referencing these user scenarios in their RFPs.
- Everyone speaking in the shared WCM vocabulary
So yes, that’s the dream. I’m sure people, companies, communities are doing (some) this in isolation. But that will not make things better in the long term. Only in the short term whilst you are a part of that group. The true pain comes when you need to leave the group and this is a massive consideration for anyone looking to change their WCM. You not just changing a product. You’re learning to a new language, a new culture.
Delivering a web content management solution involves people, process and products. You need to put the right processes in place to support the people to make best use of their products. But before we can do that, I think we need to start speaking the same language, and to stop assuming that we are.