|
Most of document assembly projects I have worked on follow a similar breakdown of time expenditure:
- 60% consulting, designing, mapping, planning and tracking
- 20% actually programming documents in the document assembly platform
- 20% beta-testing documents and supply
Following this pattern works - where everything I do is planned and designed ahead of time. Under this scenario coding does not commence until the entire system has been planned. Yes, nearly every variable and dialog is designed ahead of time. This exhaustive planning is the fastest and most efficient way I've found to build document assembly systems. It seems slow at first glance, until you realise that it saves so much time in the ongoing progress of a project. It saves even more time when it comes time to maintain a system you built. And more time still when you pick up a project for the first time in a year or two.
Imagine being able to sit down for 1hr at the start of each day and plan how everything is going to work out for you. Imagine you can 'plan away' all the interruptions, the proofreading of documentation, changes to instructions require no revision of existing work and at the end of it, you have a complete 'bible' of your entire day that can be sorted, filtered and used as a reference tool for that day. That's how I work every single day.
The most common approach doesn't work effectively...
Many times, a document assembly developer is given a stack of precedent documents that form the majority of documents for a given area of law. They will then dutifully carry out the project, something like this:
- review the documents and order them roughly according to the order in which the documents are needed on a file
- create an index of the documents and perhaps rename them according to some naming schema for later reference
- convert the precedent documents into templates (from .wpd to .wpt or from .doc to .rtf or .dot)
- create a library in the chosen document assembly platform including all the templates
- fire up the first template in the list and start coding
When I first commenced programming document assembly systems, this was also my approach - over 7 years ago. I have learned (the hard way) one very solid and useful lesson over the last 5 years - this approach does not usually work. It can work, if the developer is a professional or semi-professional in the area of law they are programming and know the documents and processes inside out. However, most times, it simply doesn't work.
WHY Doesn't It Work?
- A dialog you have designed and scripted that works for the first x number of templates may not be suitable for the entire system and may need to be re-built from the ground up later on. This will also affect any computations or scripts that rely on that dialog
- Grouping of variables by purpose is critical to a good system, and these groupings may not be apparent until you have reviewed a majority of the templates in a system. A bit of information such as "Have we received money in trust for stamp duty?" looks like its only in a single template, but actually appears about 4 times over (at least!)
- Smart interviews involve guiding the user through a series of screens that they need to fill out, without showing "extra" screens that don't need to be filled. It is difficult to program these interviews until all templates have been reviewed and analysed
- If you are dealing with creating automatic lists for quick population of data, or re-using entity data or any sort of dynamic data movement/creation on the fly, it is far easier to implement once you are certain that you know all the ways in which this data must be copied/pasted/moved around. This type of code is often complex and re-working it is not the brightest idea...
- The chance for misnaming (and creating new) variables is huge - your users will be stuck re-entering data and wondering why. Also this will affect any computations that rely on these variables - your data integrity will be lowered
- The instructions you have at the start of the project will change. More documents surface, you ask questions on content which result in more content to be coded, clients change their minds and a myriad of other factors. Plan and design finds all of these 'landmines' (go 'boom' when you step on them) before you have actually produced code to handle the outcomes. Measure twice and cut once!
- Several documents quite often share a common theme - 'the 3 subpoenas' for example - appearance, documentation and appearance with documentation. Once you have gone through all three of them, you realise it is one dialog with a few different options
HotDocs Specific
Single Component File Specific Problems
- Getting rid of duplicate components is problematic and time consuming
- Encountering a situation that requires a prompt change on a variable near the end of your templates will lose you a lot of time when backtracking to find where it should be updated
- Re-using dialogs across component files can be a recipe for disaster and corruption - all it takes is Dialog A to be a repeat in one template, then Dialog A is re-used as a flat dialog in another component file
- It is easy for manual counters/indexes/increment variables to be set or reset unfavourably
Shared Component File Specific Problems
- Get halfway through your system and realize that one or more dialogs are just "too big" and need to be re-drafted (and hence, template re-draft also)
- Use of manual counters/indexes/increment variables in more than one place, resulting in bad counts/indexes etc...
This is not an exhaustive list by any means. The reason WHY this the "common approach" doesn't work can be summed up on one sentence:
You will have begun programming before you are aware of everything your system needs to produce which means you will almost certainly have to re-visit, re-tweak, re-develop and re-test code.
So what DOES work?
These pages are designed to cover smart document assembly development from start to finish. We will use HotDocs commands and examples, as this is the more common development platform in Australia however, the concepts (but not the exact commands and syntax) discussed will apply to almost every document assembly platform we have worked with. A quick list looks something like:
- Prepare a directory devoted to your project, create appropriate directories to categorize the files we'll be working with
- Get a list of precedents that the project will include
- Get finalized document versions of those same precedents
- Prepare a master template for each precedent that will include all the variations from the finalized documents
- Get input! Speak with your professional staff and ask them about passages they continually draft over and over - store these variations & requests up and program them later if appropriate
- Get more input - this time, from the staff who will USE your system - paralegals, secretaries, support staff - they will have private stashes of precedents, lists they lookup that could be programmed and the like
- Settle on a naming schema for your dialogs & variables
If there are any conflicts in legal content, or you are unsure whether something is appropriate for inclusion, get it confirmed by a relevant authority! You aren't building your system or what you think is "right", you are building a system that embodies what everyone else in that area of practice wants!
- Start building your system in Excel (or other database, table or other tracking mechanism)
- Review your tracking document, check for duplicates & omissions, look for "gaps" where you may have missed an issue that needs to be addressed
- Program your templates, test and finalize
Interesting Note
This may or may not be suitable for you, or may not be permitted by your firm. Consider a second (or third!) monitor for your computer, the same size & resolution as your existing screen (best case scenario: same model). To do this, you may need to purchase a graphics card for your system that has both a digital & analogue output (or two digital outputs), giving you two monitor ports to plug into. In terms of an office computer, your total cost is probably going to be around the $150-$300 mark. If your primary job is document assembly, or IT type pursuits, your firm will get that investment back inside a month or two, in the form of a more productive staff member.
What the hell....?
You will never know what you are missing out on, or where you are being inefficient until you have had a taste of someone else's approach. Personally, I use 3 x 20 inch LCD monitors. For me, all I care about is screen space. Seth Rowland utilizes 4 x 20 inch flat panels - screen space is a big concern of his (I think Seth is crazy on this one!).
Having two screens allows a developer to view multiple windows at once. I could not calculate the time saving over the duration of a week simply because I have three monitors. Even when I had two monitors it was pretty awesome. This is not about online games, ego, or "an impressive looking set up". Its all about being able to:
- look at my HotDocs library, my excel tracking spreadsheet and my MSWord template all at the same time.
- copy from an application on monitor #1 to monitor #2 without minimizing & maximizing windows.
- look at two documents side by side to compare styling, content or whatever else I need to look at.
- take a document in WordPerfect, copy it into Notepad to remove formatting, then copy it into MSWord and style, all the time still looking at the original document.
- maximise my efficiency and time spent in "my workplace". For me, that's on my screens.
For those of you who may be thinking that I could just increase my screen resolution to achieve more screen space, I already run at 1600x1200 on all three monitors. Perhaps excessive for many people, but I use two screens 100% of the time and all three screens more than 80% of the time. |
