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

I quite dislike the laundry list approach to skill sets, and avoid the allure of “top ten” lists  that are supposed to be a one-dose-fits-all remedy. However, in an attempt to provide a succinct resource that can be useful to those wanting to round out their knowledge, I’ve created a suggested reading list. It is not meant to be a definitive list, and likely has more benefits to technical communicators who want to manage large bodies of technical content with more efficiency. However, I stand by my belief that those wanting to make the transition to content strategy will benefit from havin some knowledge  in each of these areas. I’d be interested in feedback and additions.

Requirements Analysis

• Identify business needs
• Understand corporate motivations and goals

Deliverables:

• GAP analysis
• Requirements matrix
• Process models

Learn from:

International Institute of Business Analysts – Body of Knowledge

Information Management Center – Information Process Maturity Model

User Analysis

• Identify key audiences
• Understand user motivations and goals or tasks

Deliverables:

• Needs assessments
• Personas and scenarios
• Flow diagrams

Learn from:

Ethnography

The User is Always Right

UI Flow Diagrams

Content Analysis

• Take inventory of existing content and documents
• Categorize content

Deliverables:

• Content inventory
• Content audit
• Metadata taxonomy
• Content models
• Content architecture
• Wireframes
• Delivery design

Learn from:

Adaptive Path on inventory

The Rockley Group on audits

Gerry McGovern on metadata

Content modeling

Content standards

Information Architecture Institute

Multi-channel publishing

Get Content, Get Customers

Content Design and Production

• Production workflow analysis
• Create content business rules
• Design content
• Develop content

Deliverables:

• Business process maps
• Topic maps
• Customization and personalization maps
• Localization plan
• Page tables/layout templates
• Standards and style guides
• And, of course, the content

Learn from:

AIIM Training Programs

Steve Pepper on Topic Maps

Letting Go of the Words

Web Content Accessibility Guidelines

The Culturally Customized Web Site

Content and Technology

• Managing content
• Content standards
• Content management systems

Deliverables:

• Technology recommendations
• Implementation strategy

Learn from:

Content Management Bible

W3C Standards

OASIS Standards

LISA standards

Wikipedia review of CMS types

There are a few resources not included in this list, only because they span multiple areas mentioned above. These are the books about content strategy, whether or not called by that name:

Managing Enterprise Content: A Unified Content Strategy, by Ann Rockley

Web Content Strategist’s Bible, by Richard Sheffield

Content Strategy for the Web, by Kristina Halvorson

Information Development: Managing Your Documentation Projects, Portfolio, and People, by JoAnn T. Hackos

As a final note, hats off to the founders of the content strategy knol (unit of information) where practitioners are welcome to contribute resources, to consolidate information into a central location.

Previous posts in this series:

The extraordinary world of content strategists

Abilities and aptitudes for a content strategist

Content strategy: the skills conundrum

For example, a content strategist in the user assistance field – technical documentation, help, training, support, and related content – should know enough about the differences between major content development processes and technologies to be able to know about content migration, optimization, workflow, delivery, and management within that realm of content. Does that mean a deep knowledge of RoboHelp, Flare, Author-It, Vasont, SiberSafe, XDocs, XMetaL, XML Mind, RenderX XEP Processor, Antenna House Formatter, DITA Open Toolkit, and whatever other Web CMS, SharePoint, or collaboration tools are out there? No, absolutely not. However, the strategist needs to have enough experience with a range of these tools to know the differences between how they process content (and the determination to find that information). The strategist also needs to know how to exploit the content, and how to determine which system works in which situation.

A typical job posting for a content strategist focuses on the abilities needed to make strategic decisions. Here is one such example, which asks for:

• 2-3 years experience in online content strategy, particularly as an Information Architect or Web Content Manager
• Ability to develop user scenarios to better sort and display various types content
• Ability to create and edit prototypes and IA deliverables
• Experience writing and editing content for the Web
• Knowledge of web standards, including W3C compliance, accessibility (section 508) and the SEO implications of information architecture
• Understanding of the capabilities and limitations of Web technologies, including cross-browser compatibilities, HTML, XHTML, CSS, JavaScript, XML, AJAX, PHP, Flash, Flex and mobile computing
• Ability to clearly articulate to internal team as well as clients the reasoning behind usability choices and recommendations
• Strong organizational skills and a basic familiarity with [a popular CMS]
• The ideal candidate will also have work experience in providing content strategy recommendations.

However, the temptation of organizations to simply ask for a laundry list of software skills has already begun. This approach, known in professional development circles as lazy recruitment techniques, confuse knowledge of a tool with quality work. A quick Web search revealed this post from a recruitment agency who seem to think that a Web developer with some creativity and the ability to articulate to stakeholders makes for a good content strategist:

Required skills:

• Drupal, CSS, Photoshop, Flash, Action script, Adobe CS2+, Google Analytics, WordPress development. Experience in Joopla recommended.
• Proactivity: A key part of what this role involves innovating the way of communicating our content through the web. Success in this role will require the ability to articulate, argue for and proactively push through your own creative solutions to problems.
• Proven track record of success in prioritizing and managing multiple projects, project forecasting, and resource planning
• Excellent verbal and written communication skills – comfortable explaining problems, options, and decisions to stakeholders

Education/Experience Requirements:

• Bachelor’s degree required
• 5+ years’ experience in a web management environment

This  organization (and many others like it – this example is by no means unique) may say they have a “strategic position requiring excellent project management and user interface expertise, as well as strong collaboration skills and a strong passion for [our] mission of principled performance. The ideal candidate will have experience visioning and implementing strategy to align content with the user experience and has the technical skills to work with the Drupal content management platform” but is that really what they mean?

What they are actually saying is that they’re not sure what a content strategist does, so they will list some software packages and a few skills having little to do with the actual development, management, or delivery of content (and that tend to be mutually exclusive – big picture thinkers are rarely detail-oriented) and see what happens. In the vein of “the music is not in the violin,” the ability to use a range of software tools is not what makes a good strategist. Many industries “hire for aptitude; train for skills.” This seems like sound advice for the emerging practice area of content strategy, particularly because so much of the work is tied to aptitude.

Related posts:

The extraordinary world of content strategists

Abilities and aptitudes for a content strategist

Skills to transition to content strategy (coming June 16th)

Putting myself in the hiring chair, I would look for someone who works well within a T-shaped creative process.  The linked graphic is from David Armano, and meant for professionals working at the intersection of interactive marketing and experience design. However, these are the same talents distinguish content strategists from smart writers or smart technologists. These are the people who have insights into content, can develop a big idea from a content corpus, and articulate that idea in conceptual terms. They have to care that content is not just useable, but useful and desirable.

Let’s face it, a single strategist likely can’t be a master at all the details in every aspect. However, the strategist is not the person who asks: how do you want this content delivered, but after an analysis, tells you how the content should be delivered, and why, and to what benefit. The strategist should be able to do so using core consulting methodology, simplified here for sake of space: determine current state, analyze the requirements (of the business, content, and users), determine future state, identify gaps, and create a roadmap from current to future state.

Understanding the nature of content – from genre analysis to taxonomy to delivery models to line editing  – is a given. Processing content is not like processing data; it’s a lot more subtle and complex. A content strategist needs to have some sort of content background – English, writing, journalism, library sciences, translation, or related fields -  to understand the qualities and properties of content. You may be able to inventory content without understand a lot about its nature, but undertaking any sort of content analysis or taxonomy effort or content rewrite implies some measure of skill at content development.

The content strategist should be able to work as part of the larger team, whether that be a CMS project team or an ongoing user experience or creative group or product development team. More importantly, a strategist should understand how important it is to be part of the big picture, and understand how to integrate the content strategy within the larger organizational plans. This means an understanding of traditional and emerging business models, and communication paradigms that support various types of marketing and customer relationship efforts. It also means that sometimes the strategist may be called upon to create what are generally thought of as information architecture artifacts: conceptual IA models or wireframes. Though this may be a small part of the overall activities, knowing user-centered and experience design processes is an important part of a content strategist’s toolkit. Knowing how to apply these techniques to content is definitely worth bonus points.

It also helps when content strategists are technology aware – in other words, knowledgeable enough about current and emerging technologies that they can recommend strategic ways of implementing content. In other words, they are not the carpenters to whom every problem looks like it needs the same hammer-and-nail solution. I’m not talking technical acumen – there are way too many complex software apps out there to be both a content strategist and technologist. But the strategist should have enough conceptual knowledge to understand how content should or could flow through a system, and which types of systems will deliver the goods for a particular business need. This means system awareness, knowledge of implementation best practices, content migration  techniques, content standards, and an understanding of the interrelationships between people, processes, and technology.

Related posts:

The extraordinary world of content strategists

Content strategy: The skills conundrum (coming Jun 14th)

Skills to transition to content strategy (coming Jun 16th)

Content strategy is a little like that. We are practitioners who understand content. We understand it at a level that many people never stop to consider. We understand the potential of content in ways that others overlook. We understand how content connects to other content, how the development and delivery of content affects, and is affected by, practices connected to our profession, and how content connects to content consumers.

Where content strategy differs from the medical metaphor is that our understanding comes, not from a common educational background or some content boot camp, but from a wide range of professions. There is no Bachelor of Content Strategy upon which you can build a specialization in technical communication, marketing communications, social media, or enterprise content. Instead, practitioners come to the content strategy table with their specialties already in place, and stretch their wings to embrace ideas beyond the confines of their existing fields of practice.

Makings of a content strategist

The model for content strategy is more like  that of management consulting. Every management consultant has come from a different background – accounting, operations, technology, communications – with the commonality of understanding industry best practices, and being able to apply them appropriately, according to the situation. In fact, the Wikipedia definition of management consulting is both the industry, and the practice, of helping organizations improve their performance, primarily through the analysis of existing business problems and development of plans for improvement.  Using this paradigm, then, a content strategist is a management consultant with a specialty in improving performance of content.

The Wikipedia article on management consulting goes on to explain that “consultancies may also provide organizational change management assistance, development of coaching skills, technology implementation, strategy development, or operational improvement services. Management consultants generally bring their own, proprietary methodologies or frameworks to guide the identification of problems, and to serve as the basis for recommendations for more effective or efficient ways of performing business tasks. ” This sounds a lot like what we do as content strategists:

The skills to look for in a content strategist, then, can be specialized – for example, a content strategist working with newspapers concentrates on areas different than the strategist dealing with website marketing, who concentrates on areas different than the strategist dealing with user assistance content – but share some common underlying qualities.

Next posts in this series:

Abilities and aptitudes for a content strategist (coming Jun 11th)

Content strategy: the skills conundrum (coming June 14th)

Skills to transition to content strategy (coming June 16th)

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

I’m proud to be one of the keynote speakers of the STC Content Strategy Forum 2010, and can tell you that there will be a fabulous line-up!

https://www.regonline.co.uk/csforum10

So when it came time to changing the answering machine greeting message, I followed the instructions only to discover that there is no option to select. I tried all the little tricks to see if the option got hidden elsewhere in the menu tree, but it was definitely missing. Well, that’s fine; I will tough out the pain of contacting customer support, through the phone number in the back of the book. The phone number works in Canada – always an iffy question – so that’s encouraging, and after listening to all the preambles, I press 1 for English, enter my product number, and go through the various menus but there is no option for “menu items are missing”. It seems that all the options end up the same way, leading to an end point of “visit our website at …”.

Now, gigantic corporations all have us trained to despise having to call in; in other words: Don’t you think I’d have checked the website first if I thought I could find the answer on your website? It would have been so much easier: go to the site, choose the model number, and  But of course, the user experience was quite painful. Here is an encapsulation of the frustration points:

1. After doing a Google search for AT&T 84209 (the model number) phone, I kept getting routed to the att.com site, which was obviously US-based, and geared to telephone service subscribers.
2. I redialed the number from the instruction book and was given www.telephones.att.com as the URL. Typing in 84209 got me to a shopping area. Do I want to buy a replacement cordless battery? I must say that if I happened to know the model number of a phone I wanted to buy, I’d be in luck because the second shopping option is to buy the very phone that I’m getting annoyed over.
3. There are links to the manual and Quick Start guide, which I consulted and had the same incorrect information.
4. Filling in the Contact Us form field promises to net a response within – depending on which of the messages you believe – 72 hours (on website), 2 days (on-screen auto-reply message), or 3 days (auto-reply email) but I doubt that I’ll get a meaningful answer. It may be too late anyhow, as I’ve run about the house, disconnecting telephone bits and bobs and tossing them into a bag to return to the store.

Now, I admit that my question is not one of the top ten questions, and it might be embarrassing to put it on the automated reply options (Press 8 if the interface  doesn’t work as per instructions.) but surely someone has asked this question before, and somewhere, a content developer has tackled this discrepancy. The point is that there needs to be a strategy around content that goes beyond the basics. Now that I’ve calmed down and revisited the situation with an industry insider’s eye, the support site is lovely – beautiful colours and the navigation to the FAQs is quite simple. But when a customer is searching content, and can’t find it, then all the other niceties fall away. The laser beam focus on finding the content, which is needed to complete their task, overrides all other aspects of the user experience. Task-based analysis at its best.

So to AT&T, I would ask: if one of your questions is “Who is Charlie Johnson and why is his name displayed on my phone?” surely the question of missing menu items could be addressed, as well? This site is a classic example of focusing resources on the usability side of the support site, but not having a content strategy befitting such a site.  In this case, I did receive an email a few days later, referring me to a “real person” in another department, but by that time, my answer was, “Thanks, but too little too late. I’ve exchanged the phone for another brand.”

Seeing as how returns of electronic consumer products is a multi-billion dollar problem in North America, companies could definitely benefit from having strong content strategies, not just on their website, but across the product line, from instructions to training to their support site.

If you’ve never been to CANUX, you’re missing out on a fabulous opportunity. Being up in a resort-like mountain setting at the Banff Centre imbues the workshop with some cosmic-force creative atmosphere. There are a few days left to sign up with the advance discount, so don’t delay if you’re sitting on the fence.

The issue with “Content strategy for the Web” is that for me, the Web a single output format.  What happens when I put the some content out on the Web, and send it to Training to incorporate into their training materials, and share it with the Customer Support group, so they can incorporate it into the knowledge base for service reps, and send it out to a PDF so it can be printed as a manual? My mandate is obviously bigger than “the Web,” but more importantly, the framing shouldn’t be by output channel.

While the term “content strategy for the Web” doesn’t say this explicitly, there are several implicit connotations: the content is marketing content, and the Web is where content consumers go to read it. The differences between content for the [marketing] Web and [marketing] print material has to do with length, look, keywords, search engine optimization, and so on.

Ann Rockley gave her earlier book, Managing Enterprise Content, the subtitle of “a unified content strategy” but the concept of “unified” is not well understood by our audiences. Unifying what and what:  Web and not-Web? Marketing and technical? When the questions I get asked start with “what do you mean by the word content?” the whole idea of unification becomes a hurdle that sometimes my audiences never get to. The type of content strategy I provide isn’t the normal definition of enterprise-wide. It doesn’t include email and ediscovery, or records management for HR, or ERP data, or any of the stuff that information-management gurus look at as enterprise content management.

Yet we know that the power to name what we do can define expectations – not to mention make search terms so much more effective! So what do we do? In an effort to frame our focus, I looked at our activities, deliverables, and scope of content, and realized that there are a couple of basic common denominators:

• The content is on the critical path. We’re not talking about email or HR records. We’re talking critical-path product content. The content is related to the product being sold or service being provided. This means product content that gets used in multiple contexts: technical documentation, training, and customer support, and marketing, as well as content that gets turned into product content, such as engineering specifications, product-related user-generated content, and content used in a social media context.
• The content either supports pre-sales purchasing decisions, or it supports the post-sales relationship between you and your customers. The content may not always be customer-facing, but it is used to build the customer relationship. Why both of these stages are important is because the pre-sales stage is like dating; and the post-sales stage is like marriage. Consumers, and perhaps more importantly, industry analysts, look to see what the relationship will be like once you’re hitched, and they do that during the dating stage. So the content we’re concerned with is, essentially, relationship content.

Joe Gollner calls it “content in the context of forming persistent business relationships.” I like this definition because it defines the content by its function rather than by its output mechanism. However, someone might posit that email exchanges between staff and customers also serve the purpose of forming or maintain persistent business relationships.

I then (re)turned to Karen Donoghue’s book, Built for Use: Driving Profitability Through the User Experience, wherein she makes it clear that every successful transaction that a user has with a website has the effect of taking a step closer to a trust relationship; every unsuccessful transaction send the user a step (or two or ten steps) away from that relationship, and in some cases, irreparably damages the relationship.

Given that part of my mantra is cross-silo consistency – your content should be consistent on your site, in your print documents, in your PDFs, on your product packaging, in your service agreements, in the software interface, and wherever else it appears, AND throughout the entire lifecycle of the content – then the logical conclusion I draw is to connect my type of content strategy to the user experience. User experience helps form and retain persistent business relationships; content is a critical component of a user experience.

Then, do I call this user relationship content? I can just see the look on the face of an executive as he mutters something under his breath to the effect that his company doesn’t have a dating site. As a good content strategist, I realize the importance of crafting content to be effective for my audience. So who is my audience: the practitioners who want a technically accurate description of the craft, or the decisions-makers who are potential clients for my services?

In this case, I have to admit that I’m leaning toward a client audience, and hence the designation of content strategies for the product life cycle. Product life cycle is a term that resonates with product managers, program managers, and other mid-level to executive-level management, and all the content related to the product lifecycle – soup to nuts, so to speak, of the content lifecycle – is what is at stake in my type of content strategy. When I use this phrase to describe this to potential project sponsors, will they understand it? Will we do our field of practice justice by calling my work product life cycle content strategies? Let the debate begin!