Skip to Content Skip to Main Navigation

What Technical Communication Managers Must Do to Prove the Value of Their Deliverables

By Hannah Kirk

Editor’s Notes
Technical communication managers, moreso than most other functional line managers need to prove the value of their department’s output and show how it can impact bottom-line profitability. In order to do that they need to be sure that their deliverables really do provide the value the manager is trying to attribute to them. This article uses a case study approach that looks at an enterprise software company’s mammoth documentation set, but the lessons learned can be applied to other technical communication departments as well.

In an ideal world, everyone in a company would understand the importance of technical communication. No departments would duplicate the efforts of technical writers. Every department would use documentation effectively and give helpful feedback. Everyone would understand that documentation is valuable to internal departments and clients alike.

Unfortunately, however, we do not live in an ideal world and technical communication managers are often required to prove the worth of their deliverables over and over again.

To do this, managers must execute two tasks persistently. First, they must prove the value of documentation to those interested in the bottom line and, second, they must make that value true.

The reality is this: if the documentation is not being used and used effectively, it will never help the bottom line. The trick to increasing value with internal and external users is to identify areas where documentation can save time and money, to create agreement that the documentation can save time and money, and to ensure that the documentation does save time and money.

Proving Worth: One Company’s Journey

The Situation

A software company I worked with recently struggled with this very issue. The software this company produces is a complicated enterprise software product for a niche market. It is a highly extensible and customizable product, thus the documentation set is quite large—thousands of pages of material on everything from basic application navigation to extensible programming functions.

The technical communication department in this company is very advanced. They were one of the first technical communication teams ever to use single-sourcing and a customized content-management solution. The output of the documentation includes a .chm file, among other options. The .chm file is most useful for searching the entire documentation set.

One might think that this extensive documentation on a highly complex product would be used often by the implementation teams, training teams, and technical support engineers to help clients with technical problems. However, some members of these teams—those who were crucial to the success of documentation in terms of boosting company sales and saving money—did not do these things.

Challenges to Use

One of the challenges to using the documentation for the implementation team in particular was that the help was not robust enough for certain implementation needs.

Since the documentation did not always meet their needs, the implementation team began writing their own documentation when it did not exist for a topic. At some point, implementation team members then began writing documentation on any concept without first checking for existing technical documentation. Since the implementation team’s primary function was to implement the software, not to write documentation or manage content, documentation was not going through the proper approval process before delivery to clients. Latest copies of these documents were getting lost on desktops. In addition, the delivery of this “rogue” documentation was not in a consistent format.

A serious lack of knowledge of the documentation led to additional problems. During the beginning of an implementation, team members told clients that no help was available, even when the client requested it.

Potential Savings Identified

These challenges presented an opportunity where the documentation could save money for the company:

  • The Implementation Team began writing their own documentation, which duplicated the technical communication team’s efforts and wasted time that could be used for implementation.
  • Clients were given scattered, inconsistent, and unapproved documentation, potentially affecting their image of the company
  • Neither team members nor clients were aware that a complete, approved, and easily searchable form of documentation was available.

Additionally, the implications of telling a client that no help is available for a complex, extensible product are very high. Clients can get frustrated with the implementation and back out or tell other organizations considering the product of their frustrations. This could potentially impact future sales.

In addition, rogue documentation only existed for certain topics, which meant that clients were presented with only part of the information they needed in a series of different files. This risked presenting an image to the client that the company was disorganized and, by extension, not a good one with which to do business.

Solving the Problem

The technical communication managers and their team members repeatedly attempted to involve this team in the documentation process and requested their feedback regularly to address shortcomings.

Managers made considerable efforts to show this team how the documentation could be beneficial. One manager held training classes on how to use the .chm file. Another wrote articles for internal and external company publications to create awareness. Yet another continued to hold meeting after meeting with managers in the implementation teams to demonstrate effective strategies for using the documentation and to encourage feedback.

Slowly, the knowledge of the documentation grew. Technical communications added a feedback form to the .chm file. Documentation users could complete a short survey on whether the documentation was helpful and give comments on suggested improvements. The feedback went directly to the technical communication managers, who sent the feedback to the topic owners to correct and respond to the person who gave the feedback.

The quick responses to feedback and ease of use of the .chm file continued to help the implementation team use the file. Management sent regular email reminders to implementation to remind them to view the documentation first when there was a problem, to ask for the documentation second, and to, finally, request documentation if none existed.

The situation was improved further when technical communication management met with implementation managers to offer them an internal .chm file. Both sides discussed the challenges they faced and a compromise was reached that was beneficial to both sides. Implementation agreed to give feedback or request documentation if existing documentation did not meet their needs.

If the technical communication team could not respond to feedback or a request in a timely manner, implementation would create a document and submit it as feedback to be incorporated by the technical communication team at a later time. Then the document written by implementation would not be needed going forward.

Resulting Improvements to the Bottom Line

Resolving this challenge created improvements to the bottom line for the company by saving time and reducing client frustration in the following ways:

  • Duplication of effort was now reduced to a management-approved duplication only.
  • All internal documentation was presented in one location, reducing time spent searching through multiple documents.
  • Implementation provided feedback that the documentation team used to make the documentation more helpful to all users.
  • Clients were now taught to use the .chm file resulting in fewer calls to technical support.
  • Clients passed along to potential clients an image of the company as one that provides helpful information in a simple way, resulting in increased sales from new and existing clients.

Lessons Learned

The key to ensuring that documentation is and stays valuable is to make this a continuous priority. The value of technical communication documentation is continually at risk without these efforts.

Based on the experiences of the aforementioned company, here are some things managers can do to use the documentation to boost the bottom line:

  • Identify areas where technical documentation can reduce duplicated efforts. Look for duplicated efforts and bottlenecks that occur because of a lack of information.
  • Meet with and educate individuals who can benefit from the documentation and who can contribute to its success. Clearly demonstrate the benefits.
  • Create an effective process for receiving and responding to feedback. Continuously soliciting feedback and incorporating it in a timely manner will impress those who are skeptical that their input matters. This also shows that you want to work with the other teams, not against each other. If possible, personally respond to each individual’s feedback.
  • Be enthusiastic! Be thankful when a team wants to work with you. Do what you can to accommodate them.
  • Use a central location for all documentation. For example, one electronic help file or manual is better than 10 emails with attachments. Using a single- sourcing content management methodology across departments can reduce duplicated writing efforts in many areas, such as marketing, training, product management, sales, etc.
  • Never give up. Acknowledge that this will always be a part of your job as a technical communications manager. Not everyone in your organization will understand the value of the documentation all the time. The best you can hope for is understanding and receptiveness. Similarly, expect to give it back.

Hannah Kirk is a technical writer for Redback Networks. Among her many accomplishments, Hannah has chaired a process-improvement committee that successfully restructured how Ontario Systems writes its online help, and taught numerous online-help development workshops. She has also taught speech and communication classes, and created curricula for a multi-cultural learning community at Purdue University.

Hannah holds both a Master of Science degree and a Bachelor of Arts degree in Communications from Purdue University.