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

• Do you re-use a lot of the same content in difference manuals, or in different types of material?
• If so, do you cut and paste the content to get the content from one place to another?
• Do you translate the content into at least a couple of languages?
• Do you have diverse groups of end users that could benefit from personalized content?
• Are you in a regulated industry where audit trails matter?
• Are you susceptible to lawsuits if your content doesn’t remain accurate across all content channels?

If you’ve answered yes to two or more of these questions, you should be wondering if a component content management is right for you.

5 Top Business Benefits of Content Re-Use

1. Process Efficiency.Content developers are knowledge workers, and an efficiency goal is to create more time that can be spent on the important tasks associated with content creation. Using a CCMS to produce content supports efficient processes by reducing, and sometimes eliminating, rote tasks such as searching, cutting and pasting, checking for identical changes in multiple places, and repetitive set-ups for generating content output.
2. Scope Extension. When staff isn’t spending time on the rote tasks, they can concentrate on the activities that add value to the organization. The gain in process efficiency allows staff to re-allocate their efforts, perhaps creating material that had previously been beyond their reach, or responding to requests for materials that didn’t fit within the product schedule. Or, it could mean the difference between having the resources to enter a new market. or taking a pass.
3. Risk Management . Inaccurate content, or content that inconsistent across publishing media – documents, websites, and product packaging – can lead to lawsuits. One content developer estimated that her company successfully avoided one lawsuit per year, at approximately $1 million per lawsuit, by demonstrating content accuracy. The only way they could maintain accuracy across all their product lines, given the amount of content and time-pressured publishing schedule, was through a CCMS.
4. Customer Trust. In markets where the difference between you and competitors is a better user experience, getting good information out to your customers quickly can be a distinct advantage. With a CCMS , you can publish content sooner, be confident of its accuracy, and, when it makes business sense, easily create more variations of your material for specific audiences. When customers have better instructions, more personalized content, or targeted translations, it all adds up to increased consumer confidence in your products and your organization.
5. Increased Revenue . Whether the support takes the form of better material for sales reps, better training material, more translated material to allow your product into a new market, or real-time sharing of content with other groups such as customer support, the ability to manipulate content quickly, easily, and accurately translates into more sales.

If you’re the type of person who likes to write, think, edit, and then publish , tink about the pain of re-using content from an article created in a word processing program to a blog entry. You had to go through and check things like apostrophes, quotation marks, and dashes to make sure you didn’t end up with question marks in the middle of your carefully-crafted prose. That can be called “dumb work” – silly rote tasks that don’t add any value at all.

Now, multiply that dumb work by millions when content gets locked into a proprietary system. You may have a million-dollar content management installation, but what happens when you want to use your content elsewhere, or when you need to migrate content between your behemoth system and specialty systems, such as a component content management system?

Unless there is a vested interest by, say, a competitor in providing some sort of import wizard from a specific proprietary format into their own format, your content is now held hostage by the vendor’s system. This used to be considered good business sense, as it locked you into their system for long periods of time. In today’s world, however, it’s considered a pretty bad move on everyone’s part. The recognition that content is a valuable corporate asset whose value increases with its potential for re-use has changed the game.

Re-use is a concept that is often discussed at too low of a level within the corporate sphere. There are several kinds of re-use:

• Single-sourcing. This isn’t a particularly sexy type of re-use, but is the industrial workhorse of re-use that is the backbone of any product or service provider that produces technical content (user, installation, maintenance, and quick-start guides, training material, knowledge bases, and so on). The ROI on standards-based, re-usable content becomes critical, particularly in cases where translation are involved.
• Integration. Content among departments, divisions, or partner companies may need to be mashed together to create a cohesive whole. Saving troublesome conversion steps toward a common format is a huge time-saver, and eliminates the worries that the conversion process has eliminated or corrupted critical content that affects the quality and integrity of the end result.
• Convergence. This re-use case is bringing together content from various types of sources, such as mixing single-sourced content with user-generated content in a knoweldge base. The need to “round-trip” content relies on being able to get content in and out of systems easily and quickly, with as much automation and as little human intervention as possible.
• Syndication. Content flies (or should fly) outside of the organization, in the form of news releases, event announcements, and so on. If content doesn’t conform to the standards-based formats – microformats is the most common example – then the value of automating syndiations is lost, with a default position of cutting and pasting into multiple sites.

Having content that can “play nice” with other systems is a key component of a good content strategy. Because large-scale content projects are dependent on the technologies that manage the content, it’s critical to look at how the system treats the content, and how open the content is for re-use in strategic ways.

So when The Vancouver Sun‘s Gillian Shaw pointed her Twitter followers to the first blog post of the Obama administration, I went there to get an idea of the tone of what I heard on CBC referred to as the New “New Deal”.

About half-way down, I noticed the following sentence: “The President’s executive orders and proclamations will be published for everyone to review, and that’s just the beginning of our efforts to provide a window for all Americans into the business of the government.” Fabulous, of course. Then I started to wonder about how this would happen, the speed of which this information would get published, whether it would be single-sourced from the original source, which other publishing channels the material would be pushed to, and what flavour of XML would be used to accomplish all of this. A few years ago, the Irish government got their staff working in XML, without them even knowing it, in order to get them publishing content faster, more efficiently, and without the potential of degraded accuracy inherent with “cut ‘n paste” methods of multi-channel publishing.

With the new administration appointing its first CTO, no doubt there will be great changes coming about. No doubt content strategies are way down on the list – infrastructure and data security is bound to be way higher priorities – but at some point, this will need to be addressed. I can only hope that whoever gets that gig will be allowed to do the conference circuit to speak about how they made it happen – I mean, wouldn’t you be awfully curious, too?