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.

As you may or may not have noticed, a common theme to my ramblings is planning...knowing what you want...understanding what you are wanting to achieve. You don't just get in a car and start driving, hoping that you get to your destination! You plan it out to ensure you get there in a timely fashion. This article looks at the content of a document or template and how it applies to document assembly to achieve what we want.

Ask any programmer of any stripe: its difficult to program when you don't have an end goal in mind. If you don't have something you wish to achieve, you are lost. So what we need here is an aim - define what (I think) a document assembly project should hope to achieve. There are two main aims really. And I will address them separately as "Basic Document Assembly" and "Advanced Document Assembly".

We are almost done, but there is one thing we haven't done - communicate with the people who matter most! All too often, software is developed without real user input. The result is an application that appears to some users to be poorly thought out, "clunky", or contains a whole host of features that many users think "this is nice, but it could be so much nicer". Don't let that happen to your document assembly system - get as much information as possible from the people who matter most - the people who use it and therefore, represent the profit of the system.

The goal here is to create a master template for each and every precedent which contains all the optional language and content that may appear in that precedent document. This is the point where you should start renaming precedents and documents so that they automatically group themselves according to topic, use and/or order in which they are used. The naming schema (for now) needs to visually distinguish between a master template that contains all the language for the document and the "documents" that relate to the master. For example, lets say we have a letter to the client confirming instructions.

So far, we have looked at:

• A different approach to developing – plan and design fully before programming
• The pros and cons of single & shared component files
• Getting our project space set up with appropriate sub folders and documents
• Why Excel is an excellent tool for planning document assembly
• Variable and dialog naming structures
• Ensuring we have the raw materials to design a complete document assembly system, covering as many variations of our day to day templates as possible
• "Preparing" or indexing and ordering said raw material so that we can work with them efficiently

It is now time to start the document assembly process. Everything up to this point has been preparation. We have assembled all the raw precedents and documents (raw content) that we will now forge into a document assembly system.

We currently have a list of templates to code. Most templates have one or more variation documents associated with it. Here, we go through the process of incorporating the variations into the master template. To do this, we need to identify what variation the document has, and marking those differences in the master template. In each instance, we have to mark under what circumstances the variation appears, and also the actual content of what appears.

After quite a bit of effort, we should now have a tracking document or blueprint that lists "close" to every variable and condition we are going to need to produce our document assembly system. I have created a dummy excel file (2002 format) which is an extract from a system I built quite some time ago. You can download this file here. Please be sure to save this to your computer, rather than opening it inside your browser.

This post deals with how to quickly (but manually) create a component file from our spreadsheet.

The hard part is over. In fact, the hard part was probably over quite some time ago...but lets get moving on.

From here, it is simply a case of programming each template in your system. If you were to pick up document #1 and start coding, this would be the bulk (or the only) work you have to do. Under this planning approach I have outlined, this is clerical. You are opening each template, and simply filling in the variables, which are clearly marked from your mark-up process.

There is no individual part of document assembly that is rocket science. It is simply a case of making a list of everything your system will need, coming up with a naming schema for it, applying the naming schema and programming your documents. It is akin to being beaten to death with feathers - it takes a long time and its a lot of soft punches, but its doable. Unlike being beaten to death, there are large profits to be realised, so long as the planning and targeting of your development was done well.