Posts Tagged ‘design approach’

Affording Document Assembly: the Group Approach

As a document assembly consultant, I am often contacted by solo or small attorney firms who are overloaded with work, champing at the bit to get a Document Assembly system, realize the value but are understandably nervous at the cost. And, they should be. Creation of a good document assembly system is expensive in both time and money. Your law school education wasn’t cheap, setting up your office wasn’t cheap and setting up a potential profit generating document assembly system that will become absolutely integral to your practice won’t be cheap either.

So what do you do – bite the bullet and get your money back on the ROI or give up? Here’s a possible third solution – Group development. Two or three lawyers with similar practices might be able to create a system that all of them can use and share the development cost. This, of course, requires collaboration, cooperation and a willingness to compromise. It’s a midpoint between buying a pre-canned system and getting one custom made for your own needs.

If you decide to go with this approach, the first thing you should do is find a developer to build it for you. It’s a very bad idea for 3 or 4 busy lawyers to try to build pieces of a document assembly system and hope they’ll hang together properly. You need a central expert who will advise your group, develop the templates and interviews and make sure everything works with everything else.

After that, devising a group document assembly system is similar to devising one for a single firm. You need to determine the universe of documents that will be automated, set up meetings with the developer and designate an expert from your group to work with the developer.  For the period of development, think of your group as one firm.

Some ideas for setting up your group:

1. KEEP IT SIMPLE. When choosing the attorneys for your group, stay in your area of expertise. DO NOT grab the real estate lawyer from down the street, the PI guy from next door and the estate lawyer from down the hall. These are very different areas of law with very different automation and document gathering needs. Stay within your area – if you’re basically a PI litigation firm, go to other PI lawyers to make up your group.

2. KEEP IT SMALL. It may seem that a system like yours would be good for the 20 other PI lawyers in town. Ever been in a meeting with 20 people? Doesn’t work very well for general consensus, does it? Don’t bring in more than 4 other attorneys.

The bottom line is – We, Basha Systems have been in business since 1996. In that time, we have never seem anyone remove or stop using a document assembly system. Once they’re built, people use them and use them. So, if price is what’s stopping you . . . try the Group approach to keep your costs in line.

Migrating from Legacy Document Assembly Systems

Over the past decade, document assembly systems have come and gone.  Some, like HotDocs 4.2, HotDocs 5.x, CAPSAuthor, WinCAPS, SmartWords, Agility, FastDraft, Form Bank, MasterDraft, MillRace, NovaDocs, PowerTXT, Scrivener, ThinkDocs, and WorkForm, are no longer supported.  Some like GhostFill, ProDoc, WinDraft, and Perfectus have only a small developer community that provides limited support. Others, like WordVBA and Wordperfect have macros tools that require dedicated technicians to support and maintain. Yet other systems, like Pathagoras, D3 and qShift lack support for traditional programming techniques like repeat loops, nested IF statements, and variable scripting.

The result is that thousands of legal templates are locked in poorly supported legacy systems, representing hundreds of thousands of hours of programming and invaluable legal workproduct.  This article explores a process of identify and extracting the business rules and workproduct from these legacy systems and moving them to more powerful and better support platforms such as HotDocs or DealBuilder.

At root, all document automation systems are the same.  They address the same fundamental issues: which documents, paragraphs, and phrases to include in output document and what data to use to fill in the blanks.  The hard work in document assembly programming is NOT the programming, but rather crafting the business rules which govern whether to include or exclude text and how best to fill in the blanks.

It is for that reason that we have developed a universal approach to marking up documents and document automation interviews that can work with any document automation system.  This approach allows us to take templates in legacy document assembly systems: (1) identify and catalog all the conditional rules, (2) identify and fully describe all the variables (by function, type, prompt and defaults), (3) identify all the dialog objects and scripts, and (4) extract all the text objects, clauses and subdocuments.

From there we structure in Excel a prototype interview in HotDocs, GhostFill or DealBuilder) that mirrors the functionality of the legacy system.  In describing each new variable, object, script in the new platform, we maintain a reference to the comparable object in the legacy platform.  Once the interview and datastructure is completed in the new platform, we turn to the text objects, clauses and subdocuments.  Where possible, we have preserved the markup of the legacy platform in the text documents.

We generally consolidate the text objects into master templates so that they are more easily edited as a whole.  Where text objects are used in multiple templates, we keep them separate and use INSERT or INCLUDE commands to bring in the text where appropriate.  As part of the process, we also strip the text of all formatting and then carefully apply a Word style sheet using outline schemes, paragraph styles and character styles to handle ALL text formatting, spacing, letting, kerning, outlining, numbering etc.  This allows use to use the stylesheet pro grammatically to change the document templates and the assembled documents.

There is a tendency to want to “throw out the baby with the bath water” when a firm decides to adopt a new document assembly system.  While the process described above TAKES time and planning, it does preserve the MOST valuable part of the automation process, the attorney time and workproduct.  If you have a system that WORKS, but is old and dated, it is best to use that as a base for the new system, rather than to scrap it entirely.  That gives you a result that will WORK when delivered.  And then, you can have fun, spend money, adding in the new features and enhancements that the new document automation platform offers.


HotDocs 4.2 & HotDocs 5.x: LexisNexis no longer supports these early Windows versions of HotDocs.  Hundreds of thousands of licenses to HotDocs were bundled with WordPerfect Legal Edition. Early HotDocs had limited scripting and presented questions in a series of popup-dialogs as the document was assembled from within Word or WordPerfect. With HotDocs 6/2005/2006/2007, HotDocs transitioned to a single interview object and moved the assembly outside the word-processor into an RTF-Assembler.

CAPSAuthor & WinCAPS: Once the best and most advance document assembly platform for MS-DOS.  CAPSAuthor still runs in a DOS-window.  WinCAPS is the assembly environment, built to run in Windows 3.1 on a 16-bit platform.  There were hundreds of systems built with CAPS, including several that were sold commercially.  We were responsible for converting one CAPS system, Drafting Wills and Trust Agreements (“DWTA”) from WinCAPS to the GhostFill platform.  We have also converted a document lending system that had over 5000 CAPS objects into GhostFill. The process of extracting the business rules, text and variables used for those conversions, could just as easily been applied to converting those systems to HotDocs.

SmartWords: Built on bTrieve and Xyrite, a very sophisticated engine. When the owner went out of business, the software was taken out of circulation.  Two years ago, Basha Systems converted Wealth Transfer Planning, the one commercially viable product built on Smartword, to the HotDocs platform.  That content is now owned by Interactive Legal Systems, which built a custom wrapper around the HotDocs templates that expanded on the document and answer management features of the original software.

Agility, from RealWorld Solutions, was a DOS-based product most suitable for offices using pre-Windows versions of WordPerfect.  The program had a deliberate strategy of simplicity.  Agility included most of the basic features one would expect in a document assembly tool, including nested logic and repeat loops.  But as there is no Windows version, non integration with any word processor, and no math functions it lacked viability for search document assembly applications.

FastDraft, from Interactive Professional Software, allowed a user to select a type of document, choose from available clauses and then fill in the blanks in the selected clauses.  The user could reorder the clauses and easily back up to previous steps in the process.  In this way, it was similar to the more powerful qShift.  FastDraft lacked features that make sophisticated rule-based practice systems, such logic, math functions, and validation of dates and numbers.

ThinkDocs started out as a graphic forms engine, which applied the concept of data stored in a database and hooked “live” into the assembled document.  It used DocVariables in assembled documents to retain a live-link to “answer data” stored in a database after the document was assembled.  As such, the system lacked any support for conditional logic on text in the template, unless the text itself was stored in the database and used to set the value of a DocVariable in the assembled document.  ThinkDocs appealed to users because of the “live” link—but in practice such live links worked only with simplistic documents – those templates lacking any complex embedded logic.

Form Bank, from now defunct ExperText Systems Ltd, was developed by Doug Simpson.  It made clever use of an automated teller metaphor, with developers depositing materials into the system, users withdrawing them, and a :”bank manager” determining who can do what.  It depended on Microsoft Access for a database of clauses, questions and other components that could be shared across multiple forms and managed by a group of cooperating users.

MillRace, from Old Mill Software was designed to allow attorneys to build documents by combing through annotated collections of forms and clauses, based on client requirements and negotiated issues.  It rejected the “QUAIL” – question, answer and imbedded (sic) logic – approach of most document assembly system. Development was ceased in 1997.

NovaDocs, from Novation Corporation in was conceived by James Conger.  It provided the basics of document assembly in an easy-to use and attractive package that exploits such features as collapsible outlines and drag and drop. Clauses and questions could be edited on the fly while assembling documents and making for little distinction between developer and user modes.  However, it lacked conditional logic, repeat loops, answer validation and other features standard in most document assembly engines.

PowerTXT, from Intercon Associates, Inc. was a feature rich, and easy-to-use program that evolved from FlexPractice, a popular DOS-based document assembly program in the 1980s.  In PowerTXT, model documents showed up as graphical outlines on the screen.  After users point and click thyeir way through necessary decisions, questions are asked that gather the details needed to assemble the desired documents.  The program did not support traditional programming techniques like repeat loops and nested IF statements.  Those who liked the outline and document-model structure of PowerTXT, would like’s qShift document modeling software which places clause libraries and document models on a privately hosted and secured web-server.

Scrivener was created by Dan Evans.  It was distinctive in being build on a true rule-based expert system engine and was among the first document assembly products to make good use of outline representations of document structure.  It provided support for incremental model revision as you use the system in everyday practice.

WorkForm and Visual WorkTool, developed by Analytic Legal Programs, Inc. was a powerful set of document assembly tools was a dominant player in the 1980s.


Pathagoras: Developed by Roy Lasris as that “alternative” to programmed document assembly. This system supports “quick and dirty” clause based assembly with rudimentary variables. If you want to build a library of “snippets” for reuse and throw some fields in, this software can save you time over traditional word processing. But to call this software document assembly suggests that this software is in the same league as HotDocs and DealBuilder (which it isn’t). That said, there is a lot of good forms built by lawyers with Pathagoras that could be made better in HotDocs.  The markup and structure of Pathagoras would make conversion fairly easy, and give users much more power and flexibility.

D3 Documents. MicroSystems SQL-Based clause manager and form filler is a great tool for fitting into the workflow of simple documents.  As a replacement for WordVBA and macros, it is a major improvement, serving as the glue for all those communications and simplistic documents.  What D3 does not support is traditional programming techniques for nested IF statements, loops, repeats and while statements, as well as script objects.  However, it represents a good start in that it forces the user to identify the data necessary for assembling templates and actually choosing and structuring the model language that will form the basis of the template.

qShift.  IXIO built a system that I would have loved to use when I was practicing law a decade ago.  It automatically takes a well-structured agreement, and breaks it into its constituent elements and presents a document model to which you can then apply automation rules.  We have reviewed it elsewhere.  It is great for choosing and crafting and dynamic form which will then be customized to a particular clients needs in a word-processor.  However, it lacks support for traditional programming techniques used in document automation software: multi-variable conditions, nested IF statements, computed variables, variables that share the same data source but are displayed differently, and full string and arithmetic manipulation capability.

WinDraft, from Eidelman Associates, was innovative and powerful when it come out in the 1990s.  It accomplished, inside the WordProcessor a level of dynamic automation that it took the other document assembly software years to catch up to.  However, the website ( hasn’t been updated in several years.  It’s business logic works with a simplified document markup and structure that did support nested logic and variables.  As such, the systems can be easily converted to HotDocs and DealBuilder.


DL Drafting Libraries: This proprietary form set, originally in DOS, but now in Windows, represents the “TurboTax” for

The Yin and Yang of Document Assembly

I gave the following presentation in Sydney, Australia at a conference sponsored by Simon Lewis on the future of Document Assembly.  In this conference I spoke about the opportunities and barriers to entry for document assembly in the legal marketplace.

A word on who I am.

  • A lawyer … like you and the people you work for with impeccable academic credentials
  • A programmer … like some of you with NO academic credentials
  • An evangelist who seeks nothing less than to turn the current legal profession UPSIDE DOWN and bring to the practice of law 19th Century business principles:
  • Define the Product
  • Figure a way to SELL the Product
  • Mass Produce the product

THESIS: Document Assembly is not a “product” or a piece of “custom software”, but rather part of a process that transforms the practice of law.

  • It is an evolutionary and enabling process that builds on existing best practices and manual processes.
  • The goal of a well built system is not people replacement, but enablement, the enabling of your current staff to reach new heights of productivity
  • The goal is the ability to bring on new staff as productive members of the team shortly after hire.
  • The Yin is your existing staff and manual processes.
  • The Yang is the software and the custom solution.
  • Together, they create a wholistic solution that will bring your law practice to the new levels of profitability.

Prerequisites to Selling Document Assembly in the Organization – Requires agreement on the Following

  • Law is NOT about Hours, but Deliverables
  • The DELIVERABLE can be accurately described
  • The CURRENT cost of achieving that deliverable can be quantified (albeit in a range)
  • The Time from Retainer to DELIVERABLE is a separate quantifiable factor
  • The case load maximum capacity of your existing talent is a FACTOR.

Document Assembly can do it

  • I have not yet met a document I could not Automate.
  • The more complex the document the GREATER the return on the investment in automation.
  • You know the story about the Ginzu knife: it slices … it dices … it chops … it even opens Beer cans …
  • A well implemented process can do and handle ANY ANTICIPATED legal or factual issue.

Can Your Firm Afford a Document-Assembly Empowered Business Process?

  • I am not talking about CASH … cost in the traditional sense.  I am talking about STRESS on the organization of a process that can be sped up by a factor of 10 to 100
  • This stuff is Crack Cocaine … Once started, there is no going back.  You take away document assembly, and your staff will QUIT.
  • Every aspect of the BUSINESS process is up for evaluation for potential automation.
  • Document assembly means paralegals and secretaries are doing FIRST RATE legal work and calling in the attorney for Closings and Court Appearances.
  • With Document Assembly you can ELIMINATE the Middleman … that supervisor layer that serves as an quality control and process bottleneck on getting the work done.
  • With Document Assembly you can RETAIN staff.  The work is exciting and the pace is fast.
  • With Document Assembly you can scrap those plans to go on a HIRING SPREE.  Your current staff can handle the work.
  • Document Assembly enabled processes adhere to Moore’s law … each year, you can double the amount of the work with the same Staff.

The typical questions and some not so typical answers

  • What will it ACTUALLY COST? How long is a piece of string …. as long as it needs to be.
  • How long will it TAKE?  How does one move a mountain?  …. One rock at a time.
  • Will you constantly need to REVISE the system?  Will you stop practicing law?  No … so why should a document assembly process ever be finalized.
  • Are all document assembly platforms the SAME?  … Oh … you must be snorting coke.  Document Assembly programs, unlike people, are not ALL created Equal and endowed by their creators with certain inalienable functions.  Some are simply more capable than others.
  • Does it REALLY matter which document assembly program I start with?  NOT REALLY.  So long as you start, and follow a clearly defined and documented process.

Half-Pregnant Document Assembly Systems

In a recent TechnoRelease, entitled “TR: Document Assembly: Let’s Be Frank.”, Roy Lasris, President of Innovative Software Products of Virginia, the developer of Pathagoras, wrote the following

Seth Rowland, a well recognized document assembly guru and multiple TechnoLawyer Contributor of the Year outlines in an article published in the September 27, 2005 TechnoFeature 13 discreet steps needed to implement an effective interview driven document assembly system. Seth implores those who are considering document assembly to find the time to implement all steps. Failure to do so will result in less than an optimal system.

I thank him for that quote. He then continued:

As a busy attorney, you may have neither the time nor the inclination to invest that kind of energy without having a guaranteed outcome. As academically accurate as he may be, Seth’s approach is simply contrary to (1) human nature and (2) the nature of most law offices. If you cannot or will not find the time to do it, then you won’t do it.

It is there that I disagree, both with his interpretation of my article, and his conclusion that real a substantial time investment in document assembly will not be rewarded by substantial multiples in profits for any law firm that makes such an investment.

Where Investment Counts

The same law firm that will calmly make a decision to to hire a $150,000 associate will agonize over a $30,000 automation project.  In the first year, the $150,000 associate will bring in a net profit of $50,000 to $100,000.  In the second year, the net profit will be about the same, for another $150,000.  The return on investment is a whopping 30-60%.  That’s if you are lucky.  Once that associate is well trained, he will want more money, or he may decide to bolt to another firm, taking his expertise (and maybe your client) with him.

By contrast, a $30,000 investment in a document assembly system, will allow your existing staff to do the same work as that $150,000 associate and maybe several other expensive associates.  The amount of money made each year on this initial investment of $30,000 would be equal to the profit on the expensive associate, for much less outlay.  The $50,000 to $100,000 would represent a 180% to 300% return on investment.  In the second year, even assuming maintenance costs, keeping the forms current of $10,000 per year, the profit would jump to 500% to 1000% on the annual investment. And even better, the “document assembly” system will not threaten to leave the firm or ever take your clients.

So why does this matter

This ROI will not happen with a simple clause based system which relies on constant and repeat judgment by an expensive associate to administer.  It will NOT happen with Pathagoras.  Pathagoras is a start.  It will happen with a carefully analyzed and scripted system that evaluates the whole document automation process, extracts the fundamentals and then scripts the whole process. When you are thinking of document assemby, be aware you get out of system what you put in.

To those users of Pathagoras, I offer this advice.  You have started down the right path.  You have started making the investment.  But you should not be wedded to your software choice.  Once you have organized your forms and information, identified all the key clauses that are worth re-using, you will be ready to take the next step.

Lessons from Mrs. Frisby – Nibble before you Bite

Mrs. Frisby came into our life last week … She is a “fancy rat”.  Her presence as a pet in the household has forced a re-examination of my prejudices as I have put this creature, who normally skulks around in the dark (avoiding rat poison) under close observation.  I have observed rat behaviour that has lessons for document assembly …

Nibble before you Bite

A rat does not see very well … That should not surprise you since rats are nocturnal, where the sense of sight is not particularly useful.  Rather rats smell, use their whiskers, and use their teeth. Mrs. Frisby, in the morning samples my fingers with her teeth, before you she climbs onto my hand.  When she discovers it is flesh and blood (and not rat food), she climbs on board.  At first, I was concerned with this biting behavior.  But she does not bit down … rather, her teeth come into contact with my skin, and then the bit withdraws.

So … what does this matter

In looking at document assembly systems, my most successful projects have been those that started out as a nibble.  The nibble before the bite means that the user (1) understands the work involved, and (2) has not put too much time and capital at risk before ensuring that there will be a success.  The nibble also allows time to develop an understanding of the document assembly system’s method of markup.

So what is the big deal about Pathagoras

Document assembly systems are complex and require a lot of work, despite what some responders have said to my article regarding the Pathagoras system.  Would you want to hire a lawyer who went and grabbed a bunch of miscellaneous paragraphs, each time he put together an agreement for you … or would you prefer a lawyer who planned out several contingencies, and choose the options most appropriate to your situation.  Don’t get me wrong, something is better than nothing.  But don’t kid yourself that you are going to build a system that will save you “tens of hours” on a project by using Pathagoras.

Because the “hard coding decisions” are avoided in a clause based assembly system, the time you save in development is lost EACH TIME you do an assembly, because the user is (1) required to have a higher degree of knowledge of the system, and (2) the user will have to continually “repick” the appropriate clauses, and (3) because the clauses exist in isolation, out of the contractual context, changes in one clause, that need to be reflected in another portion of the agreement, simply don’t get made because the “distance” between the clauses, and the memory of the “unwritten” and “uncoded” rule rests with the trusted author.

Basha Search


Basha Network

Basha Product Sites