27 Tips for a Successful Document Assembly Project

By James A. Eidelman
and Christopher Maeso

(c) James A. Eidelman
Eidelman Associates
317 S. Division, Suite 187
Ann Arbor, MI  48104
734-769-1500
eidelman@lawtech.com

Reprinted from Law Office Computing, June/July 1996 and Law Practice Management, Sept. 1996

A computer program that can draft complex legal documents in minutes is the "Holy Grail" of many lawyers who handle business transactions. After all, those with document assembly systems can reap the benefits of higher effective hourly rates, faster turnaround time to clients, and consistency and quality in all their documents. Successful document assembly systems allow attorneys to focus on the creative, personal and fun parts of practicing law, letting the computer do the cutting and pasting.

Unfortunately, stories about failed document assembly projects are legendary, and anyone who has tried developing a system has learned too many lessons the hard way. The development of document assembly systems can become a black hole. When the system finally gets finished, if it is not flexible and user friendly, it will fall into disuse as the law and needs of the firm change or as the people who developed the system move on to other projects.

The following tips are based on hard lessons learned, and if followed, they should lead to the successful completion and implementation of a maintainable system that attorneys and staff rely on and use profitably. Whether you use Word, WordPerfect, or Word Pro, and whether you use WinDraft, HotDocs, Scrivener, PowerTXT, General Counsel, ExperText, or Workform, these general principles will help.

Managing the Project

1. Get Everyone Involved: If you practice in a group, make sure that everyone feels that the system is partly theirs as it is developed. (But don't let a committee bog the project down too much, either.) Involve the group in testing and improving the system as you proceed. If you are the sole attorney developing it, and it is viewed as your system, it will be hard to get others to use it -- no matter how good it is.
2. Start Small and Grow Slowly: Get a small system drafting simple and often-used documents like powers of attorney, simple wills and client opinion letters up and running first. Establish the concept of the system, test your approach and use it on a real client project.
3. Develop the System While You Do Billable Work: If you refuse to implement the system until it is 100 percent complete, you run serious risk of failure. Waiting until the system does everything you (and your committee) think will be needed to "do it right" will lead to a project that will never be finished. Instead, add variables, text and logic with real clients in mind as you go along, each time testing the system so it correctly creates first drafts of client-ready documents. In several months you will have painlessly created a working system that meets your needs most of the time.
4. Sustain Your Efforts: It is much easier to complete a system or one of its components if you apply a sustained effort. This greatly reduces the amount of time you spend relearning how your system works. Block off development time and don't allow yourself to be interrupted.
5. Finish One Document at a Time: Complete one document before moving on. This way you know that all documents are correct, and you and your partners can see the project progressing.
6. Appoint a System Manager: Make sure there is a lawyer who takes full responsibility for the legal accuracy of the system. It is this person's responsibility to make sure that the system is kept up-to-date. In the three-ring binder you'll use to manage your system (see Tip 21), have that attorney update each section as the law changes. This way, anyone can see whether the last changes to the system include recent changes in the law. It also takes a responsible attorney to coordinate the management and use of the system in the firm. This is often necessary in ways that a paralegal, secretary, or MIS staff simply can not do.
7. Don't Try to Integrate With a Database...At Least at First: Trying to work on a database at the same time you set up a document assembly system is like running a marathon with a young child clamped to your leg -- you won't cover much ground. It is very difficult to know how to define the variables for the database until the document system is complete. Also, because the law is always changing, law practice systems must be remarkably flexible. Database integration can hinder this flexibility. Don't try it unless you want to change your career from practicing law to computer programming. (There are exceptions, such as looking up limited data in an existing firm database, developing commercial applications with a professional programmer, integrating relatively simple documents with an existing case management database, etc.).

Choosing Software

8. Pick a Word Processing-Based System…: Pick a program that works with your word processor. This prevents you from having to learn new function keys and eliminates wasted time importing, exporting, and dealing with differences between the way the document assembly software works and how your word processor works. A word-processing add-in is much easier to learn and maintain. More importantly, it lets attorneys divide the task of developing a system by letting the lawyer do the lawyering while a secretary does the formatting and non-substantive editing.
9. …With an Open File Structure…: If your whole system is in one giant file, it is virtually impossible to use a team approach. You will often want to have one lawyer work on a section of a loan agreement. With a system based on word processing documents, this is easy. You can cut, paste, e-mail and redline text to your heart's content. Some non-word-processing based systems won't support coordination of separate efforts.
10. …And Good Balance of Power and Approach…: Some packages use IF ... THEN logic to program rules into a document. Others offer a lawyer-friendly way to browse through paragraphs and select the ones you want. To many, this is a religious issue between absolute good and absolute evil. The truth is that they are different tools, one a hammer and one a saw. Each lawyer will have a different preference, and each tool has advantages in different practice areas and firms.

At their best, systems that utilize IF ... THEN rules are more challenging to create and maintain, but they are worth the trouble. These systems save not just secretary time, but also lawyer time. The law is full of rules. By using systems that let you program the rules, you can, in a small way, teach the computer to think like a lawyer.

For example:

1. "IF a beneficiary is a trustee, THEN put in language restricting the trustee's powers."
2. "IF the amount in controversy exceeds $50,000, then there is federal jurisdiction"

Systems that let you put the IF ... THEN rules right in the text are better than those that hide them from you. While actually seeing the logic takes a little getting used to, it makes the documents "auditable," so that you can make sure the rules are being applied correctly.

Note that the key to the success of an IF ... THEN system lies in how well the rules are stated. Use language that lawyers who are not programmers can understand. For example, a lawyer can easily comprehend a programming statement like "IF plaintiff has children" or "IF there is diversity of citizenship," but will find cryptic or awkwardly drafted logic hard to follow.

11. Ignore Macros and Merge Programs: Systems based on WordBASIC, field programming or the WordPerfect macro language are either too difficult for the average lawyer to understand or too limited in power. (It's a shame that word processors don't have the basic document assembly features of the old WordStar Mailmerge or Dictaphone.) Most document assembly packages combine the power you need with ease of use for mere mortals. You can get great looking macro-based systems up and running, but as the law and staff change, the firm can't maintain them. Also, as the word processors change versions, you may find yourself with an obsolete program. Just ask anyone who programmed on a system in WordPerfect 4.2, then 5.0, then 5.1, then 6.1...

Programming Techniques

12. Test As You Work: As you add data elements, logic and language test your system every few minutes. Debugging is a part of any project, and it is much easier if you test as you go along.
13. Use descriptive Variable Names: It is easier to understand "I, [Grantor Name], a resident of [Grantor County], [Grantor State]" than I, [Gr], a resident of [Gcty], [ST]."
14. Take Advantage of Your Program's Internal Comments Feature: Most systems let you embed annotations, comments or notes. Use these to leave an audit trail, explaining both your legal and programming logic for yourself and those who will follow.
15. Use Word/WordPerfect Fields Liberally: If you use Word or WordPerfect fields to handle changing terminology like "he/she," his/her," "testator/testatrix," "will/trust," "plaintiff/defendant," etc., the documents become much easier to read. With Word, you can use Tools, Options to show these fields shaded with gray and with the variable fields showing or not. That makes it much easier for a partner reviewing the forms or editing the model documents on screen to concentrate on the logic and the language. "To him in his discretion" is far more lawyer-friendly than "to [Trustee Him or Her] in [Trustee His or Her] discretion."
16. Hide Complexity in Subroutines: There is no way around some complex programming. When we have to do seriously complex programming in our documents, we move it to subroutines or rules files that contain "the ugly stuff." This way, attorneys who are working with the systems don't have to be distracted by the programming. This includes "IF statements" to insert signature lines, and the like. If there are 10 places in a document where the same logic causes alternative text to be inserted, you can put that logic in a subroutine and either call the subroutine from each of the 10 places or have the subroutines set a variable and insert the variable in each place. Whether each subroutines are called rules files, computations elements, or simply included documents, most document assembly engines have some way of accomplishing this result.
17. Color-Code Your Commands: Use color and different fonts for commands, and use different colors for nested logic. We usually use italics and blue text for most programming commands and sometimes use red, green, or magenta to make it easier to read the nested logic. For a simplified example, see Figure 1.
18. Print on a Color Printer: If you use color to set apart programming commands get a color printer. The attorneys will appreciate reading hard copies of documents that have the programming commands in color as much as the author will appreciate working with color on the screen.
19. Redline Your Documents: Use redlining tools early and often to compare: (a) different client documents to spot special clauses that have been used under different fact patterns, (b) versions of your "programmed" model documents, and (c) documents that the system has drafted. Both WordPerfect and Word have excellent tools to compare different versions of documents, and DocuComp and CompareRite are even better. Using these redlining features will help you catch errors, improve logic and capture custom changes you've made for clients.

Staffing

20. Use the Team Approach: Don't have your lawyers doing secretarial work, and don't have your secretaries doing legal work. The team approach works and is the only way to have a successful implementation. Use other lawyers and support staff to help do the parts you aren't good at and test the system with different sets of data.

Documentation

21. Put the System in a Three-Ring Binder: When you start the project, create a binder with plenty of dividers and keep it up-to-date with printouts of data, data entry screens, model documents, rules files, INI files and any other components of your system. Tuck an extra floppy disk with all of the system files in the binder, and keep an extra copy of both off-site in case of fire or other risk.
22. Create a Good User Manual with Screen Shots: Make this the job of a secretary or paralegal, except for editing any lawyer-to-lawyer instructions of documentation. Also, as there are changes in the law, put references to the law or copies of cases or statutes in the back of the binder.
23. Keep Your Binder and Manual Current: Tips 21 and 22 won't make any difference if you don't keep the information up-to-date.
24. Use the Online Help Features: If a CLE course outline or article contains practical advice on selecting clauses, or if a partner wants to give instructions to associates, this is a great way to make the advice available to the right people at the right time. Although some fear that document automation systems rob young associates of the learning experience of creating complex documents "from whole cloth," a well-organized checklist with online advice about the issues can be an outstanding educational tool.

Maintaining the System

25. Keep the System Up-To-Date: Each part of the system should have internal programming notes at the beginning describing the content, date and author of the latest changes. The three-ring binder containing printouts should be initialed and dated by the lawyer who is the system manager. The system manager must track changes in the law and take responsibility for the system being legally correct. Just like the law and the firm, the system is never done and is always changing. If you don't maintain the system, it will become brittle and people will stop using it.

The Bottom Line

26. Don't charge by the Hour: Spending money and time to create a system that lets you do more work in less time is well worth it if you can charge on a flat rate for results. It's counterproductive if you are going to charge by the actual time spent. Change your retainer agreements so that you are doing it in an ethical way, charging for your documents, advice and results -- not hours.
27. Make the Capital Investment: Business people understand the importance of capital investment. The airline with the newest fleet of planes is the most profitable, while the airline with the oldest enters bankruptcy. Hardware and software costs are only a small part of your operating budget, but the investment of your time and effort can produce an effective practice system that can help launch your firm to the top.

Rules to Remember

Hoffstadter's First Law Of Programming:
"Every programming project takes much longer to complete than you think it will, even after you have taken into account Hoffstadter's First Law of Programming.
--Douglas Hoffstadter, one of the "fathers" of computer science

Brian Howard's Law of Computing:
"You can get it quick. You can get it cheap. You can get it working. You can combine any two of these at the same time, but not all three." --Brian Howard, Computer hacker and friend of the author

The 80/20 Rule:
"You get 80 percent of your results from 20 percent of your efforts, and 20 percent of your results from 80 percent of your efforts. Applied to document assembly, 20 percent of the forms and clauses will be used 80 percent of the time. Make your Phase I a system that will automate that 20 percent, and let the rest be done the old fashioned way." --Adapted Pareto Rule, from 1920s economist Pareto

Pournelle's Rule:
"Better is the enemy of good enough." --Jerry Pournelle, Byte columnist and science fiction writer

Eidelman's Law:
"It always seems 90 percent done." --Jim Eidelman, legal technology consultant and author of article

CHRIS MAESO is a Michigan attorney specializing in corporate law and the development of expert systems. He can be reached over the Internet at cmaeso@milaw.com.

Updated ideas: 

InfoWorld, How to get users involved.  Article:  http://www.infoworld.com/cgi-bin/displayNew.pl?/lewis/990315rl.htm , Forum:  http://forums.infoworld.com/threads/get.cgi?102329