Contract Life Cycle--document assembly is just one part of the puzzle

I was an early adopter of automated drafting. Back in 1988, with an IBM 8088, 64K memory and Borland's first C compiler, I wrote basic document assembly and client management software. They were not the most user-friendly applications. They did not need to be. I was the sole user. However, the software radically changed my practice and career.

More than 20 years later, the technology of automated drafting is both powerful and easy to use. But it has yet to be broadly adopted as I naively anticipated those many years ago.

I now realize that unless the entire contract life cycle is automated—not just the drafting bit—then automated drafting can be expensive, limited in utility and potentially unsustainable.

The complete life cycle has four main elements, which when systematized, creates a virtuous feedback loop.

1. Production

The first element in the life cycle is a means to efficiently produce documents. Over the years, drafting has changed little. We can start with a blank page (very inefficient and very rare), a document assembly system (very efficient, but rare), a model form (efficient, but infrequent), or the last closest document (inefficient and very common). Why is repurposing the last draft inefficient? Unless, you are drafting a particular type of document daily, you have to read through all its terms and adapt them to current needs. Moreover, any drafting improvements are captured in a particular document, which may or may not form the basis of the next draft project.

2. Automation

The precursor to efficient drafting is some means to organize the material. Typically, this consists of a checklist (or outline) and a clause library. The first time I tackled a large scale automation project, I did it manually. I asked the lawyers in an estate planning group to give me copies of their forms and exemplar documents. When printed out, the stack of documents was about 2 feet high. I might have used less, but that would have risked missing important variations.

My approach was to find the fattest document (on the grounds that it likely contained the most number of clauses) and then list each of its clauses in a database. I then went serially through the pile and for each document added clauses to the database that I had not seen before. By the end of the process, I had a list of 250 unique clauses for Testamentary Wills and 350 unique clauses for Trusts. With this clause library, the system could construct any Will or Trust. The next step was to find the range of language for each clause. As you can imagine, the approach—while thorough—was very time consuming, taking about 3 months for each document type.

3, of course, months is far too much time. A set of 20 documents would take 5 years to automate. It is therefore not surprising that such efforts have been limited to those practice areas that frequently use a small number of documents, or have need for less complex forms. In order to reduce the time, and costs, there are two approaches: (a) reduce the number of input documents, or (b) automate the process of creating the document outlines and clause libraries. I have taken the later approach. (See, Empirical Analysis: What's Market?)

3. Review

The third element of the contract life cycle is document review. This process is typically more formalized in corporate legal departments compared to law firms. Frequently legal departments will have different levels of review depending on the nature of the transaction and its contract value.

This element of the contract life cycle is, however, absent from document assembly systems, significantly limiting their utility. Indeed, for all the money spent on developing document automation systems, they only assist the lawyer when she or he is tasked with creating a first draft. They cannot help with the more common task of reviewing a document.

While other professions, notably airline pilots and physicians, have widely adopted the use of checklists, lawyers rely on their experience, skill and recall to ensure that transactional documents capture the business needs of the deal. As with other elements of the life cycle, absent of some form of automation, the cost of creating and maintaining deal checklist is likely cost prohibitive.

4. Audit

The final stage of the life cycle addresses to need to monitor usage of the precedent systems. Again, audit systems are typically lacking in most document assembly solutions. As a result, they lack a means to efficiently maintain their collections. The challenge has always been that the templates are constructed in the assembly system, but edited in a Word processor, where such changes cannot be easily or automatically picked up by the assembly software. Over time, the edited documents get "out-of-sync" with the assembly systems and at some point the drafting templates have to be re-created. Again, lacking an automated system, such maintenance can be just as expensive as the initial cost of creating the assembly system.

5. Conclusion

If we do consider the entire life cycle: (a) setup costs can be reduced by automating template creation, (b) utility can be added by providing a means to review contracts, and (c) the system can be maintained through a process of continuous improvement by feeding new documents back into the system.