It was interesting to me to see how Lean has made it into this area because at first glance, Lean is all about production line efficiencies, and here it’s being applied to a discipline that is far from production line, and couldn’t be effective without a certain amount of creativity. And creativity is hard to streamline in terms of “reducing waste.”

The idea of applying Lean principles to a service environment isn’t new, however. In 2004, Lean was just starting to be adapted to areas beyond manufacturing. I worked on a project where we applied Lean principles to the production of content, where the savings were great and the ROI was stunning (though as Scott Abel always warns: your mileage may vary).

My client and I turned our success story into a presentation. As the question of ROI comes up continuously, I thought I’d post the presentation to show how a rigorous examination of even a small area of content production can yield significant results.

How Far to Lean (goes to Slideshare.net) or view below:

Let’s start with the lowly Word document. How many of you use stylesheets to write your copy? That is, use it properly. Be honest;  nobody is watching you. What I’m talking about is about applying the right tags to the appropriate headings and subheadings, applying appropriate tags for the various list types,  and so on. Why is this important? Once you save this document as a PDF, this is what allows your generated Table of Contents – you did know that you can auto-generate all of your tables of authority and references, right? – to be hot-linked to the appropriate heading. It’s part of what makes your document meet accessiblility standards. Oh, and those same qualities make documents mobile-friendly, as well.  And do you add the metadata to the properties screen, and keywords that would help with internal search? If you do, you’re in the miniscule minority that does, because you understand how using the technical side of Word can be of benefit down the road.

Moving ahead to the example we used in the persuasive genre of copy. News releases are a type of content that organizations want to share. For more years than necessary, communications coordinators have cut-and-pasted news releases into various partner and distribution service sites. However, if the copy is created in a semantically structured format – that is,  with systemic attention to detail so that  other systems can understand and programmatically process the content – then it’s possible to leverage the content exponentially to get better value from it. For this example, I’m not debating whether the news release genre is dead, or what should go into a news release. This is about how to get the best use whatever content you do create. You do this with technology, which will be discussed in the next post.

Previous post: Copy is not content

Next post: Defining content in the age of technology

What impressed me about this particular method of content planning was not just the identification of personas, which are essential to any content strategy, but the identification of personas within the sales cycle. In a B2B context, this is important because the person who wants a product may not be the person who approves the product or the person who does the purchasing. And at each stage of the buy, there can be different tensions that need to be balanced to keep the buyers tracking on your product and not a competitor’s.

Content Mapping Process and Templates

The limitations of this particular mapping process is that, in my opinion, it ends with the buy. It’s only one conceptual step out to extend the process to the entire customer relationship cycle. We know, or should know by now, that what was traditionally deemed “post-sales” content is often considered as part of the adoption process. So adding post-sales material, such as user assistance content, social content, and user-generated content, to form an integrated process that brings the process more toward a customer conversation.

However, I’m providing the net best thing – a book review of Erin Kissane’s The Elements of Content Strategy. Kissane has brought together content strategy principles, methodologies, and deliverables in context for aspiring practitioners. This is an invaluable resource for anyone wanting to transition to the field of content strategy.

Don’t know if you’re ready to transition to working as a content strategist? Read this book. Someone who is comfortable translating what Kissane has brought together, and interpret it into a work methodology should be comfortable enough to try their hand at it. If you have the “aha, that makes sense” moment, this will give you the framework to develop a strategy in your own workplace. If you read this and wonder where you fit your writing and editing tasks in, then you’re probably not there yet.

The book isn’t just for the next generation of content strategists. I can see this being useful when you’re sitting in that late-night stupor after working several late nights in a row, and have a complete blank on what to do next. A quick flip-through can give you that push, the “oh yes, of course, why didn’t I think of that before?” I wasn’t prepared to like this book – it was too thin and full of clever puns and metaphors – but after finishing it, I can see this being a staple on the bookshelf closest to my desk for those difficult moments when I need a shot of inspiration.

Read an excerpt:
http://www.alistapart.com/articles/a-checklist-for-content-work/

Like the book? Come back and leave a comment to tell me what you find helpful!

http://richardingram.co.uk/downloads/110318_pr_workflow_example.pdf

If the format looks familiar, it’s because in the vein of “great minds think alike”, Ann Rockley also uses swimlane diagrams, as shown in her book, Managing Enterprise Content. Richard has added a few extra extra components to provide clients with more context. Richard adds that “there’s nothing about the design process of these types of diagrams that I would consider complicated. Usually, once we’re all happy with what I’ve sketched on paper, I like to use OpenOffice.org’s Draw to rapidly sketch the final diagrams. With several diagrams of this type for any one project I even insist on using Draw’s gallery of preset shapes and icons. I save so much time doing it this way.”

As an aside, I’ve noticed that many organizations are averse to technology-assisted workflow. In fact, one CMS vendor told me that over 80% of customers never turn on the workflow module. Sometimes it’s because it’s “one-step workflow” – the communications person writes, edits, and uploads the content – and that’s fair enough. Other times, it’s resistance to change that holds an organization back. The manager wants to see a Word document, print it out, mark it up, and give it to the admin person who is tasked up the upload process. It works well – until there’s a problem and no one can establish the audit trail for the content. However, documenting workflow is quite useful for situations where content is componentized, re-used, is destined for multiple outputs, or has multiple touchpoints within an organzation.

The advantage of knowing about transactions flows as a deliverable is twofold. First, you can use this to track transactional states and the related content flow. Second, if you don’t have a team backing you up, you’ll be able to create your own transaction flow in order to document your content needs.

Todd O’Neill of Doing Media contributes a sample of a transaction flow for an ecommerce site.

Kevin P. Nichols, a long-time content strategist whose practice leadership has influenced numerous organizations, has contributed a Current State Analysis – Stakeholder Interview Protocol to our deliverables series.

This protocol acts as a guideline for how to conduct interviews to understand the types of content each business unit handles, what their processes are, and whether their content is working for them or requires an upgrade.

Current State Analysis – Stakeholder Interview Protocol (PDF)

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.

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