The Case Made: How a contract documentation team made the business case for its permanent status

by Kevin Cox

My company hired two contract technical communicators to build a temporary documentation team to work on a large technical report project involving hundreds of components, and many personnel. To give an idea of the size of the project, part of our task included over 32,000 pieces of data, which was to be contained in 42 reports. The project, for a large state agency, was to take at least six months to complete.

In addition to building the team (with the help of Human Resources and a local temporary staffing agency), we were asked to devise and develop a process for the process of writing, editing, and performing quality assurance on the reports, based on pre-written segments by subject matter experts in 11 separate disciplines. We were also asked to define the role of each person on the team, create and maintain a schedule for the project, create an infrastructure for archiving the report at each step of the process, and provide for contingencies. In short, we were being asked not only to provide documentation services, we were being asked to be project managers and “strategic contributors!”

It is not in the scope of this article how our team accomplished these tasks; we now need to fast-forward to a time in the middle of the project, after receiving accolades from co-workers outside the documentation team on the terrific job we were doing.

This company is an engineering consulting firm that relies primarily on documentation products as a large part of its services, which are usually in the form of technical reports, and marketing proposals to obtain contracts. In 2000, the company's Portland office consisted of a staff of 30, with a word processor supporting that staff. In 2002, the staff had grown to 75, supported by a word processor and a technical editor. By 2004, the size of the office had grown to over 100 employees, and only a graphic designer had been added to the word processing and editing support.

In an all-staff meeting at the end of 2003, management stated that more, larger, more complex, and more controversial projects were in the works for 2004. This piqued my, and one of my team members' (the project coordinator) curiosity, and with the support of the technical editor, we felt that the company needed a larger, permanent documentation team to support these future projects. Also somewhat amused at the situation, we talked about this with our supervisor, a respected, high-level, document-savvy engineer/project manager, who readily agreed with our views. He asked me to develop a Powerpoint presentation to present at a meeting of Portland office upper management, which I did, with his help and that of the project coordinator. This presentation covered the following points:

• Explaining the company's current and future needs, and why a larger documentation team on staff would benefit the company
• Outlining the development of today's complex flow of information and technology
• Summarizing what a documentation expert is and what he or she does to add value
• Describing how a documentation team on staff adds value to the company's goals and core values
• Explaining what the contract documentation team has accomplished for the current project

We highlighted these points using text and graphics and sparse humor to enhance the clarity of our message.

In the presentation, we explained that o ur work, and the expectations of our clients, demands that we expand the capabilities and quality of document production and that we must scale the document production capabilities to the larger size of the office. We also explained that we must leverage senior resources -- allow project managers and subject matter experts to step away from day to day documentation project tasks, releasing them to do what they do best: sell the company's products and services, create more revenue, and solidify the company's reputation as a leader in its field and a creator of high quality product.

We also noted that we expect that the office would continue to grow. We recommended adding the capabilities of QA/QC processes, large documentation project and scheduling management, and continuous improvement to the capabilities already present.

Next, we outlined the development of today's complex flow of information and technology as it relates to documentation processes, and how the complexity, immediacy, and globalization have been added to the mix of communication services, adding that the future holds only more complexity, new and better technologies, and more globalization.

The presentation then explained to the management team what a technical communicator is and does, and how these skills can improve a company's bottom line, emphasizing that the quality of documentation must be at least as good as the science (or other information) that the documentation is communicating; if it is not at a high standard, the audience may question the accuracy of the information itself. Other points made were that technical communicators not only write documentation and manage and coordinate information flow and documentation projects, but that they:

• Ensure the clarity and accuracy of technical information -- “casual” documentation is no longer acceptable quality – and focus on the quality and usability of the end product
• Develop clear, concise communication that addresses users'/clients' needs, and add to a company's cost-effectiveness
• Reduce costs to clients by providing high-level skills that bill at lower-level pay scales
• Prevent miscommunications that can cause litigation and cost the company money
• Are advocates for the end-user, acting as “translators” for non-technical readers, and d esigning information with multiple users in mind – for all levels of understanding
• Create many different types of products (giving examples of each)
• Use many different types of media for those products

We also noted that with STC membership (three of our current and contract staff are STC members), technical communicators employ the power of ongoing training, and that membership offers opportunities and resources for professional growth.

The remainder of the presentation explained what the current contract documentation team had accomplished for the project, summarized the points made earlier, and posed this scenario to the management team:

Situation: You (the project manager) have a large, complex document project to produce for a client involving multiple media and public and agency review, with a contracted schedule and budget.

The team:

• Identifies the processes and options to complete the project, communicating with other specialists inside and outside the firm
• Sets up systems and a schedule, which you outline in your work plan, freeing you for technical and project management and budgeting work
• Assembles the team and communicates responsibilities
• Develops the documents, and tracks their development
• Coordinates distribution, record handling, and closeout

The response from the management team to our recommendations was an unequivocal “yes”, with support from almost all members.

As of this writing, the project coordinator and I have been added as permanent staff to the company, and I have been asked to participate in other projects as my time for the project I was hired for allows; our priority is meeting the deadline for the project we were contracted for. The Principal in the office does indeed understand and support our recommendations, and as a result of our presentation, has changed his attitude from “I'm not sure how this will add to improving our bottom line” to “Oh-my-gosh-we-really-need-to-do-this-and-how/when-are-we-going-to-do-this?”

I plan to follow up on this article in six months or so, to share more results of our journey of making the business case for technical documentation staff.