Speaker Insight [What's this?]

What I'm hearing time and time again from project managers is that content has become the major pain point of their projects. Organizations have lots of content, but because operationally, we haven't dedicated the resources to it that we have for other corporate assets, we're not managing it with the same level of care of other assets.

As a result, we haven't brought content up to the standards - technologically and often quality standards - that it needs to be at to work in our increasingly automated and technically-manipulated workplace and marketplace.

Content needs to be agile in many different ways. In its creation. In the way it is managed. In the way it is presented. When I think of agile content, I think of content tailored for its users and with possibilities for users to provide feedback.

In the Dark Ages before the Internet, bound in the closing pages of a technical manual would be one or more pre-printed Reader Comment Forms that you could tear out, fill in, and mail back to report any problems with the content or examples you wanted to add. The disclaimers made it clear that you might never hear back directly about your input.

That was then.

Today it is hard to think of any content that you would intentionally try to isolate from human social contact in that cruel fashion. Socializing information allows it to be improved by "the wisdom of the crowd" and republished almost immediately. The challenge lies in making sure that you can still certify the truthfulness of what the crowd adds to your content. "Content agility" is the process of managing these various revisions of content practically at the pace of speech (which rhymes with "tweets!").

As software development organisations recognise the benefits of agile methods over conventional (waterfall) ones, technical communicators need to work hard not to get left behind. An agile development organisation learns to be more flexible, and more responsive to emerging customer needs, and starts working in shorter and shorter product release cycles.

"Agile content" suggests an evolution: from "documentation" -- monolithic, static, self-contained, passive structural descriptions of product as artefact -- towards information repositories -- multi-faceted, dynamic, connected, proactive and practical facilitators of product as solution.

In the life cycle of a customer's interaction with a product (and its provider), modern customers do not expect that they should know the internal organization of a company to determine whether they need a Product Update Bulletin from Sales or Screen Help from Tech pubs or a Field Alert from Support. They rightfully expect that they'll get the appropriate information exactly when they need it. Ideally, the customer doesn't even need to know that something like a "repository" exists; they simply receive the information content how and when they want it. Developing and delivering the content of such repositories is the challenge we all face right now.

For many organizations, the expectations of their customers have outpaced what their information managers can provide -- and in some cases, can even conceive of. The notion of "agile content" would thus seem to encompass several aspects: development of increasingly sophisticated information in multiple media, storing it in such a way that it is accessible and relevant throughout an organization, and designing the optimal user experience when the information is needed.

Not only has content to be succinct and relevant to the customer, but it has to be structured in such a manner that it can be reused at a sub-component level. Agility now means that all the best practice of the last years has to be carried over into a real-time environment, where authored content can be delivered globally in the near instant.

These days people are flooded with information. Providing our users with the information they need, when they need it, should be the aim of every documentation specialist. More than ever, we need concise, clear information that supports our users' daily work.

Content agility means being able to quickly respond to customer requirements and make sure they experience delight, rather than pain when they need to find information.

It also means giving customers the information they need before they consciously start looking for it - for example, investing more in documentation that is embedded alongside a product.

Content is no longer being created, stored and shared for just one purpose or media. To address both the current, future and unforeseen ways we will have to share, use and disseminate content today and into the future requires content to be in a format that supports agility.

Today we might need to distribute the same content to web, tablets, printed documentation, smart phones and search engines. We also might need to use the same content for user, training, technical, marketing, help and other documentation. Again, all requiring agility in content.

Content agility means quicker time to market and quicker time to customer. These are two of the key aspects that drive our business. Agile content improves both.

Content needs to be as agile as the people who need it, when and wherever they are. One way to achieve that is to repurpose and reuse more efficiently the content that you have, and using DITA within a CMS helps.

Customer expectations, new technologies and the never-ending quest for the ‘perfect’ customer experience means that content is consumed in different ways, on different devices and in different languages. Some prefer to read content on the printed page, some want a video on their iPad, some want to interact with the content.

Whatever the customer expectation is, organizations that create content need to adapt to that, which means their content needs to be agile and ready for the next wave of technologies and changing customer expectations.

I'm not sure of content itself needs or can be agile. It's more that content processes need to be adapted to whatever overall process a company follows - be it waterfall or agile. And content processes need to be defined in alignment with what internal teams need - but both sides need to be flexible to change processes - not only the content side.

Content that has "agility" is portable, reusable, manageable. You can find, transform, and evaluate it so that it gets where it needs to go on time, on budget and to the right audience on the platform of their choice. You can understand it better by understanding what it is not: Content locked in storage and delivery formats that require investments of unfeasible amounts of time and money to effectively filter, search, reuse, translate or republish is not agile. Content with agility isn't 'magic'. It doesn't write itself and it doesn't solve all your content problems.

It does however solve a LOT of them, leaving you additional resource (again, time and money) to focus on improving processes, refining your audience personas and building bridges with your peers and their content. This all makes the overall business benefit and customer experience contribution even greater.

Finally, content that is "agile" should be top-line (like marketing) and bottom-line (like tech docs) oriented. It should be good for improving your product, brand interactions and experience - leading to more top-line revenue from happy customers. It should also take the donkey-work out of getting there - leading to lower costs and better bottom-lines.