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:

CMS Myth asked if I’d do an interview in advance of the conference, and the result was an interview called Good Content Means Good Business. Enjoy.

Rachel and Rahel talk with Scott Abel

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

This places the focus on the containers rather than that which is contained, which becomes more obvious in its context of description by technologists. The assumption is that forcing compliance of the containers imbues the contents of the containers with quality. The endeavour is considered successful when the system works as intended, and the contents delivered according to the rules written for the CMS. This is an upside-down view of content, where the tail wags the dog. It is time to dispel some of the most common myths around content and the content lifecycle.

Here are the first five content myths that came to mind.

Myth # 1: A content lifecycle must be tied to a CMS.

No, not at all. Content has a lifecycle, with or without a CMS; a lifecycle is an organic system. Before content was able to be managed in a technology-assisted way, the lifecycle was manual. Often, the lifecycle is still largely manual, and depends on human intervention to move the content from phase to phase. Organizations with large amounts of content have recognized that maintaining the content lifecycle manually is not cost-effective, and a CMS is the logical vehicle to corral and guide the content throughout its lifecycle.

Myth # 2: The success of a content lifecycle depends on the quality of the CMS.

Well, to an extent, but not really. It’s important that the CMS is able to support the content lifecycle, so having a CMS that is robust enough to meet the content needs is important. But having a quality CMS does not guarantee the success of content lifecycle. A CMS can only be programmed to support the process decisions made about the lifecycle. The success of the lifecycle depends on the content strategy that is formulated at the beginning of the lifecycle. If the strategy is flawed, then the content models, work flow, business rules and so on programmed into the CMS will reflect those flaws. So while the quality of the CMS is important, even the most sophisticated CMS cannot save a flawed strategy.

We only need look to the horror stories of the uber-CMS implementations of the early 00s to see how this played out in the past. The projects were all about the containers, and not the contents. The system sales were often made on the basis of features, and ill-suited to the content that needed to be processed. To use a metaphor, customers would ask for a vehicle to transport their content – a sedan, or a minivan, maybe – and be sold a ship, complete with the need for a harbour to dock it in, a crew to build it, and staff to maintain it. Analysis of the content and the content lifecycle would have illuminated the disconnects between the system and the requirements.

Myth # 3: Content can be produced independent of the user-centered design process.

You may rightly point out that content gets created independently of the user experience all the time. I would counter that this is why many websites are in the mess that they’re in today. The user experience professional designs for the process leading up to the content, but not the content itself. Common disconnects include designing spaces:

Too small to display the content in a way helpful to the user. This could result in a list of titles only, when having a content preview might be critical to a smooth user experience, or allowing for an arbitrary number of words or lines of text that results in a non-helpful half-sentence being displayed.

That inadvertently obscure or deprioritize the highest-value content. If content has not been taken through the UCD, it’s up to the designer to intuit what content type goes where. Some UX professionals do this better than others. However, in the spirit of “nature abhors a vacuum,” when design considerations lack research to back up where content types should be shown, that vacuum will be filled by other criteria – designing the content for attractive screen composition may not serve the needs of users.

That completely miss certain content types. Without a content inventory and analysis, the designer can lack certainty about the actual content types and their purposes. The content types could be grouped incorrectly, or presented in inappropriate ways – a whack of PDF attachments, for example, that really should be part of the copy on the site.

Myth #4: The organization doesn’t need governance to manage the content lifecycle.

The governance aspect is a critical success factor. In too many cases, a project has gone sideways or been abandoned because the chain of authority has not been explicitly set out, or because the processes have not been established and approved organization-wide. The governance model should be considered more of a web of determining process around your content operations. In this light, the need for operational processes would not be considered optional. In other domains, there is clearer delineation – for example, only developers can write code – but when it comes to content, everyone is a writer. The guidelines to be established include:

• Who owns which content. When there are differing opinions about who gets to make decisions around the publishing of content, who prevails? A clear set of protocols around content publication needs to be established. Too often, content is created and maintained within silos, and without a governance model, there can be a stalemate. A group can decide that they like recreating content in their little silo, and their circumstances are “special” enough that they get to operate according to a different set of rules. (And while that very well may be so, it has to be established as part of the governance model.)
• What are the content processes. What are the review and sign-off processes that establish how content gets created and produced? Unless there is an organization-wide understanding of how content gets adjudicated, it leaves from for waste. Are there any inter-departmental politics that could jeopardize the publication processes or content in any way? For one content type, we managed to reduce the meeting times by 84% and approval process by 99% just by enforcing a governance model that eliminated some serious political ping-pong between two engineering groups.
• Do we have a periodic review policy? And is management willing to enforce it? Have all the stakeholder groups bought into the project, or will the project be jeopardized if a critical group gets cold feet and decides to pull out?
• Budget. This may not be as straight-forward as it seems. There is likely a budget for creation of content, but what about maintenance? Or you may decide to adopt a new process that will result in significant improvement in localized content, but the localization budget may reside within another department. There may be a provision for cross-departmental sharing of the expenditures and savings, but without any agreement, some departments get very territorial about their budgets. In other cases, the budget for implementing a tool may be through a project budget, but the annual maintenance costs are assigned to another department. These issues are all too common, and all too commonly ignored until a problem arises.

Each organization has a distinct et of tensions that require operational guidelines. If you are new to governance, Welchman Pierpoint has an excellent white paper on Web Operations Management.

Myth #5: Our site is about experiencing brand, not providing content, so there is no need for content strategy.

Please excuse me while I recuperate from my laughing fit. This is every marketing executive’s wet dream: all “brand experience,” no content. I have asked around extensively, and have yet to be shown a content-free experience, let alone a satisfying one. I’m sure the YouTube experience wouldn’t be nearly as compelling if all the video content were  missing, or a Martha Stewart site experience if all the articles and photos and videos were removed.

The bottom line is that the experience is the treasure hunt, and the content is the treasure. Site visitors come to find some sort of content, whether that is persuasive, instructional, or entertainment content. That is the treasure they’re hunting down. The process of finding the content influences the user experience. But, to be clear, ask anyone who has gone on a hunt – from the six-year-old at a birthday party to a site visitor looking for content – and can’t find what they’re looking for: the dissatisfaction becomes palpable. They won’t wax poetic about the great navigation or the affordance on the buttons or the whiz-bang Flash on the home page. The feedback will be that they came to the site to find out about a particular product or service and couldn’t find it. And content findability is part of a content strategy.

What are your favourite myths that involve content and its lifecycle?

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

Content can be described as “everything” (Rachel Lovinger quoting Chris Sizemore) but let’s refine that definition to something more tangible, a definition that can be employed by practitioners and stakeholders for the purpose of designing user experiences.

Simply put, content is contextualized data.

A few years back, I read an anecdote about someone who would send the Google folks a period email with a number. That was the entire email, a single number. Eventually, the recipients figured out that the number was a comment on too many words on the Google home page. Was that email content or data? There is no absolutely right or wrong, but I would posit that without the context of the number, it wasn’t content, it was data.

The number 12 is an example of data. It may have a context in the sense that we know it is more than 11 and less than 13. But it doesn’t have meaning for a reader until there is a practical context:

• a dozen eggs
• December
• players on a team
• children on a schoolbus
• dollars to purchase a product

There is a different type of contrast:

• http://www.bestbuy.com/site/olspage.jsp?id=abcat0101000&type=category
• http://hypem.com/artist/joel+plaskett

In each case, the commonality is that the context that helps with cognitive processing of content.

The practical application of this definition of content could be understood through the following example. A catalogue in a catalogue will have content attached to it: a product description, a photo, perhaps a video of the product in use. There will also be data that gets attached to the content – a SKU, a price. As soon as the data can be understood in context, it has become part of the content.

Content strategists understand the importance of managing content throughout its entire lifecycle, from analysis of business requirements and planning right through to archiving and forensic e-discovery. I believe that what differentiates us from the information management side is that we don’t treat information as data to be managed. For us, context is a critical part of designing the user experience. So while information management and content management is more consumed more with the technologies behind the management and delivery mechanisms, content strategy is closer to the contextual understanding of content, including contextualized data, for the benefit of the consumers of that content.