“Our IT department gave us VSS and we can’t figure out how to get components out of that. How do you do that?”

“We’re tearing our hair out with Sharepoint and versioning; what is the workaround?”

“Our website uses Documentum and it won’t do what we want. What do we do?”

“We have Interwoven and the interface is awful, so our staff won’t use it. What should we replace it with?”

Each set of circumstances was unique, yet eerily alike.  Each instance involved the acquisition of a software product which was then implemented for an operational unit, without regard to whether the software was suited to the task. The mismatch, in some cases, was painfully obvious; in other cases, the mismatch was more subtle. In many cases, certainly all the instances above, the software is popular, thriving software that has been implemented without a proper strategy. The results: generally some sort of fail.

Bad strategy or no strategy?

During the past decade, acceptance of content management has drastically increased. The idea that managing any significant volume of content requires some technology assistance has been demonstrated a multitude of times, and the adoption of a CMS (content management systems)  is no longer a novelty. Yet the instances of the tail wagging the dog – buying the software before determining the operational needs – continue to be far too familiar to ignore.

When I would encounter an audience member at a later event, I’d ask if they’d ever gotten the problem sorted out. Overwhelmingly, they would sheepishly admit that they had not. They continued to produce and publish content in ways that they acknowledged were highly inefficient and prone to operational risks <link> because they couldn’t convince their organizations of the need to make the changes that, to them, were obviously needed. So what went wrong?

Go cheap or go home. This “strategy” is when the technology group either already has some software – collaboration software, source code control software, or a Web CMS – that they insist be put to use because “we already own the software” or “the software is free.” Not only does this dooms a project to failure, but anecdotal reports show that the operational team is then blamed for the failure. The technology group refuses to take responsibility for having foisted upon them an inappropriate tool. In this case, a stalemate ensues, and everyone goes back to their previous kludgy way of work, with no movement forward, and the technologists smug in their political win.

Don’t get it, don’t care; just do it. This “strategy” is in play when a group has heavily invested in a software application, and is reluctant to investment more time or money to make it work for a different operational purpose. There is equal resistance to bringing in additional software that complements the original uber-application, and no impetus to understand why it is needed. There may have been a strategy developed for the initial implementation, but there is no acknowledgement that different operational needs will require further customization of the software. The idea is that the software should be one-size-fits-all, and if the customization has worked from one department, it should work for all departments. The department whose operational needs aren’t being met is sure to find inventive work-arounds, sometimes taking pains not to let on what is going on for fear of sanctions from the powers that be. Generally, the situation comes to light when a serious breach of protocol comes to light that can be traced back to a work-around that failed.

Connecting strategy to technology

The idea that technology can be implemented without strategy is naïve, at best. The idea that technology or strategy can be implemented without a deep understanding of the content lifecycle is a wanton mismanagement of corporate assets.

Understand your content. The entire CMS implementation is to support, with technology, the production, processing, and publishing of content. It is imperative to understand what the content needs are throughout the entire content lifecycle. Without this understanding, a technology implementation is sure to go wrong at some point because there will be a mismatch between the content requirements and the software assigned to support it.

Know your standards. For any technology to be effective, there needs to be an understanding of how the content can be leveraged. This generally involves connecting systems, whether that is as simple as providing an RSS feed or using microformats, to more robust standards such as implementing DITA <link> to make content system-agnostic or integrating content from one system into another through the magic of XSL transformations.

Understand pertinent technologies. The decision-makers who, with much eye-rolling, confess with some pride that they don’t even know how to use styles in their word processing are who allow bad software implementations to thrive. Get with the program or get someone who can, because the lack of understanding about how to leverage content through technology, more often than not, shortchanges the project or leads to disastrous results. The complexity of systems has grown exponentially over the past decade; it is imperative to understand, at least at a high level, what the various technologies can do and how that can benefit – or harm – your content and, ultimately, your brand.

The concepts I’ve articulated here are not entirely new, nor are they particularly rocket science. Consultants, software vendors, and their savvy clients have produced many case studies demonstrating successful implementations and the derived organizational value. Invariably, their successes all share a common denominator: a strong strategy.