A good start is collecting all the precedents for an area of practice that you wish to automate. Consider this the "official" list of what needs to go into the system. Copy these precedent documents into your project directory and list them on your tracking document. Once you have them "in your project", check them for currency. Or more accurately, confer with a lawyer or 'group of experts' as to which precedents are out of date. Many times, you will find that some of the precedents in the list are constantly being edited when a document is created, because they are slightly out of date. Throughout this step, you will find that you are culling the poor precedents - delete outdated precedents and move them to the outdated folder.

This is a good start to the process, however, this is only the start. A quick glance at most "precedent lists" quickly shows that this cannot possibly be ALL the documents that are used from day to day. There are inevitably memos, specific purpose drafted letters and documents that aren't on the list. Quite often, they are part of a staff member's "secret stash" who works in that area of law, who has amended the firm's precedents to suit their own style, or their author's style. Other times, they are on the network drive and accessible to all, just not "officially" listed. Either way - be aware that the precedents are rarely going to be a conclusive collection of content to go into your new system - they will be the skeleton at best. So how do we fill this gap?

Get documents and raid staff stashes!

The difference between a precedent and a document is simple: A precedent is the file which is used as a base to create documents from. Since the precedent is rarely going to contain every variation we need to produce a good system, we need DOCUMENTS! Documents are the finalized product that was eventually "used" in the file and are far more likely to contain additional & conditional wording that does not appear in the precedent. So, to fill the gap left by a list of "pure" precedents, we get documents from real files.

Lets backtrack the logic for a second there - a well programmed "document assembly precedent" will contain most or all of the logic that could be used in the resulting document. Since a "standard" precedent wont have all that information, we go to documents, to get optional content which is then programmed into the template. This template is then used over and over again to produce variations of all the conditional content we just put into it. Make sense?

Review and attain copies of 5 - 10 documents for each precedent you have. Sometimes you will notice that the 5-10 finalised client documents you have collected are exactly the same in content as the precedent. This usually means that the precedent is fairly static, and that the content of this precedent is all you need to account for. Other times, you will see that the author has created a document, and modified it to suit a need for that file. These modifications are what we are searching for here - if we wish to provide a system that can handle the majority of the common decisions from day to day, we need to know what the different uses of each document are.

In the cases of highly dynamic content, such as Statements of Claim, Wills, mortgages, leases and the like, you may need to review far more than 5-10 documents. If you wish to build a system that incorporates many of the day to day options of these documents, you will need to keep looking through client versions of these documents until you stop encountering new variations. In these cases, I would recommend speaking with a professional staff member, and getting a list of the major variations they would like programmed. For example, approach your litigation lawyer for a list of the 10-20 most common Statements of Claim, and settling some standards for them. In this scenario, you'd find that you'll need 5 - 10 document versions of each "type" - so 5 or so "goods sold" Statements of Claim.

The key here is liaising with the people who do the work - laweyers, paralegals and secretaries. Find out what the hotspots are going to be - some documents are almost never used - don't spend too much time on their specific variations. Other documents are used multiple times by multiple people daily - these should cater to as many variations as possible, as they will save every staff member time every time, multiple times.