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

Of course, a presentation is just that. It’s generally an hour-long session, in which a speaker has to pick and choose their facts and explanations to fit within the time frame. Sometimes large issues get glossed over in order to fit in all the great material the speaker wants to present.

CMS-savvy people – internal staff to project stakeholders to consultants and everyone in between – know that there can be inadvertent, besides deliberate, misrepresentations of what a system can do. It’s often a mismatch between a system’s features and organizational needs, and often a mismatch between cost models and budget expectations. So how do you ensure that you’re not  left holding the bag when the software vendor has left the building?

Process.

When you can explain to a vendor exactly what you need from a system – the scenarios and use cases – then you can get the vendor to demonstrate how their system will fulfill that need, how much it will cost for add-ons or customizations, how long it will take to accommodate all of this, and what impact all these will have on the maintenance after an upgrade or two. Without doing all of your homework first, you fall prey to the never-ending escalation of time, cost, and frustration as you discover the shortcomings of a misfit content management system.

Be sure that visitors subject your website to the same first-impression scrutiny that they exercise in real life, only faster. It takes 0.1 second to decide whether your site is attractive, 10 seconds to decide that your site is “taking too long” to respond, and 1 minute to be fed up with a task or a video.

Explaining the importance of getting this right is critical to a development team has its problems, as people “yes but” when it comes to their territory. The marketing department may “yes but” over the whiz-bang elements that slow down the site. Interaction designers may “yes but” when asked to redo problematic area. Developers may “yes but” when asked to do over some code. The writers may “yes but” when you insist that a content strategy must precede the content development stage.

Actually, it’s not even the “yes but” that is the problem; that may just development stakeholders working through how to fix the situation. The problem is when the “yes but” is accompanied by a workaround, a justification, or a reason that serves to solve an internal problem rather than a client-facing problem. It can throw the development timeline off, affect the quality of the final product, and compromise the maintainability of the site. Because all of these factors have an effect on the Total Cost of Ownership, sometimes in serious ways, the “yes but” can be the “gotcha” that takes a project down; definitely not something I’d want to underestimate.

Janus is in the enviable position of living and working “across the pond” where talking about dysfunctions isn’t sanctioned by threats of lawsuits and exposed to the “shoot the messenger” syndrome. On this side of the pond, a CM consultant is expected to turn away, tight-lipped, and not expose irregularities to public scrutiny. When one sees, for example, a CMS contract awarded to a questionable vendor – the vendor rep who leaves the group RFP debrief, where requirements were being discussed, and courts the IT Director instead – any questioning of this manipulation of the system will work against the consultant. It’s as if ethics takes a back seat to the expediency that requires membership to the inside track.

Janus Boye is organizer of the J Boye conference series. At the Philadelphia, online professionals can share knowledge, hear great keynote speakers, and further their professional development. If I weren’t already committed to going to the STC Summit, I would definitely be there.

However well that has served you in the past, using this structure might be doing your group a disservice when you have a lot of content to manage. This holds true when you move to a content management system, where you have lots of content “chunks” or “objects” that get combined and recombined as an aggregate of topics for the output in a “book” format.

How context affects findability
There are lots of ways to think about your content, and to be sure that you’ll be able to store the content in an appropriate place, find it when you need it, and manage its lifecycle, you need to understand the requirements from a business, content, and technology point of view. When content gets stored in a traditional file structure, you run the risk that content gets forgotten because of its creation context.

Using the example above, let’s imagine a typical department scenario. Imagine your company has a product line of, say, office chairs. The traditional file structure would be:
Office Chairs
> Swivel Magic Chair > Assembly Instructions
> Swivel Magic Task Chair > Assembly Instructions
> Swivel Chair with Lumbar Support > Assembly Instructions
> Swivel Magic Executive Chair > Assembly Instructions

Let’s assume that a new writer is assigned the task of creating assembly instructions for the new type of chair (executive chair with armrests). The writer must look through all the versions of all the chair types to see if any assembly instructions for the armrests exist. If there are many sets of assembly instructions over a number of years, finding existing instructions could be hit or miss.

In a content management system, there is no need to store the content in such a linear way. The content chunks get stored in a way that can be mixed-and-matched, and changed with conditional text processing that gets applied at some point during the system. In the case of a product line such as chairs, where one could assume that lots of the content is common, a more efficient way of structuring the taxonomy could be to group the common elements in a way that requires writers to sort through a known number of content types. An alternative structure could be:

Office Chairs
> Swivel bases
> Swivel bases > Castor type A
> Swivel bases > Castor type B

> Chair frames
> Chair frames > Steel
> Chair frames > Wood

> Armrests

> Upholstery
> Upholstery > Leather
> Upholstery > Wool
> Upholstery > Microfiber

Under this model, any writer beginning to write assembly instructions would look under each Level 1 section, and would choose a topic from each appropriate area. Because any writer can see all the available topics, there is no guesswork about whether content exists elsewhere, and where. In a content management system, there are likely search options to locate content that isn’t categorized appropriately, but for a successful search, the writer has to determine what the search terms will be. If a previous writer used a slightly different term, or a now-defunct term that was in vogue during a certain marketing era within the company, the search may be unsuccessful, and a writer could spend valuable time rewriting content that already exists. On a one-off basis, this may not seem like a big deal, but in an environment with lots of content or many writers, the content repository can get “littered” pretty quickly with duplicate content. And as the collective memory fades, it will become unclear which version is the right version, the official version, or the signed-off version.

The example used here is obviously a simple one, and certainly will not apply to all situations. In cases where complex content relationships exist, you may need a formal taxonomy that allows terms to be referenced in specific ways, that allows content to appear to be filed under multiple categories, or that drives navigation. These strategies are best left to a taxonomist whose training lets them easily see content relationships that the untrained eye struggles to detect. What should not be hard to see, however, is that how you structure your content, right from the beginning, will affect your content “discoverability” for a long time forward, and is a decision that should be based on the business and content requirements within your organization.

The article was published in the August issue of TechCom Manager, where you can read about the project and the lessons learned.

Trying to explain this dynamic to potential clients sometimes falls on deaf ears. Their IT group or management often insists that any software not recommended by whichever analyst firm they subscribe to isn’t worth looking at. So it was refreshing to reach John Lovett’s article about the inner working of what he calls the “pay for praise” business model of industry analysts. In fact, the only completely vendor-neutral group of industry analysts in the content management sector is CMS Watch. There are better ways to choose a CMS than by downloading the responsibility to an outside agency whose loyalties are to its clients – the vendors.