Mark Baker
Director, Communications, OmniMark Technologies

Often, one of the overlooked consequences of moving to single sourcing is the change it implies in the way the work of a documentation group is organized. A typical documentation group (at least in my experience) is organized to undertake a series of projects. Each project is essentially independent of every other, independently funded, and independently staffed. A documentation group is a pool of resources from which project leaders and project staff are drawn as needed.

Most documentation groups have ongoing responsibility for a product line or a set of product lines. They maintain libraries of documentation from previous versions, which they draw on as a starting point for new documentation projects when a new version of a product is being created. The care and maintenance of this library is important to the group, but it is not the group’s main concern. Work is not organized around the maintenance of the library. Work is organized around individual documentation projects.

In a single-sourcing environment, however, the material that goes into an individual document is drawn, in whole or in part, from a shared collection of information components: the “single source” from which all documentation is built. This changes, or should change, the focus of the group’s activities. All individual projects now draw from the single source. All new material that is created goes into the single source. (If it doesn’t, the source ceases to be single and the system breaks down.) The group must now be organized to exercise permanent stewardship of this central resource. Projects to create particular documentation sets from this resource are secondary, and they call on services provided by the central repository. Work must now be organized around the maintenance of the single source.

The switch from project-oriented organization and planning to ongoing resource maintenance can be hard to accomplish, especially if you don’t anticipate it. However, making the switch is essential to the long-term success of the single-sourcing system. Often, getting out an individual project, or meeting nice-to-have requirements for an individual documentation set, can most easily be achieved by breaking the single-sourcing rules. It will be easy to do, and the immediate consequences will be minimal. If the writers and editors have not internalized that the maintenance of the single source is the primary task of the group, breaking the rules will happen over and over again.

The consequence of breaking the rules is that the single-sourcing system begins to break down. Exceptions accumulate and sources begin to diverge. After a while, the single-sourcing process no longer works or requires so much manual intervention that it ceases to deliver any cost or time savings.

If you are embarking on a single-sourcing project, therefore, make sure that everyone involved, from managers to writers, editors, and designers, understand that the work of the group will now center on the care and maintenance of the single-source system. Also, make sure that product management understands and buys into this idea. Make sure that they understand the consequences of single sourcing when they create their requirements. Also, ensure that they understand what the central responsibility of the group now is, and that they are willing to fund the group accordingly.