Whenever I am handed a document assembly project to complete, I follow a rather fixed set of steps. This process is a means of quality control but just as importantly, its the most efficient way I have found to complete projects. Like most things, a bit of planning up front on how to approach something is more efficient than just jumping in and "starting". Measure twice. Cut once.

The Concept - Planning Document Assembly

When I create a document assembly system, I am looking to design a system that embodies as close to ALL of the decisions and results that an area of practice will have to deal with on a day to day basis. If the client does not wish to invest this heavily in a particular area of practice (and sometimes, it is not wise to do so), then I am at the very least looking to create a system that contains all the relevant documents to that section. Having a single library that contains all the documents a user may need from day to day is what we are after - it just makes sense! Why have a wonderful document assembly platform if you aren't going to use it to its fullest advantage. Or again, at the very least, use it as a central access point for all documents a user may wish to create for each area of practice.

To create a system as outlined above, there is something I (or any developer, whether in house or not) need before I begin: content. More specifically your content. No one can program a quality system for you if they do not have all (or at least a majority of) documents up front before planning or coding commences. Creating systems "piecemeal" results in a system that is also piecemeal - it is patched together with "workaround" bits of code and doesn't run as well as it should. It is not as clear or easily maintainable as it could be, because it was written over time with "bits" being added in all the time. "Garbage in, garbage out" applies. Much like a lawyer needs all the facts before they provide advice, a document assembly developer needs all the documents (or at least most) before programming a system.

Preparing For Work

Before we go about our work and start gearing up for a document assembly project, there are a few things we should do beforehand to prepare. You want to have a place for everything coming in and going out. You want to be able to track everything without having to rely on your memory and lastly, you want to have a document that does some reporting for you so you can pinpoint things that need to be done.

• Create a directory for working with the project. Every time we "get" or "grab" a precedent or client document for reference, we aren't "taking it", we are copying it. We don't want to risk losing important precedent documents, so we make a duplicate of it. It will also give us a single folder to visit that contains everything we need to know about our project - templates, precedents, documents, tracking spreadsheets, correspondence, notes - all in one place.
• Create a tracking document. I favour Excel, but this isn't necessary. You need something that will allow you to view large lists of data and sort them. Ideally, you also should be able to filter them and otherwise use it to analyse works later.

This step is a simple matter if you plan to outsource, as all you really need is a table that lists every template in your desired system, along with annotations as to which finalized documents relate to which template. This is more fully covered in the next article

• If you're developing, separate the data in your Excel columns. File path, file name, extension, notes - these are all columns you may have. Have status columns for things like "coded" or "reviewed" or whatever else you may need to track. This isn't 'just a list' - its going to be a filterable and sortable database that just happens to look like Excel!
• Create sub-directories in your project folder. These may vary from project to project, depending upon various factors (for example, you may have a "database" folder to store reports from a database that you are converting). The directories I customarily use are:

  Analysis: everything related to the project, but not a part of it - such as the tracking document, reports and other such that may be used from time to time

  Backup: For use when deleting/removing files. Instead of deleting from the main project directory, cut & paste it into the backup folder

  Documents: Stores all the documents related to specific templates. A single statement of claim template to be drafted may have 5 (or 50!) different documents that show variations of that template. Rather than clutter up the main directory with documents, they are stored separately.

  Outdated: those documents which are for historical reference only - they are out of date

  Supply: the folder that contains "zip" files of the library at various development stages. It actually forms a complete collection of every version of the library that ever went "live" and as such, may be of benefit to in-house developers, as it will allow you to revert to the library "as at" a given date

  Notes: notes, correspondence, memos - the general "back and forth" between developer and client.

• The main directory itself is where I develop the library - all component, template and library files for the system. If it is not directly in the system to be delivered, it is in a sub-folder.