How ITIL is changing technical communicators' jobs (or How I stopped worrying and embraced ITIL)

It was about six years ago when I first started hearing people use the term ITIL in sentences at BMC. At the time, I was working with a new software product line. Technical communicators in my workgroup, as well as the rest of the product team, learned about ITIL-related best practices that were relevant to our customers' everyday business. As a result, the technical communicators took responsibility for publishing best practices information to customers. That experience was the first of many changes to come as ITIL gained acceptance in the IT software industry. Since then, many of the technical communicators at my company have become certified in ITIL Foundations. While it's true that the certification is great for professional development, we all must be prepared to put that training to use, pairing it with the traditional tools of the trade for technical communicators (skills in communications, research, and analysis, just to name a few).

After certification, you will need more than a working knowledge of the ITIL Service Support and Service Delivery disciplines. It's likely that you'll be tasked with learning how your software, your company, or a group of users that you support can work within the ITIL framework. For example, if you document event-generating software and your users expect ITIL best practice guidance in the user information set, where will you start? Will you have access to ITIL-knowledgeable SMEs who can help you match functions, features, and business results to the best practices that are supported by the software? Do you know the business of your company and your customers' product usage well enough to communicate its technical features and functions as a business solution? Do you have the experience in business, workflow, and task analysis that are needed for the research?

In the pre-ITIL days, the tasks covered for the event-generation software in the example would have been limited to what's possible within that system, with some coverage on integration capabilities. However, ITIL forces us to look at that software as it will relate to the Service Desk and its role in Incident and Problem Management, as well as other disciplines. After all, it's not likely that any company buys software for event generation just for the heck of it; those alerts and warnings about the monitored components have to go somewhere.

At BMC, technical communicators are pioneering how to address ITIL support when business solutions cross product line boundaries. In many cases, the goals of several ITIL disciplines must be addressed in a single business scenario, and that is forcing us to re-examine which deliverables should contain process-level versus task-based information and develop new information models. Technical communicators have always advocated publishing workflow context for users of technical tools rather than product-centered Help or hardcopy user information; the very nature of ITIL encourages all project teams to learn business processes and document from that perspective. And that's surely a good thing for users. How is ITIL changing your job as a technical communicator?