The information sources are the items at the top of the flowchart. You can further refine this information by specifying who is responsible for each step in the process and when responsibility is handed off from one group to another. For example, in some organizations, engineers write content drafts and give those drafts to the technical publications group so that they can “make it pretty.” In other organizations, technical communicators write content independently with minimal input from the engineering team. Some organizations use a hybrid approach: perhaps the technical communicators write user documentation and the engineers write systems documentation. It is important to understand how information flow is currently working and where the problem areas lie.
Reviews are a common source of frustration. According to the authors, reviewers are lazy delinquents who give content only a cursory glance but try to prove that they did read the information by nitpicking the comma usage, usually incorrectly. According to the reviewers, authors tend to inundate them with 300-page documents, due back in two days, and delivered with no advance notice exactly at the busiest point in the release cycle. Both parties complain about inefficient, annoying processes for marking up documents with comments (reviewers) and integrating comments into the source content (authors).
The distinction between technical content and information products is not always present. In many web-based tools, for example, content is stored in its final form. In most publishing workflows, however, there is a transition between a source content format (maybe XML) and a delivery content format (HTML or PDF).
As you examine the information flow, the goal is to identify bottlenecks and inefficiencies so that a new process can improve upon the current workflow. For example, one common recommendation is to eliminate any content duplication via copy-and-paste and instead carefully manage reusable information. Speeding up the update process so that published information products are current is a priority for many organizations. And often, the integration of a localization workflow into a previously monolingual process is a challenge.
Other considerations may include existing tools, skills, and corporate culture. There’s a big difference between Microsoft Word and wiki authoring. Staff who have lots of experience with print production may find a transition to automated document creation annoying—they like having the ability to tweak page breaks. If your corporate culture glorifies last-minute heroics rather than careful planning, you cannot implement a workflow that requires multiple formal signatures on reviews. (By contrast, if you are in a regulated industry, it is unlikely that you can avoid formal review and approval cycles.)
The analysis goal is to develop a solution that:
- Streamlines the flow of information throughout the organization
- Supports efficient content creation and delivery (which reduces costs)
- Maintains or improves the quality of the information delivered to customers
- Provides an authoring environment that is appropriate for content creators