Robertson’s rule of CMS usage
Categorised under: Content management
We’re just wrapping up a review of the content management system within an Australian government agency. Their story is typical:
Lifecycle of a CMS
Some years back, a CMS was purchased to manage the websites and intranet of this agency. This was a powerful and complex product, produced by a small vendor. The product was extensively tailored to match the organisation’s needs. Some years later, the vendor closed up shop, leaving a significant question mark over the future of the CMS (therefore triggering the review).
A key part of our brief was to look at how the CMS was being used, to assess the benefits being gained, and to compare the solution to current marketplace offerings. What we found was interesting, if not surprising.
The CMS in place offers a uniquely powerful way of capturing and managing content. It supports rich content reuse, and highly structured content. There is also an extensive development layer, facilitating further extensions in many different directions. In short, a powerful (if unusual) solution.
Yet when we looked at the websites and intranet, they were very typical. Pages upon pages of content, statically published. Very little content reuse, and only a handful of simple dynamic features and areas of integration with back-end systems. Authoring was also very straightforward, with a typical mix of centralised and decentralised publishing.
The gap between back-end complexity and front-end simplicity quickly became apparent. This has increased the amount of effort needed to create new sites, and to manage the CMS on an ongoing basis. In summary, a greater than average amount of work to publish very average sites.
So not for the first time, we’ve recommended simplifying the back-end management of the sites, and moving towards an out-of-the-box CMS solution. This should be highly usable for authors and site administrators, and require little or no custom development. In the process, many of the unused functionality in the current solution should be stripped out, moving the organisation back to a more typical product.
The bigger picture
Looking back at previous work, we’ve seen a pattern emerge, which can be summarised as:
Robertson’s rule of CMS usage: Over time, CMS usage will head towards the middle of the road.
Or to put it another way:
Typical business needs will be met in typical ways, regardless of the CMS technology available.
Organisations often buy powerful CMS solutions, with an eye towards meeting future (unknown) needs. The assumption is that the CMS will be used in increasingly rich ways over time, fully making use of all the features the product has to offer. There are also ambitions to use the very powerful functionality evangelised by vendors and consultants alike.
Instead, we see that organisations often settle into fairly typical patterns, regardless of the technology being used. This is the 80/20 rule in practice: a core set of common functionality meets the majority of business needs.
As a result
This means that organisations can often benefit by purchasing comparatively simple CMS solutions that “gets the job done”, allowing the focus to be placed on the sites themselves. The replacement of an existing CMS also provides an ideal opportunity to consolidate and simplify, based on the real-world experiences to that point.
This also means that CMS vendors benefit from continuing to build an understanding of how their products are used in typical environments, and tailoring their out-of-the-box experience to match this. This is a journey that the mid-market vendors have been on for some time, but the bigger products have been slow to recognise.
So, what are your thoughts or experiences?
James Robertson is the Managing Director of
4 Comments:
Interesting James, but I can’t help but think of the parallel between your theory and the standard practice in financial theory of “regression to the mean”, ie that everything will return to equilibrium, eventually.
Nowadays people are starting to think that, in financial markets at least, activity is more driven by continual cycles of fear and greed, leading to wild swings in prices where assets are alternatively vastly overpriced (in bubble times) and then vastly underpriced (in the times that we’re heading for right now).
An interesting question to ponder for content management teams, and IT projects in general, perhaps: do we tend to overengineer in the good times and then underengineer in the bad times?
Maybe that’s just human nature?
@Brendan, that’s a good perspective on things!
I think that CMS projects tend to be over-engineered most of the time, mostly because they tend to be driven by technology considerations. There is also a huge lack of practical, pragmatic information on content management systems on the web, making it hard for organisations to identify what’s real and what’s hype. (In the absence of vendor-neutral commentary, other than from folks such as CMS Watch, vendor marketing rules.)
So I’m expecting to be recommending simplification in client projects for some time, even in a recession
I think what happens is, you have somewhat of a technical skill-set disconnect between the ambitious web/IT staff (who sees the potential and are usually the driving force of change) and the more practical, non-technical staff (who usually don’t want anything to change because it’s not, in essence, a priority in their positions).
The first group wants all the CMS bells and whistles, but it’s the second group who are usually stuck having to actually use the tools in order to maintain the content. So what’s the result? Absolutely brilliant web launches, only to turn into ho-hum sites after about a month.
This is a fantastic observation!
I couldn’t agree with you more! We’ve seen it again and again with technology, where organizations go to great effort and expense to adapt a standard technology to what they imagine are their “absolutely essential and indispensable” requirements. Over time they learn that it’s far more efficient, effective, and easier-on-the-budget to see if they can’t maybe — maybe — bend the inflexible rules a little bit and adapt their practices towards what the technology offers.