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:

• Create as many tabs on the spreadsheet to track as many different things as necessary. I often have: info, variables, docs, issues, code snippets and scratch pad on my spreadsheets.
• I can sort the rows by any column in the sheet
• Analyse a growing system easier than an MS Word table, yet faster than a database system. I can quickly extend my Excel 'system' to track new data. Say I suddenly needed to rename every single TF variable in the system - I could write an Excel formula to create the new name for me, filter on "variable type = true/false" and do nothing but copy and paste.
• Auto-filter for rows that meet a certain criteria, without needing queries & reports in a database platform such as Access. For example, it is two clicks to look at every true/false or multiple choice variable in a system. Or perhaps a list of every variable on a specific dialog, including variable name, prompt and rules under which that variable appears. Or maybe a list of all documents that have been "coded", but are not yet "tested".
• Copies easily into MSWord, imports into or exports to a database quickly and easily
• With a bit of working, can work with the HotDocs template generation procedure
• Allows extended formula writing for "cool" functions you may wish to add to a system. For example, if you wanted to write a html help page for every dialog in your system, you can do so, and auto-create all your names with a simple CONCATENATE formula. Or perhaps you wanted to write a html file to list & link to every single template in a system - another concatenate formula does it in minutes, instead of manually copying each template name & path

The usages of this approach are endless, but all allow faster development that results in a total blueprint for the client later. It also provides a "quick and dirty" data source for anything else you may wish to do later. It also results in a far higher level of quality - design once in excel, then copy and paste - do not re-type data. Ever.

I Don't Like Excel!

Look to items 1-5 in the above list. Any database will serve most of these items. You can achieve some of them with MSWord or other word processor table. If you are so inclined, you could probably set up a quick php website to locally track your development. At the end of the day, it doesn't really matter HOW you track your development, so long as you DO track it. The reason this is critical to the approach I use is because most of the development is done in Excel (or whatever tracking mechanism you use). I develop, plan and structure everything in Excel, then pretty much copy & paste it into HotDocs.

This may seem a lot of work "for document assembly" but trust me on this one: If you are trying to build even a semi-complex system, you'll be glad of this tracking blue print in short order. If you do not plan on doing the document assembly design yourself, you need only a table listing all the precedents and templates you wish programmed, and a separate table for queries, questions and notes for later,

Ok, So Excel is the go. What to do

There are three basic tabs to set up in Excel that will track the core of your project:

• Templates: This will start out as a list of every template in your system, as well as a list of each document that has content for each given template. Eventually it will be a list of every template in the library, the template path, the library title & description, with the document lists removed (because they will have been blended into each template). Each entry will likely have a status column (looked at, reviewed, pseudo code done, coded fully, has issues, is ready, has been tested etc...)
• Variables: This is your system spreadsheet. It will be a list of every variable in the system, and the dialog it belongs to. Each row will be a single variable, listing the dialog it appears on, its name, prompt, list options (if applicable), rules under which it is used (if applicable) and also any notes needed. With a bit of effort, you can copy this sheet into a word document, turn it into a HotDocs template and voila! A complete report of every variable and prompt in the system that you can assemble in HotDocs. Suddenly, you can report on answer files properly, not just with the "HotDocs default" reporting.
• QC Tab: This is a quality control tab, to ensure that every issue that ever arises in the system is dealt with in a timely fashion. It will start out as a list of things you need to do (or get back to), precedents that aren't quite working right, dialogs that look weird or scripts that don't work correctly. Eventually, it will also contain client/user feedback, requests for additional functionality, and new templates to be added.

At all stages of the project - no matter how small the detail, note it on your tracking document! If a document or precedent goes into your working project folder, it gets noted on the tracking document on the Templates tab. You notice the margins are not set according to your QC manual? Note it on the QC sheet to be done (even if you plan to do it right now!). You find an extra document that relates to a precedent? Create an entry for it on the Templates sheet and note which template its going to relate to. Precedent outdated? Mark it as outdated on the documents sheet at the time you move it. It may feel strange at first (it did for me) but it avoids a lot of problems and provides a much better project base for collaborative efforts. In short, you miss nothing, finalise everything and wind up with far less "bailing water" time wasted.

At every stage of the project, you have a single file that you can view to see where you are at. You can deliver it to a client or manager as a report as to your progress. Perhaps you could copy the QA tab into an MSWord document, pretty it up and deliver a formal report, with an addendum listing outstanding issues that you need answered? And if you are planning to outsource your document assembly to a consultant, you have done many hours of work that you do not need to pay for at consultant rates. No matter how your consultant chooses to work, you will have given them extremely clear instructions, lists of document variations to be included into each template as well as a complete index of everything that needs to be done. Ask a lawyer in your firm how much poor instructions cost the client, versus how much the client would have saved if they had provided everything up front, indexed, categorized and annotated. The same concepts apply here.

Lastly, should you leave your job, the next person after you has a complete blueprint of everything you've done, every rule you coded, every template involved. If you hit a wall and cannot program more, but the users are asking for something, you can palm it to a consultant, and they wont have to spend many long hours figuring out what has already been done so they can move forward. There's nothing worse than picking up a "finalized" system drafted & built by someone else, with no notes as to how or why it was done. Do I personally have a problem picking up a project without any notes? Not at all, but its your money...