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.

This is a crucial question that will have lasting ramifications for YOU, the developer. If you are a subscriber to the HotDocs ListServe, you will likely have seen the arguments on this very topic before. I have worked with, and created systems using both approaches. If given the option in my client works, I will almost invariably use shared component files, due to ease of maintenance. With the blueprint I create prior to programming, it reduces maintenance times to almost NIL - it is one or two changes.

The arguments for and against single/shared component files generally come down to this:

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.

Utilising Excel for developing document assembly systems is a crucial part of my approach. If deprived of it, I most certainly would take far longer to build the systems I do. Here are the reasons I love Excel so much and rely on it absolutely for every project:

Before we can build a nice, consistent system, we need to know how to impose order and consistency from the ground up. The core of HotDocs is the humble variable, but dialogs are where we need to start our naming schema. Getting variables and dialogs "right" is the core of getting document assembly (and particularly HotDocs) "right". HotDocs contains a component manager which allows developers to view all the individual components of a system - so lets work with that.

Naming a variable may be the "ground level" method in which to create order in a document assembly (or any programming) system. However, in terms of HotDocs, dialog naming is where it starts. The reason for this is that variables (in HotDocs) are separate and distinct containers for information. For the most part, a variable generally appears on a single dialog. Also in most cases, dialog will contain all variables that relate to a single "area" within a system - its common sense to put all variables relating to the Court on a single page where possible. This is referred to as "variable grouping".

So where does all these naming structures and schemas actually HELP a developer? They help in that whenever you look at your component file manager, everything is laid out alphabetically. If your naming schema has been consistent, it would automatically group all related variables together. I'm putting some materials together to provide an interactive example however, in the interim - here's how it helps a developer. Using this system and approach, here's some things I can do/get/report/produce in seconds - imagine trying to do them with the way you currently develop: