[Originally appeared 2001.]
After a pause of several weeks, thanks to several writers for serious and thoughtful responses to my questions about success in teaching and using templates with a strong style orientation. Your reports confirm that organizations that take the time to develop and promote such standards gain much. As Office XP becomes available, we can review strategies for templates and styles in the light of new the formatting features and viewing options available in that upgrade.
For now and the next several columns, we will explore the strategies, tools and methods for document assembly. This column will cover definitions, identify the questions to be covered and describe the basic capabilities needed to support document assembly.
This discussion will focus on standardizing the content of documents and automating the tasks of creating individual documents based on standardized text. In many of the Word of Law columns, the role of Microsoft Word templates has been featured. The columns have highlighted formatting and other features of templates that can control the Word environment, such as keystroke assignments. Templates of course, can contain text. With the power of macros and other features of Microsoft Word, such as fields, it should be possible to automate the creation of new documents with standardized text. That goal has been “obvious” since word processing arose in the late 1970’s and early 1980’s, yet its achievement remains elusive.
Although the tools matter, the challenge and solutions to document assembly remain primarily in the people – the skills, staffing, responsibility, authority and time investment necessary to the success of a document assembly project. Often we have seen in legal practice, as well as other professions, the assignment of document assembly projects only to information technology staff. These projects fail. Document assembly needs (some) programming knowledge. Document assembly requires (much) content knowledge.
We begin by restating a definition for document assembly. Document assembly means the automated creation of documents or portions of documents using standardized text, including the insertion of data into the text and the selection of applicable text based on responses to questions or other pre-defined rules.
To take stock of the current state of document assembly, we need to address at least the following questions.
1. What functions in Microsoft Word and supporting programsare required to support document assembly?
2. For what types of documents does the effort to preparedocument assembly have the highest payoff?
3. What responsibilities must be staffed and what methodsmust be employed to succeed in a document assembly project?
4. How well do Microsoft Word and VBA support theprogrammatic requirements for document assembly?
5. What help is offered by third party programs?
6. Where does the Web fit in?
7. What’s next for document assembly?
The rest of this column covers the first question. Document assembly requires the insertion of data into standardized text. It should be no surprise that the characteristics of the data that may be inserted into documents in document assembly resemble those of databases. The data should be classified into various types, many of which have characteristics similar to the data types in a program such as Microsoft Access. They include text, number, date, currency, yes/no or true/false and multiple choice. Data may be unlimited in content or format, or may be limited to specified choices of content and formatting. Data may be derived from other data in accordance with programmed logical or computation rules.
The document assembly tool should enable an item of information to appear in different places in a document in different formats. A date, for instance, should be entered once, but able to appear as March 20, 2001 or 3/20/2001 or the twentieth day of March 2001.
Document assembly must support conditional inclusion of text based on logical rules. Blocks of text, including insertion of standardized text shared among several documents, should be included or excluded based on the answers to true/false or other logical questions, or the values of data.
The data and rules for selection of text or provisions for document assembly should be able to be derived from several sources. It may be obtained from user input during the assembly process, from one or more dialogs. It may be obtained from answers to such user input dialogs in a prior instance of the assembly process saved separately from the document. It may be obtained from one or more databases. It may be obtained by calculation from other data, including logical values. For instance, if the assembler of a standard contract form chooses a renewal option for annual renewals unless cancelled on 90 days notice prior to the anniversary of the contract, the dates for renewal notices could be inserted automatically based on the effective date of the contract. It should be possible to mix and match these data sources.
Finally, the results of the document assembly, in most instances, need to be an editable document. For the purposes of this column, that means a document in Microsoft Word. In many instances, the “programming” of document assembly does not or can not resolve all issues required to prepare a draft of a document. The assembly process must be able to leave the assembler able to complete the drafting. An open question is whether the document that results from assembly can be reassembled. Although there are instances where this capability has been supported by document assembly solutions, it is uncommon.
This 2001 article originally appeared in Office Watch.Subscribe to Office Watch free at http://www.office-watch.com/.