Collaboration in Technical Documentation

Collaboration is a baseline requirement when documenting any technology-dependent product, because technical documentation, like the product it describes, is created by teams of people. No one person can create detailed documentation for a product that has deeply-embedded technology such as a PDA or an automobile.

Likewise, large companies that manufacture complex products are typically driven by supply chain requirements. Technically, these companies are not manufacturers as much as they’re assemblers. Take Ford or BMW. They don’t actually “manufacture” cars. They assemble cars out of components that are manufactured by their supply chain ecosystem.

The assemble/manufacture distinction highlights the presence of in-house and third-party components – or sub-assemblies – in a manufacturer’s product. The distinction also highlights the burden placed on product documentation teams, who must now track these components from the beginning to the end of the supply chain process. That is, the team must supply documentation for the product’s components as well as the product itself.

The critical aspect for this type of documentation is seamless integration for the end product.  Complex, sub-assembly driven machinery has to have a consistent presentation schema for the overall final product, which becomes even more of a challenge when you consider that often the subassemblies are manufactured by plants that are scattered around the world, and employ people who most likely do not speak the same language.

Take a CAT scanner from a company likeSiemens Medical Solutions. It’s a large, very complex machine with many parts supplied by a wide range of contractors. In turn, the documentation must address not only the scanner in it’s entirety, but there needs to be detailed documentation for each of it’s components. In addition, each sub-component needs to be documented multiple times, and in multiple languages.

Technical documentation must reflect different audiences, from the end user to the field service rep. End users need documentation that helps them use the product correctly (a stringent requirement for medical devices). Field service reps need information that helps them fix and maintain the product in the field. Both aspects of this are based on the delivery of accurate and up to date technical documentation, but each set of documents needs to be designed to meet the individual audience’s unique needs.

In each instance above, geographically distributed teams of people are collaborating toward an end result. If the objective is to produce a 4,000-page manual for a CAT scanner in time for shipping with the product, the product manager will create a functional specification that describes what the product must do, based on end-user requirements. Engineering will develop design specifications based on end-user requirements. These core documents, the functional and design specifications, become the basis for a broad range of spin-out documents that can be re-purposed to meet the needs of a variety of audiences, from sales and marketing, to call center support and field services training, all of which are driven by the technical writing team re-purposing existing content. If done correctly, tech writers can often re-use up to 50% of an existing core documentation set., which not only results in a big jump in productivity, but in substantial cost-savings as well. Care for a specific example? One major medical device manufacturer who implemented a content management system specifically for the purpose of increasing collaboration saw their documentation costs for one product drop from $3 million to $300,000 in less than nine months, while decreasing production time from three months to less than three weeks..

One product manager might be responsible for producing a 300-page manual that describes the CAT scanner’s rotation arm. The product manager will work with the technical documentation team to create the functional specification, detailing what the rotation arm is, how it works, factors to consider under different operating environments, CAD/CAM images of the arm in action, etc. Once this step is complete the tech doc team  then moves into re-pupose mode.

Part of this manual may get pulled out for a marketing data sheet. Part may get repurposed for training materials for the field service people. Part may be used to provide information to a call center support person, who may be answering questions from people in the field struggling to service the CAT scanner’s rotation arm. And yet another section of the manual may circle back into engineering as part of an archive that documents how their technology was used.

Regardless of how the original 300-page manual was used, a team of people worked together to create a final product. Here, documentation standards such as DITA (Darwin Information Typing Architecture) are crucial because they create structural consistency for information organization and presentation, which is particularly critical when you have teams of people scattered around the world creating your documentation set.. The alternative to a non-standards driven production cycle is to have multiple people, each writing his or her own product narrative sequentially. The resulting documents will lack consistency and be completely ineffective in terms of meeting the end-users needs for accurate and useful information.

Clearly, collaboration is a core factor of technical documentation life. While manufacturers know this, the question remains, how efficient are they at collaborating? A lot of companies are stuck in a sequential documentation process. One person works on his section and then forwards it to the next person, who works on her section, and so on through completion.

But that sequential approach doesn’t work. It’s slow, cumbersome, expensive, and ineffective. Instead, consider a 12-chapter manual with each chapter focused on a different aspect of the product. In a large company, each chapter should be assigned to a specialist on that particular chapter topic. All 12 chapters, then, should be assembled at once, simultaneously. And as it’s being written, the content of those chapters should also be translated simultaneously. After all, any Forbes Global 2000 manufacturer will require documentation in multiple languages. And while translation adds a whole other aspect to collaboration, it reinforces the main point: collaboration is a core feature of technical documentation.

The systems to put this type of collaboration work flow are widely available, and yet are relatively under-used, particularly considering that most of the companies that really need them could easily afford them. So what is the problem?  To be blunt, it’s mostly ignorance. The people in the production cycle are under a lot of pressure to get product out the door and rarely have time to look up and see the broader picture. The people who are higher up in the organization and actually have strategic responsibility are always focused on the core business of the company (the product), with most being vaguely aware (if at all) of the critical nature that documentation plays in the overall product offering. The bottom line for these execs is, you can’t ship the product without the documentation, if the documentation is inaccurate you have substantial liability issues, and the technology to address all of this is in place. Not only will you reduce your legal risk, your product goes out the door faster, your production costs go down, your organization starts operating far more efficiently, and most impotently, your customer satisfaction levels go up.