Working with template systems (as opposed to individual templates) requires attention to detail and planning before execution. The rewards of planning come from ease of maintenance, and flexibility to change. The blog looks at formatting and design questions in Document Assembly system.
Document Assembly
All things related to document assembly generally
Document Assembly on Wall Street (Corporate Transactions)
This Blog addresses the use of document assembly in the Corporate Law Department of a large firm. It explore the type of documents in such a department that might be amenable to automation.
The chart below shows a range of documents that form the bread an butter of a corporate law department providing general business and transactional advice. Each of the documents below can involve anywhere from 10 to 100 hours to draft. Once automated, a solid high-quality first draft of these same documents can be produced in less than 30 minutes, dramatically increasing the firm’s competitive edge and opening the possibility of substantial profits from value billing.
| VALUE | VOLUME | INVESTMENT | DOCUMENT TYPE |
| Low | High | Low | Advertising and Promotion Agreement |
| Low | High | Low | Alliance and Co-Marketing Agreement |
| Low | High | Low | Bioprocessing Services Agreement |
| Low | High | Low | Campaign Management Services Agreement |
| Low | High | Low | Collateral Assignment and Security Agreement |
| Low | High | Low | Content License and Co-Branded Area Agreement |
| Low | High | Low | Co-Sale Agreement |
| Low | High | Low | Interim Linking Agreement |
| Low | High | Low | Joint Marketing Agreement |
| Low | High | Low | Linking Agreement |
| Low | High | Low | Manifest System Services and Co-Branding Agreement |
| Low | High | Low | Manufacturing and Supply Agreement |
| Low | High | Low | Media Placement Services Agreement |
| Low | High | Low | Order Fulfillment Agreement |
| Low | High | Low | Resale Agreement |
| Low | High | Low | Web Advertising Services Agreement |
| Low | High | Low | Website Affiliation Agreement |
TABLE KEY:
Value measures the value of the document in terms of potential markup based on time to do the document without automation. High would be over five thousand per document; moderate would be over a thousand; low would be in the hundreds per document.
Volume is the likely volume in a given year. Low would be once a month; Moderate would be once a week, High would be daily or more frequent.
Investment is the amounts of time it would take to automate the document to 90% effectiveness. High would be over 250 hours. Moderate would be over 50 hours. Low would be anywhere from an hour up to 50 hours.
Document Type is the name or category of documents that to be automated
Interview Computations (Best Practices)
A few recent posters to the HotDocs list have suggested it was not “best practices” to use computation in the INTERVIEW computation; that is was best to use a series of ASK statements, surrounded by IF EXPRESSIONS to guide the interview. This Blog add looks into Best Practices for creating a document-scope INTERVIEW computation in HotDocs
Related Link: General information on HotDocs
A few recent posters have suggested it was not “best practices” to use computation in the INTERVIEW computation; that is was best to use a series of ASK statements, surrounded by IF EXPRESSIONS to guide the interview.
Best practices are always best understood in context: what is the purpose of the practice; when is this practice appropriate. In the case of using computations inside the INTERVIEW computation, there are a number of competing factors that affect your choice.
READABILITY: The purpose of the interview computation is to define the scope of the INTERVIEW for a document. To this end, it is meant for a sequence of ASK statements. The more you can focus on what is being asked, and place it on the dialog, the easier it will be to debug scripting issues arising from “misplaced dialogs” and “orphan variables”. There may also be a benefit for those using HotDocs Online, where it is indeed best practices to explicitly state the order of dialogs asked.
SPEED OF PROCESSING: There are times where HotDocs processes or calculates certain scripts FASTER than other ways, used by more experienced developers. I have found a modular master interview, with optional calls out to computation variables that contain the dialog asking sequence to actually run faster. In a Master Will, I might have a sequence dealing with pre-residuary gifts that I would isolate from the main interview in its own computation.
DATA-MANIPULATION: HotDocs 6 and HotDocs 2005 fundamentally changed the way HotDocs processes data. It changed from a “linear processing” to “recursive processing” whereby each new data entry leads to a recalculation of the complete interview tree. Being aware of this has led to certain best practices on our part, namely using either (1) Buttons that launch computations or (2) computation scripts in the main interview that contain “flags” to determine whether or not they have been launched.
MASTER CMP vs. DISTRIBUTED CMP: also known as MATTER SCOPE INTERVIEW vs. DOCUMENT SCOPE INTERVIEW: I am a big believe of Matter Scope Interviews; a single CMP file that launches a master interview that start out with a Document Selection dialog, and then renders a custom interview based on the document(s) selected. In such an environment, interview scriptlets (or subinterview computations) are critical. On the otherhand, if you are only doing document scope interviews, which work in a system with shared matter-scope answer file, it would be easier to keep the scripting to simple ask statements in the INTERVIEW file.
Document Assembly On Wall Street (Introduction)
I have been asked recently to prepare a White Paper on Document Assembly as applied to a large Wall Street law firm, with a sophisticated and diverse corporate practice. This article will launch a series of articles that will take you through a law firm, department by department and identify those areas that are ripe for automation.
Related Link: For further review
I am myself a creature of Wall Street. That is where I got my start as a lawyer; it is a place that defines my view of the practice of law. It is a model, not the only model, that delivers exceptionally high work product and dedicated client service.
It is an area of the law practice that is exceedingly profitable. Partners charge upwards of $1000 per hour at premium rates or sometimes, a sliver percentage of very large transactions. The expectations of these clients is nothing less than perfection itself. And for that perfection, they pay. Profits derive in many of these cases from the raw talent of the lawyers combined with very long work hours.
It is my position that the profits of these firms (revenue minus costs of delivery of services) could dramatically increase with the judicious use of document assembly; that these law firms could increase their profits while at the same time decreasing the prices they charge for defined services. These profits would come with increased consistency of quality work product; faster turnaround of critical business documents; increased client satisfaction; and even increase attorney satisfaction.
This series of articles will make the case on a department by department basis, through a typical (if that is possible) Wall Street law firm.
Pitfalls of Online Document Assembly
How does one explain to a web developer that document assembly is more than just throwing up some web-forms with fields tied an SQL database? Sometimes, the hard way, by letting them try it themselves …
Related Link: For more information
Document Assembly is more than “merge templates”. A merge templates takes “defined fields” and replaceS the field codes with data from a data source. Anyone who has worked with a document assembly program, like HotDocs, GhostFill or DealBuilder, knows that “field codes” are just the beginning.
And yet, on countless occasions when talking to prospective clients (particularly large corporate IT or big firm legal, and even smaller law firms) they view document assembly as just a bunch of fields that can be filled in by any Tom, Dick or Harriet paralegal off the street, with little or no training. They view the “coding” of such systems as beneath them in its simplicity.
To corporate IT, it is a matter of laying out the fields in a database, tying that database to a series of web forms, and then pushing that data through a Word/RTF engine to produce the final output. To them, there is no problem that a few days of coding can’t solve; a smart team of web/database specialists can build this stuff in under six months, piece of cake.
Now if my clients gave me funding for a team of programmers to work full time for six months, I would be laughing … No I wouldn’t say no, but with the current state of the art in document assembly tools, what my team could accomplish with that funding vs. what the IT group would build, would be quite different. Don’t get me wrong, the IT group would produce a system that would be polished, beautiful objects and data flow, sculpted buttons, drop-dead graphics, the works.
However, the laugh would occur when the “content managers” half-way through the project changed their mind. Everyone knows that law is as much an art as a science. It is a series of balanced judgments and competing interests, and how the balance comes out on any given issue will change over time. Where document assembly tools shine (apart from rapid development tools) is when the “author” changes his/her mind; wants to change phrases in the template, add a new rule in a dialog, remove irrelevant questions (or hide them under new rules); or simply wholesale change the help text because the users keep asking dumb questions that can be best explained in the system.
When I have talked to the web developer about my “requirements” … they say piece of cake. They see fields, dialogs, databases… Basic stuff. Then I tell them, that I want the data structure to expand and contract (at whim). That I want to add conditions and rules to the content of help text on particular variables. That of course, there should be a seemless navigation system that lets me answers questions in a non-linear fashion (but still only show me relevant questions based on the answers I have given to the interview).
Only after have they have invested substantial days in the project will they come sheepishly to admit, this stuff is REAL HARD to do … you are going to have to settle for less. To which I laugh: Why should I settle for less? I can do all of this, without your fancy programming with DealBuilder Server; GhostFill Server or HotDocs Online Server. These systems take the desktop template systems that many of you use, and let you “publish to the web server”. The publication process automatically converts the pages in the case of GhostFill to DHTML, in the case of HotDocs, to Javascript; and in the case of DealBuilder to ASP pages.
So … if you still think programming document assembly forms on the web is easy. Go ahead. For the rest of you, go take a look at these products, see if they work for you. It could save you a lot of money in the long run.
Tips for Working with the HotDocs Markup Tool
In working on the CIC exam for HotDocs, I took the opportunity to master the HotDocs Markup Tool and HotDocs Template Generator. In this article, I examine some tips on how to use the tool to the best advantage.
HotDocs has recently released the HotDocs Markup Tool. A few of you may have dismissed it as a toy … real coders don’t need markup tools. But I took the challenge to see if I could find a use for the tool. Following the NYMetro user’s group where Marshall demonstrated the tool, I started seeing additional features, not obvious on the surface that have been built into the tool.
Now, I am a big believer in planning. I build spreadsheets for complete template systems. I layout all the fields, organize by topic and series and name consistently. The concept of a markup tool, therefore is appealing, but only if I can have my categories and groupings.
Conclusions about the Tool
There are limitations to the tool, but on balance, its ability to write directly to a HotDocs component file and to interpret directly IF expressions and variables with formatting, promise the potential of much faster template development. Doing work faster and more efficiently means projects get done. There is a value to finishing, as a significant number of HotDocs systems never get finished.
So … if you are going to use the tool, here are some tips
- Code: This is the markup that will actually show up in the document. Use abbreviations that group the variables by target dialog and then identify the type of variable. Do not try to get the exact HotDocs variable name. Use something descriptive.
- Variable Name: Take some time to think out the variable name. Realize, this is a database, so you can change the variable name BEFORE you publish it into a component file. Give it your best shot. Use a prefix that groups the variable by the target dialog. Use a suffix that identifies the data type.
- Type: This is merely a matter of telling which type of component to create. There is now support for Multiple choice variables. Also, note the support for computation variables. This does not mean you can actually create the computation, but you can place a computed variable in the template and it will create a blank computation that you will later use.
- Default: This is the format example. It is worthwhile setting this, particularly for dates and numbers.
- Options: This applies only to Multiple Choice variables. There is support for setting both the options and the prompts
- Resources: This is a fancy name for Help Text. For some reason, HotDocs persists in calling this “resources” when it is really just links for help text. At the moment, the only support is for the standard help text, not for links and URLs
- Notes: Very useful for notes and status. Not sure where these end up in the component file.
Now what can be done with the data?
- Drag and Drop: You can drag and drop from the list into a template. It uses square bracket notation for the variables
- Add Logic: The square bracket notation can also read IF expressions and Repeats and End Repeats, End Ifs etc and translates them into chevron notation. It is not clear whether the if expressions can use the pseudo variables in the markup and replace them with the actual variables or whether you have to use the HotDocs Variable.
- Copy All Rows to Clipboard: This lets you copy the complete database to the windows clipboard. You can then “paste” it into a spreadsheet.
- Paste Rows from Clipbard: Assuming your clipboard matches the columns on the spreadsheet, you can now copy from Excel into your markup database, effectively creating a data dictionary that you can supply to your authors for template markup.
Plain English Document Assembly
Special Feature by Rose Rowland, Basha System LLC on plain english, manuals, and verbal brutality towards Basha staff
A few years back, the SEC, in an attempt to make prospectuses and other stock offering documents intelligible to those without a financial degree, regulated that all main offering documents had to be written in “Plain English.” They then created a manual to teach us all how to write in Plain English. Frightening thought, isn’t it? At the time, I was a paralegal working in private securities offerings and I was rather impressed with this idea.
A few years later, I am a partner in Basha Systems LLC and I am striving to bring the concept of “Plain English” to our document assembly and case management systems. Basha Systems, as many of you know, creates wonderfully innovative and interactive document assembly systems that can pretty much create any kind of document you would like. The dilemma with complicated systems is how to make them palatable to the non-computer professional.
This is where I come in. While new to the world of programming, I feel that I bring a unique insight to Basha Systems that might well be lacking in other computer consulting companies. I have not forgotten how frightening and frustrating the learning of a new computer program or system can be. At Basha Systems, I am in charge of the Quality Control and Manuals for all of our document assembly and case management systems.
I am absolutely brutal – as both Ian and Seth will attest. If a prompt is not absolutely crystal clear on a first reading, out it goes! If I find that any part of our system seems to be the slightest bit difficult to maneuver, back it goes for retooling. No obscure computereze is allowed in any manual written by Basha Systems. My feeling is that if you can’t pick up a manual, follow the instructions and begin to use the system immediately, we have not fulfilled the standards of Basha Systems. And, our standards are very high.
Not only do we strive to create systems with all of the cool technological bells and whistles the client desires, we also strive to create systems that anyone can use with an absolute minimum of training. A document assembly or case management system that’s too complicated to use is a system that won’t be used.
Lawn Maintenance and Spring Cleaning (document assembly revisited)
The key to a successful implementation of document assembly is an intelligent markup. The key to an intelligent markup is a solid understanding of the subject matter which is being marked up; as well as an awareness of what “can be done” with document assembly.
Of Forests and Trees
The old “saw” goes, “can’t see the forest for the trees”. And the converse is “can’t find the trees, all I see is forest”. In document assembly, you need both the “helicopter view” and the “hiker’s view”. You need to see the overall lay of the land, where the document is going, how it’s flowing. And then, you need to get down on the ground and start sorting and culling.
Lawn maintenance
With the coming of spring, lawn maintenance is something on my mind. The sytems I built need a spring cleaning and refresh. Over the winter of use these systems can become stale. Like a lawn, you can let everything grow will. Better to run the law mower once a week. When cut to 2 inches height, weeds and grass look a like. You can rip up the whole lawn, an reseed with fresh kentucky bluegrass. Or, you can apply fertilizer and selectively apply weedkiller to find those troublesome patches.
In document assembly, you need to do a bit of everything.
Regular Mowing Like the lawnmower, you need to sweep through the document, getting all the obvious issues and gaps. Run assemblies (if you have done partial automating) and identify what is missing.
Apply Fertilizer: Go through you document on a regular basis and apply enhancements. Each time a new issues arises look where you could have addressed an issue better, applied more nuances.
Remove the Weeds: There are portions of your document that will just not work. You try to tweak the code, a little here and little there. But there are some blocks of code that just don’t work. They create eyesores that you are constantly deleting in the finished document. Remove these items, from the document, from the interview.
Reseeding a Patch: Sometimes, an Article in a Contract just needs to be rewritten. The language is stale. There are too many codes in the paragraph for one to figure what the hell you ever meant. In these circumstances, it is better to start from scratch.
Extending the Lawn: Look at your current systems. Did you go far enough. You are gathering data on a lease, but how come you haven’t created a term sheet generator or an abstract generator. Take the next step and build on what you created. What is the next logical document to automate. There are economies of scale in document assembly, and there is the “marginal cost of production”. The marginal cost of building the next document in a practice set is much less than the initial document cost.
Planting Garden Lawns are well and good. They are fun for croquet and games of catch. But gardens are what bring “fruits and vegetables” to the dinner table or “flowers” that bring value to the house. Consider taking what you have built and planting a garden. Let your clients know what you have done with these systems so they will want to give you more work and refer you to their clients as a lawyer who “gets it.”
A Tool To Consider – DealBuilder
I have written extensively about HotDocs and GhostFill, but not said too much about DealBuilder. DealBuilder, as a webhosted platform, which ships with a product called DealBuilder Author and DealBuilder Express.
These are the authoring environments for the DealBuilder Server. Until DealBuilder or one of its resellers offers DealBuilder on an ASP model, you will need to get a full license to DealBuilder Server and have the infrastructure and IT department to support it. Once you do, you will find that DealBuilder lets you do your infrastructure redesign right in the template. The Author engine validates the document, and renders conditional scripted dialogs on the basis of the nesting and scripting in the template. It also offers you the ability to “drop in” a data dictionary of terms, so that variables can be easilly reused across templates. As we evaluate DealBuilder more closely, we will post further information in the DealBuilder section (http://www.bashasys.com/dealbuilder/index.html) of Basha System’s main site.
An Interview with the DocGuru (by himself)
No one was calling me for juicy quotes. Some of you have started visiting the blog. I was getting tired of the lack of interaction in a blog (too much lecturing). So I thought I would do something fun, I would interview myself.
Related Link: the guru’s document assembly page
The DocGuru: Where does document assembly make the most sense?
Himself: Well everywhere! Anything you write, anything you type, any form you fill is a candidate for document assembly.
The DocGuru: Be real. Coding a template takes time. Should we really do everything?
Himself: Why not. It’s fun. It challenges the mind. It beats billing time.
The DocGuru: Yes. You caught it: “billing time.” Shouldn’t we spend our time doing billable work?
Himself: Well for me, document assembly is billable work . But for you, I get the point, and the answer is NO!
The DocGuru: Who is going to pay for the office overhead? We can’t hole up in a dark corner with a laptop and code.
Himself: I don’t do it in a dark corner, I beg your pardon. I take the laptop out to the garden, and watch the Daffodils pushing up, hear the birds chirp. Spring is beautiful.
The DocGuru: You are avoiding the question
Himself: All right. Here is why you should “stop billing”. Do an hour of billable work and you make money for an hour of billable work. There is no multiple; no extra reward for the effort, no return on investment. Yes, you make more than the typical wage laborer …. (have you talk to your plumber recently?) But say you make $400 and hour … you need to work a lot of hours to get real rich. And then, you have to constantly justify your time. What is the “value” of your labor … What is the value of your “workproduct”
The DocGuru: But that is what lawyers do, they bill
Himself: I disagree. You don’t come to a lawyer for a few hours of his time …. Yes he may bill you for a few hours. You come for advice; you come for help out of a jam; but more often you come for a “document”. It is the document you want, not the time; you want to take home a piece of paper, whether it be a partnership agreement, a lease, or a will; you want to know that it is well written and will survive the test of time.
The DocGuru: What does that have to do with document assembly?
Himself: Document assembly is all about documents; it is all about the creation of quality documents; it is all about the delivery of services. It is about workproduct. Invest 100 hours in template coding, and the return is equal to a thousand hours of billing. It allows you to bill for the document; not for the time. It is all about multiples; all about service; all about competition.
The DocGuru: You seem convinced about this? You have been doing document assembly for nearly a decade. It is easy for you; but not everyone can code.
Himself: Exactly my point; but all of you can markup documents. You markup documents day in and day out. Why not mark up your documents and send them to me to code. It will take less of your billable time to get the project done; and bring you closer to your the time you can reap the multiples from your investment.
The DocGuru: Aren’t you being a little direct? This seems to be a sales pitch.
Himself: Think what you wish. Feel free to come back; I give away advice for free and tip. You will find me posting (uncompensated) on the HotDocs list and GhostFill list. Many of you have received a private email or a call when you got into sticky trouble. But I do make my money consulting and love my work. Did I mention my new document assembly and case management sections on my website?
The DocGuru: The DocuGuru: You are a hypocrite. Don’t you bill by the hour?
Himself: Have you called me? You ask me to troubleshoot a template and give you “help” writ large; of course I bill by the hour. But, if you come to me with a set of documents, all marked up, and ask what will it take to turn them into a system, I will more than likely give you a fixed fee quote or a range. The quote will be based on a combination of the value of the documents to you, the complexity, and an estimate of the time it would take a typical coder to automate the documents.
The DocGuru: Well, our readers thank you for your candid comments and this opportunity to talk with you. Keep up the good work. Keep blogging.
Is HELP text necessary?
A well designed document assembly system NEEDS NO HELP text. Each prompt is group logically and clear. It states its purpose and can be understood by users. Why would anyone ever need help text?
Because it is not so simple. In building systems, a polished dialog is a balance between information and data entry in an environment where space is limited. The term “limited real estate” means the amount of information that can be seen in a standard window WITHOUT scrolling. That is the real estate you are dealing with, because more often than not, the user will forget to Scroll before proceeding to the next dialog.
Now why do I care?
I care because I want all my questions answered so that the assembled document will be complete. To this end, I use headers and short prompts to fit as much relevant information in a single window.
What about the help text?
The help text is optional. The first time you run a template assembly with HotDocs or GhostFill or Dealbuilder, you want all the help in the world, until you figure out what the author of the system means. However, on the second, third and fourth time, you get it … and now that detailed on screen prompt is weighing you don.
The solution – tiered help systems
Our approach is a tiered help system.
- Careful naming of prompts, headers and dialog titles
- optional on-screen help
- drafting tips that spawn dialogs
- buttons that launch web pages
- integrated resource help
This approach lets you get the help you need, when you need it, but otherwise doesn’t clutter up the real estate.