Process Based Document Assembly for Civil Litigation

by

Is it the process or the document that comes first?  Does the user view the world as a series of data, with document as the outputs; or a series of documents, with data as the inputs.  These views govern how you will design a document assembly library.

Input Data ….
Output Documents …
Process or Form Library

These are the choices when building a document assembly library.  Most users view the world as a collection of forms.  Choose the right documents and fill them with the available data.  Push it through from lawyer to paralegal (or secretary) and then out to client or court house.  And yet, where you stand in the process is critical how you design the library.

Benefits of Process-Oriented Systems

A process-oriented system focuses on steps in a process, and constrains the users choices only to “relevant” information and documents.  The user at stage one, inputs client info, opens the “matter file” and sends out a “client engagement letter.” Once payment is received and further action is authorized, the process requires gathing facts on potential defendants, third parties, and their related representatives.  Then as the litigation proceeds, there are options as to how that litigation branches.  An internal party list keeps track of who was served with what documents and when.  Another data table stores information about each defendant.  And yet another table stores data about the claims and their elements.

Such as systematic approach allows for a high volume litigation process … not high volume in terms of hundreds of hours plodding through documents and depositions, but high throughput in ability to cost-effectively process claims and get out the necessary court papers to keep the action alive and bring it to resolution.  It allows this work to be done by “paralegals” and “legal secretaries” under the supervision of a junior attorney.  The constraints built into the process system, reduce the level of supervision to managing the “stage of the litigation” and “court appearances” rather than overseen the choice of document forms and the quality of the data input.

Benefits of Document Library Systems

The typical “forms library” is usually a book or an electronic book with a table of contents.  From this library, it is up to the user to (1) select the appropriate form, and (2) fill it.  There is no constraint on the appropriateness of the form; it is the selector’s judgment.  In filling the form, a good document assembly system (HotDocs, GhostFill, DealBuilder) will allow you to use “answers” given in prior document assembly sessions to fill out the current form, and then prompt you for missing data.

The “libraries” are exactly that; places to browse in the hope you can find the right bucket.  In many “off the shell systems” is is serendipity whether you will actually get data used for one form to pre-populate a second form.  These published systems have inconsistencies in their underlying code so that the “promise” is not delivered.

Conclusions on Process vs. Library

If the practice is “diverse” enough, what you may need is in fact a “library”.  The library will give you a modest increase in efficiency, but will require a much greater degree of senior attorney supervision and judgment.  If the practice is essentially a solo practitioner (without secretary), these open systems with hundreds of forms make sense.

However, the more complete process oriented systems are better suited for high-production law departments.  They require an investment of time and training.  But the productivity rewards put a law firm in a substantially greater competitive position.  They are systems that give a full ROI in the first month or two, and then become profit centers.

Document Assembly on Wall Street (Asset Securitization)

by

Part of a continuing series on applications of Document Assembly at a Wall Street law firm.  This blogs deals with the application of document assembly to a practice specializing in Asset Securitization.

A corporate legal department may, from time to time, have clients who need to take “debts and obligations owed to them” or “accounts receivables” and securitize them, turn them into assets on their balance books, by selling off the obligations or receivables … turn those “future revenue” into present revenue.

The elements of such a package may include a loan agreement, an origination agreement, securitization agreement, trust agreement and verification agreement.  While the transactions can be quite complex and the assets diverse, there are certain regularities in these instruments that will lend themselves to automation.

For example, each state has required language for loans, certain proforma’s require to make the loan valid and collectible.  The terms of the loan, payment rates, early payment provisions and the like will be standard in their structure, while varying in the specifics.  The schedule of assets being transferred will have a description, a volume/amount, a value (fixed or estimated), and particular restrictions. These schedules can be built automatically, incorporated into the document and totaled using document assembly.

In connection with each asset, notices may need to be sent out to the original debtors as to a change of control of the obligation.  These can be automatically (and accurately) generated from a data source.  A mass mail of certificates and notices can be generated using the same data used for the schedules.  The overall time savings can allow a firm to very profitably value bill from these transactions.

 

VALUEVOLUMEINVESTMENTDOCUMENT TYPE
LowHighLowLoan Agreement
LowHighModerateOrigination Agreement
ModerateModerateModerateSecuritization Agreement
ModerateModerateModerateTrust Agreement
LowModerateModerateVerification 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

Document Assembly on Wall Street (Corporate Transactions)

by

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.

VALUEVOLUMEINVESTMENTDOCUMENT TYPE
LowHighLowAdvertising and Promotion Agreement
LowHighLowAlliance and Co-Marketing Agreement
LowHighLowBioprocessing Services Agreement
LowHighLowCampaign Management Services Agreement
LowHighLowCollateral Assignment and Security Agreement
LowHighLowContent License and Co-Branded Area Agreement
LowHighLowCo-Sale Agreement
LowHighLowInterim Linking Agreement
LowHighLowJoint Marketing Agreement
LowHighLowLinking Agreement
LowHighLowManifest System Services and Co-Branding Agreement
LowHighLowManufacturing and Supply Agreement
LowHighLowMedia Placement Services Agreement
LowHighLowOrder Fulfillment Agreement
LowHighLowResale Agreement
LowHighLowWeb Advertising Services Agreement
LowHighLowWebsite 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)

by

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)

by

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

by

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

by

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.

Knowledge Hierarchies

by

This blog evaluates hierarchical knowledge systems from searchable knowledge systems.  As Yahoo is to Google, Westlaw is to Lexis, Blogger is to ExpressionBuilder.  … unstructured information can be useful, but the extra effort to add structure make the information even more useful.

I started blogging in ernest a few weeks ago.  At first, it was a spurred on as part of a marketing campaign to drive traffic to my website.  A suggestion by Neil Squillante that the link in my bio to bashasys.blcgspot.com would go nowhere … since the last post was several months old.

I took the time to think what the purpose of the blog was and where it fit.  I knew I liked to write.  But like most writers, I liked to be read.  So I got to thinking, what could I write that a number of peoples would want to read.  I was not a novelist; no plans for that.  I was not a scientist.  No, I was a technology consultant, a recovered lawyer, an invetirate tinkered.

I set myself a quote of 15 minutes a day … capture one thought in the blog.  Then I started looking at other blogs; to see if there were anyone I would want to visit again.  I found a few.  The best ones I have listed in my blog-roll on the right.  If you have the time, take a look at them.

What I saw was that I needed a focus, an angle.  I know a few things about document assembly and case management.  I have written and lectured extensively on these topics.  I make my living providing consulting services in these areas.  I have taken my hand at helping guide the makers of these products to better understand what tools would be useful to people like me (trying to build solutions for our clients with document assembly and case management software.

It took a few weeks to get focused on the topic.  Then I turned to the tools.  As a lawyer, I was used to structured knowledge.  Legal contracts have articles, sections and headers.  Legal briefs have arguments and supporting facts.  Legal cases have fact headnotes and then facts.  Most of law is structured and categorized.

And yet, when I looked at my blog, I had titles, dates and body text.  Unless you, my reader were to come back every day and read what I had written, the mass of unfocused material would overwhelm.  And, if I strayed off the narrow topics of document assembly and case management, you would have no way of following that thread.

And so I hunted for a new platform.  I found pMachine’s ExpressionEngine.  It supported multi-tiered and multiple categorization of information.  And it sported powerful keyword tagging and search indexes.  Moreover, it allowed you to create custom fields that could be used to provide abstracts or summaries to help you, the reader, decide to read on.

Now back to Yahoo versus Google; Westlaw versus Lexis, and ExpressionBuilder versus Blogger.  All of these tools allow you to find information; run searches.  The latter category focus on boolean searches; choose the right search words, and you will find the articles that contain those words.

The former group, Yahool, Westlaw and ExpressionBuilder give you a hierarchal structure of topics so that one can find the correct topic and drill down to find the articles that are on that topic of interest.  As you drill down, you will see abstracts.  And only then do you see the full articles.  This is the approach I hope to use with this Blog.  I will write in an “unstructured fashion” … stream of consciousness like a typical blog, but as I do, I will categorize and abstract, so that over time, there will come to be a wealth of information on a range of topics.

Plain English Document Assembly

by

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.