As the world of technology makes literally breathtaking strides, the world of automation finds itself increasingly focused on the technology. Indeed, in many areas of popular culture, the technology becomes an end in itself, conferring the patina of success on projects that are techno-heavy, never mind that they may not meet their objectives particularly well. This despite the pronoucements of virtually every management authority since the 60’s that technology and automation are different and the latter is the most important to success of the organization.
Nowhere is the tendency to focus on technology itself, to the detriment of meeting functional goals, more pronounced than in the general area referred to as “conent management” or CM, and in no part of CM has this tendency more clouded the picture than in the relationship of its semantic components; “Content” and “Management.” In today’s CM world, the focus on Management means that software and technology takes center stage with an implicit assumption that if one just adheres to the proper technological dictums and acquires the most powerful CM software, the effort will be successful. When efforts so constructed fail to meet their objectives, the further implicit assumption is that the technology… or the technology selection… or the technology governance… or the technology infrastructure has failed. In many cases while some of these may be true, they are not the reason for the failure.
Often, the cause of failure (or marginal performance) is the other side of the CM terminology; the content being created, managed and delivered. Look closely at many automation environments and you will see a high-performance management and delivery environment being fed by virtually uncontrolled content raw material. If “you are what you eat”, so too is a content management and information delivery environment. In fact, failure at the delivery end is more often than not a failure to develop usable content instead of a failure of management and delivery technology. So why, with all the tools at our command, do we not address the content creation portions of our information life cycles?
I don’t claim to know all the answers, but have formed some impressions over the years:
FIRST: Content creation and its unwashed masses of authors, providers and editors has traditionally been viewed as outside the confines of automation planning and development; indeed often as a detriment to automation rather than an integral part of the overall process. With that mentality, the system developers often stay completely away from content creation.
SECOND: The world of software products and vendors, especially those in the management and delivery space, would rather spend more money on their systems in an attempt to make them resistant to the vagaries of uncontrolled content, of course at higher fees for their products. The world of content creation, if it can be called that, is still controlled by the folks in Renton, to their own corporate and marketing ends.
THIRD: In most automation projects involving content, the primary resource is the IT group that, while highly capable in many cases, does not understand the world of content over which it does not itself have control. The result is usually a focus on the IT itself while the content creation groups in the organization find themselves outside with their noses pressed against the glass… until they are called in to be told what will be expected of them. The resulting fight often virtually dooms the project as it had originally need conceived.
So what should we do differently?
While every project is unique, here are some thoughts that might help:
FIRST: Understand that technology cannot fully make up for the absence of content designed and structured to meet the functional needs on the table. Indeed, if it came to a choice between good content and high-performance management resources, content can be delivered with a surprisingly low level of technology while no amount of technology can make up for AWOL content.
SECOND: Accept the premise that well-designed content, fully capable of supporting the functional objectives of the project, should be the first order of business in any major project. With this, acknowledge that the content creators, while they may be less controlled and sometimes not easy to work with, are a critical component in the success of any project based on their output. In many content creation environments, negotiation between what would work best and what can be provided will result in a set of compromises that gets the best possible content within the constraints in place. That done, technology can be applied to optimize the life cycle flow of the content. Note that in this construction, the technology is a secondary factor, supporting but not defining the strategic direction of the project.
THIRD: Despite what you may hear from the software industry and its sales force, understand that in the term “content management”, content is the most important component and just buying more technology will not make up for its lack. From this understanding, you will be able to create a balance that accords both content and technology their rightfully important places in the overall effort.