Why I say that is because of a concept borrowed from the financial industry called asset amplification. In the context of financial markets, asset amplification describes how changes of wealth in financial markets causes amplification because of follow-on consequences. (Thanks to the Journal of Financial Economics article by Wei Xiong explaining how this works.) Similarly, the power of copy can be amplified if it is placed into a robust technology framework. Once copy is placed inside of a framework, it becomes the content of that framework. Like coffee is the “content” of a cup, copy is the content within a technology framework. And like a super-hero with the appropriate gear, copy, with the appropriate framework, gets super-powers, too.

The super-power of content is the potential for follow-on consequences of copy because of the underlying technopower is what turns copy into content. Thinking back a few years, communications coordinators who organized events would type out the event details: event name, start and time, place, cost, and so on, and then spend hours copying and pasting the event into sites that would allow them to paste it into a provided text box or, even more time-consuming, complete a set of form fields that the coordinators had to fill out individually. Today, we use content feeds which allow events to be amplified with no manual intervention. This is done through the technopower of the underlying technology framework.

As we get away from brochureware to robust interactivity, the need for rich semantic content grows. Again, copy, multiplied by technopower, makes content which can be processed by other systems. The event example was a simple one, but there are increasing levels of complexity, from “simple” publishing to the kind of interactivity and outputs that allow for successive complex transformations of content. We are all familiar with how content gets syndicated, but what may be a surprise is how much content is manipulated and transformed within a system. Each transformation provides the potential for additional amplification, and eventually provides a much richer user experience for the content consumer.

In the end, content may be nothing without copy; however, in a post-paper world, copy is nothing without content.

Previous post: Turning Copy into Content

Getting a CMS without decent documentation is like buying a luxury car that has no windshield wipers. Imagine this scenario – you’re taking possession of your new car. There is a downpour for the first 100 miles. The car salesman tells you that they didn’t get around to putting on windshield wipers because, well, the company doesn’t really think it’s that important. Well, they might have some old, used ones lying around. They don’t really fit, and will leave big streaks that prevent you from seeing properly, but if you insist, they can get some installed. Because it’s only raining for the next 100 miles or so, and then you should be OK. If a sales person tried to convince me of that, I’d be outraged. The reputation of the company would come into question and I’d start questioning the other features. In fact, I’d do everything I could to cancel the contract before leaving the car lot.

Yet many, if not most, of the mid- to mega-sized content management systems come with incomplete, incorrect, untranslated, and/or outdated documentation. What’s the danger of taking charge of a complex piece of software that’s under-documented?

Well, let’s start with the integrator needing to do a bunch of extra work. Who absorbs that cost? Is it the integrator, whose developers end up redoing work because they aren’t given all the information they need to do it once? Or do they pass that cost down the line to the customer, who may never know that they’ve just absorbed the cost of bad practice on the part of the vendor?

Next, there are the project delays. The client waits (and often waits and waits and waits) while the integrator goes back to the CMS vendor to figure out why some feature is crashing, or the system is crashing, or something or other went wrong during setup. The customer, who inevitably has an aggressive launch date, now starts sweating bullets as the clock keeps ticking. And the contractors hired to do various bits with the post-installed CMS  – the content folks who get the content into the new CMS, the testers who are supposed to start running their gamut of tests, the visual designers who are supposed to tweak the CSS and templates, and so on – they get to sit around and wait until the CMS vendor or integrator figures out what went wrong so they can start up their work again. And who pays the bill for flying out a developer from the CMS vendor to troubleshoot what turns out to be documentation that hasn’t been updated since two operating systems ago?

And then there is the lack of training material. At each level, this is so woefully lacking, it’s a wonder that anyone knows how to operate the system properly. By the way, a few Powerpoint slides showing system configurations and other geeky details is not training. It’s a lazy way of checking off the box for training deliverables without doing the work – and not caring that customers won’t get what they’ve paid for.

When technical communicators talk about the ROI of documentation, these aspects of project pain seldom get factored in, because no one talks about them. CMS vendors certainly don’t want you to know that their lack of investment in good documentation will cause you thousands, or tens of thousands, of dollars. Integrators won’t talk about the make-work aspects of having to compensate for the CMS vendors’ lack of adequate documentation. And I haven’t met a customer yet that wants to admit they’ve been taken for a ride because it never occurred to them to verify a CMS vendor’s documentation  is up to snuff.

A word to vendors: Documentation is a product feature! If it’s not an integral part of your feature development plan, you’re not selling a complete product. You should be bounced out of the RFP process in the first round.

A word to integrators: You have a responsibility to get your hands on whatever documentation the CMS vendor has, as soon as possible, and tell your client where it has gaps. That gives the client the opportunity to go back to the software vendor and make them put the wipers on the car before driving it off the lot into the rain.

A word to customers: Here are the things you never want to hear from a CMS vendor:

• We don’t have documentation factored into our project plan.
• Our software is so straightforward, it doesn’t really need documentation.
• We can show you our documentation next month, if you insist.
• We have some documentation, but it’s for the last release.
• That part of the documentation hasn’t been translated yet.
• Oh, I can go write you something if you want.

The era of “real men don’t need documentation” has long sailed into the sunset. Software is too valuable to leave to cowboy coders, and it’s too complicated to send out into the market place without decent instructions. I’m not afraid to demand documentation for software,  just like I’m not afraid to demand all the safety features on my car.  It’s time to get over the idea that documentation is somehow a luxury add-on and consider good documentation a necessity.

A recent inquiry on the content strategy group asked about efficient ways of surfacing content in multiple ways. Yet avoiding content duplication isn’t as easy as it may sound. Managing content is more complex than managing data. Data moves from one point to another with little problem. The number “12″ is the number “12″ no matter where it ends up. But when the content equivalent – a dozen, December, above-average family size – context becomes critical.

This is where having a technical communication background comes in handy. Surfacing content in multiple places is a cornerstone of creating technical documentation, online help, training, and user support material, which can often come from a single content repository, and published out with variations. The “one source of truth” has long been articulated as “single-sourcing” with its corollary, “multi-channel publishing.”

The model for creating content and pushing it out to the surface is a different process, and uses different tools. It also moves responsibility for content further up the production process. The decision on how this is put into effect is a key aspect of a content strategy, and doesn’t get addressed often because of the deep divide between types of content authors.

One source of truth in a Web CMS (WCMS)

The WCMS  generally takes in content that is edited in form fields. A simple example would be changing the account settings of Facebook, and having those changes show on your home page. How this happens is programmed by the developers, and any changes to how the content is surfaced either by the writer (de)selecting a check box, or by the developer customizing the code of the WCMS. Thus, the WCMS is the gatekeeper for the content flow.

A practical example in the WCMS world

I recently worked on a project where a number of hotel resorts were described in various ways on the website. On the home page, there would be a one-line description accompanying a photo. On another page, there would be a short teaser paragraph. On yet another page, the hotel contact information would be shown.

In the background, all of the content was in a single database, per hotel. The database cells included: hotel name, city, state, country, reservations phone number, front desk phone number, one-line teaser, short teaser, property description, and at least a dozen more content blurbs. These were provided in an Excel spreadsheet to the technical team, who then programmed how the content would be surfaced, and ensure that the right images match the content as it is displayed.

Single sourcing in a Component CMS (CCMS)

In a CCMS situation, the responsibility for surfacing content is moved upstream, to the writer. The writer uses an XML authoring tool (as the industry matures, tools are starting to leverage common tools like Word to do XML publishing – it’s still in its infancy, though) to create content and determine the variations. The authoring tool creates a individual content files, which then get managed in the CCMS. In other words, the CCMS is not the gatekeeper; it becomes simply the “traffic cop” that supports the author’s work.

Once the writer has created the content and set up the dependencies for surfacing content, the CCMS does an automated generation of the content through some sort of publishing pipeline. This reads all of the XML metadata and determines what content is shown where. At this point, the content is generally pushed out to some area in the WCMS reserved for the content, and then the WCMS picks up its gatekeeping duties.

A practical example in the CCMS world

To publish a travel advisory that needs to be shown to three audiences, you would create the entire long-form advisory and tag each of the sections with an audience, as shown:

<public>Don’t go to country X, effective immediately.

<doctors> <industry_stakeholders>There is a suspected outbreak of a mystery disease. If called by the media, assure them that they will be informed as soon as developments are known.</industry_stakeholders> If someone comes into your office with the known symptoms, quarantine them and get them to a hospital as soon as possible.</doctors>

Stay tuned for details.</public>

The publishing pipeline would send out three separate messages to the appropriate output channel, presumably different places on the website, or a combination of the website and other forms of communication.

• The public would see the preamble plus the concluding statement (in blue).
• Industry stakeholders would see the public message plus the statement intended only for them (in blue + purple).
• Doctors would see the entire message.

Other critical differences in surfacing content

The first difference is in what constitutes the “single source of truth”:

• In a Web CMS, content changes are made to the database, and the content is changed everywhere it’s programmed to do so. The database is the single source of truth.
• In a CCMS, what you have is, in effect, two “single sources of truth” – one is the pre-published source; the other is the published version. The nature of publishing is that these get out of sync after version 1. Think of publishing a multi-hundred page HTML manual. Version 1 uses all new content. Then, there are updates to one section, say pages 20-30. These pages now have Version 1 content and Version 2 content, while the published content is all in the Version 2 manual.

So the second difference is how content is versioned:

• The authors will be concerned with the versions of each content file; after a while, a body of published content can be made up of a range of versions that co-exist in the same repository and get mixed-and-matched by the author to be published.
• The published content is another single source of truth. It is the aggregated “publication” that is for consumption. The consumers of this content have no idea that any given page may be made up of multiple content chunks aggregated together for a seamless reading experience.

Another difference the gatekeeping functions:

• In a WCMS, the code written by the developer provides virtually all gatekeeping functionality.
• In the CCMS, the writer is the primary gatekeeper, but there is another gatekeeping function – the publishing pipeline code. The content is generally publishing using XSLTs (an automated transformation of XML content using XML stylesheet language scripts). The code automates the output process, and changes to the output means tweaking the scripts.

The WCMS world vastly overwhelms the CCMS world in number of systems sold and implemented, though amount the content published by CCMS systems on a given site often considerably dwarfs that output by the WCMS.  The next few years will be interesting, as content management systems try to capture market share by enabling “the other type” of authoring experience for organizations that need to adopt more robust methods of creating and surfacing content in more flexible ways.

The web is simply one channel in a multi-channel publishing environment.

You can’t really talk about being a web content strategist, unless that means you handle only web content that is not also destined for mobile phones, PDAs and other small-screen devices, or even (gasp!) print. And if you don’t, who takes care of the content models, delivery design, topics maps, localization, customization, standards, publishing pipelines, transformation guidelines, metadata, and all that other stuff that needs to be considered?

When we develop content strategies, we are asked to analyze content and make recommendations about the various aspects of how content will be handled during the content lifecycle. One of those decisions points may be how the content should be, is likely to be, and will be consumed by its readers.  It could be output to the Web, but it’s more likely to get output to the Web as simply one of the channels in a multichannel publishing environment.

I contend that no one can do it all, but that the way to slice the content pie isn’t by output channel. Meanwhile, did this ring a bell for anyone else? Discuss…

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

Perhaps the lack of attention to content lifecycle is a reflection of the lack of attention given to the topic on the Web. In fact, a Wikipedia search on the topic of the content lifecycle sent me to the topic of Content Management, where a brief mention of content lifecycle management involves “content distributions [sic] and digital rights” – if only it were that easy. The German version of Wikipedia has an article on the content lifecycle for Web content, which seems incredibly simple (Create > Publish > Archive? Really?) and is also tied to a content management system.

But, I’m telling you, this is wrong, wrong, wrong. At the risk of sounding like David taking on Goliath, I want to spend a couple of articles talking about the content lifecycle, and clearing up some common misconceptions. I’ll discuss  content without the attachment to a CMS, proprietary software, tools, or methodologies. It’s all about the content, front and center. Defining a content lifecycle What is a content lifecycle?

Just as in the information architecture world, there’s “big IA” and “little IA”, in the content world, there is “big content management” and “little content management”. The “little content management” is about getting content to work within a content management system; “big content management” is about having a content strategy to create a repeatable system that governs the management of the content, throughout the entire lifecycle.

The content lifecycle covers four general areas: the strategic analysis, the content collection, management of the content, and publication, which includes post-publication maintenance and a loop back to analysis for the next cycle. This lifecycle is present whether the content is controlled within a content management system or not, whether it gets translated or not, whether it gets deleted  at the end of its life or revised and re-used.

The critical aspect of the lifecycle is that it begins with the analysis quadrant. The saying, “if you don’t know where you’re going, any road will take you there,” certainly applies to the lifecycle  of content that begins without a strategy. You can change how it produced, how it’s managed, which tools you use to control it, translate it or not, cut aspects out of it or not – if you have no strategy, you have no real rationale for the content you produce.

The other three quadrants are the tactical aspects of the content lifecycle.  They may not have the same allure as the strategic side (at least, not for me), but they are important, nonetheless. It’s where the rubber hits the road. Without the strategy, you may end up in an aimless wander, but without the tactical side, all you have is a good idea.

Next week: Dispelling the Top 10 Myths about the Content Lifecycle

• October, New Orleans, LA: Lavacon
  A conference for techcomm managers and project managers, this year’s theme is professional and career development. If you sense a career change in your near future, or are out of a job and want to move to a field with a future, I’m presenting two sessions. One is on content strategy; the other is on managing your personal brand online.
• October, webinar: Leveraging Content Assets on a Tight Budget
  Part of Aptara Corporation’s Thought Leader webinar series, you can learn how to align technology and processes with business goals, leverage existing content assets for better user experience, and creating an optimized content supply chain
• November, Banff, AB, Canada: CANUX
  I’ll be presenting a case study at this 2-day Canadian User Experience workshop. If you attend, you’ll also get the infamous Kristina Halvorson, whose keynote my presentation follows
• December, Boston, MA: Content Management Professionals Association Summit
  The theme of the trade association summit this year is open source standards. My presentation on “open source content” is a little different aspect of content strategy.
• December, Boston, MA:  Gilbane Boston
  I’ll be moderating a panel discussion on Content Modeling and Information Architectures for Content Management, which is a critical aspect of content strategy.

If you can’t complete your professional development in the content strategy area during 2009, there will be multiple opportunities during 2010. Stay tuned!

Explaining CCM (component content management) to clients is sometimes difficult. The concept of combining content at the component level to create topics, which then get combined to create publications – or not; sometimes, topics just remain topics – is complex to understand to people who aren’t typically involved in the production or management of content.

Ironically, one group that has a hard time with the concepts of CCM are the IS/IT groups. For a while, this flummoxed me, as I thought that an understanding of the technology side would be an advantage to understanding it. Then it dawned on me that knowing the general principles of content management could actually become a barrier. Content management has become synonymous with WCM (Web Content Management), with CCM considered an obscure niche within the broader field, and WCM does not handle content at a sufficiently granular level. The final two words, “content management” are the same, but it’s the first word that makes the functional difference. It’s a little like thinking a truck is a truck, whether the prefix is “moving” or “dump”.

The difference is a little like that. For the average WCM system, content is input directly into the content management system, and managed at whatever level the content is input – generally, at the page level. A change to made to a page, and an edit udpates the entire page.

For the average CCM system, the content is created in smaller-than-page chunks, and assembled, much like a content mashup, to create a larger-sized page for output. A change is made to a component, which can be a single word, phrase, paragraph, or larger, which is then compiled, much like a software “build”, which generates a presentation version of the specified sources. The aggregated content can be pushed out to a Web page, a PDF, or a print destination.

When we think of mashups, we think of the Wikipedia definition of a mashup, which is combining data from two or more sources to create a richer information set. A common mash-up is an address with a map, that displays that includes both components as a single, integrated screen, with more meaning. A content mashup is similar – for example, when an ecommerce retailer pulls product descriptions from one data source and the prices from a financial system to mash together and display according to the requested content.

The technology that allows content to be mashed up before making it to the end display is an XML editor. The editor allows authors to determine how the components will be mashed together, whether that be through a manual mechanism such as a content map, or automated through an information retrieval system such as a taxonomy or thesaurus.

Whether understanding CCM as a mashup application is helpful for purposes of explaining to the technical parties remains to be seen. I do suspect that the analogy will strike a chord with a certain client segment, though, and that’s about all I can ask.

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.