Tips on Outsourcing Technical Writing

By August 26, 2015Uncategorized

Despite having worked on dozens of successful projects over the years, we frequently come across projects where the outsourcing of work is either very difficult or inefficient for the client. In this article we’ll present a short list of issues that can make outsourcing a project difficult and provide solutions and recommendations for each.

One common challenge is when the source information provided to an outside technical writer is believed to be a complete and informative resource. Examples may include design documents, knowledge transfer videos, and other informal resources. Unfortunately such resources are often too informal and may only be useful to a project insider with “internal knowledge”. The solution here is to work closely with the technical writer on how to best harvest the information available. It’s also important to realize that a lot of “leg work” may be required on behalf of the client to prepare these materials for consumption by an outsider to produce detailed technical documentation.

A similar problem occurs when detailed information is to be created from information that appears self‑explanatory on the surface. Consider as an example, an inventory management system with entities like account, client, product, etc. In one case a client asked a writer to create descriptions for these entities without providing any information about them under the assumption the writer could come up with that information themselves. While a writer could deduce what each entity represents, only the client could provide detailed information such as the relationship and dependencies between each entity. The best option here is to spend some time up front coming up with a list of key points about each entity so that the writer can incorporate them into the documentation.

From a timeline perspective, product schedules always offer a challenge to all aspects of a project. And more often than not, technical writers are brought on too early under the assumption that they can get a head start on the documentation. Unfortunately when the product has not matured enough yet, it can be difficult and overly time consuming to obtain and record key concepts and functionality, especially when the design in a state of churn. As a result it takes more work in the end to go back and modify documentation that was written while changes and development were taking place. This is especially true for materials like recorded media (e.g. video tutorials), where screen capture for example, must be redone in part or in whole. The solution here is to work closely with the technical writer to determine when the documentation can be started. While there may be external pressures to produce the resources (e.g. from customers), this must be balanced by recognizing when a product that is in development is mature enough to be documented.

Next up are resources and personnel. While a lack of time can offer a big challenge, the lack of source materials and subject matter experts (SMEs) can be an outright barrier. While developers and other SMEs may be busy writing code or designing the product, time must be built into their schedules to convey technical information and answer questions posed by the technical writer. Without the deep insider knowledge provided by SMEs, it can be very difficult for an outsider to obtain specific, technical details on their own. Thus subject matter experts play a key role in conveying knowledge to the technical writer.

As part of this, “good” subject matter experts need to be identified and selected. Selection should include those with a good understanding of the product’s design and functionality, and good communication skills to convey information and answer questions. Note that some SMEs like to focus solely on product development (e.g. coding), so find those who are willing to share some of their time and those who can have this time allotted to their schedules. Since technical writing is typically 70% percent information gathering, and 30% writing, a technical writer often needs a good chunk of an SMEs time to obtain information. Thus availability and selection of good SMEs is critical.

On the flip side, we’ve seen a few projects where too much information and background detail were provided. While the information provided was generally good, the client could have written the documentation themselves faster than trying to convey ever bit of information. Thus the use of an outsider was inefficient as it took the writer excess time to filter out what needed to be documented. The best solution again, is to work with the technical writer to determine what level of detail works best for them. Often short bullet points will suffice, along with a few conference calls, and access to some source materials. Also, letting the technical writer drive the questioning after the first initial meetings will help to focus in on what needs to be documented. Finally, any ideas that need to be clarified or added will be handled during the review process.

Finally, style is another issue that needs to be conveyed upfront. Often times clients have very strict grammar and voice rules, some of which may violate best practices and even standard grammar rules. Thus the rules to be followed in the writing, and their importance, need to be emphasized up front. Review of materials should also be done as soon as possible to ensure the content is following the rules, especially when multiple writers are involved.

So with all of these factors in mind, the following is a short summary of attributes which will make for great outsourcing to a technical writer:

  • Information is both available and comprehensive enough that a technical writer can extract most or all of the content to be documented with minimal assistance.
  • Subject matter experts are available for all areas to be documented, are willing to help, and have good communication skills.
  • The project has advanced to a state where it can be successfully documented.

In the end it all comes down to knowing how to best work with outsider, whether it be a technical writer or another resource. Hopefully these tips will help you in outsourcing your next project.