Articles Posted in Technology

In December 2005, Marc Lauritsen and his colleagues assembled the document assembly engines that they then knew about. Just over a year later, these references may help law departments that would like to try out the genre of software. All that follows is quoted, but I have shortened some entries.

HotDocs from LexisNexis has the biggest market presence and most developed ecosystem. It has an excellent online knowledgebase, email discussion list, and consultant community. HotDocs offers the best tool for automating graphical forms, and has a full-featured Web implementation. The company continues to release significant new versions each year.

GhostFill from Korbitec in South Africa [is] integrated into the Amicus Attorney case management software, branded as Amicus Assembly. It also underlies the new and improved construction contract software from the American Institute of Architects. GhostFill has a programmer-friendly object-oriented and open architecture, making it very easy to add functionality. It offers great flexibility for custom integration, and can be easily hooked up to databases out of the box.

Every manner of software is used by some law department, somewhere. Much of that software has company-wide application, such as word processing, document management, spreadsheets and e-mail, not to mention all the operating system and network products, and offers nothing unique to law departments.

A handful of applications, however, run only or principally for the benefit of law departments (See my post of Jan. 25, 2007 on GM and nine applications.). What might be considered law-department specific includes software for board portals, corporate secretary and subsidiaries, e-billing, EDGAR filings, litigation support, matter management, options tracking, and patent and trademark databases.

This blog has commented on all these genre (See my posts of Jan. 25, 2007 on board portal software; Feb. 15, 2007 on corporate secretary packages; Aug. 21, 2005 on e-billing and matter management systems; Jan. 4, 2005 on the spreading acceptance of e-billing, March 21, 2007 on law firm vexations, and March 6, 2007 on the modest penetration of e-billing into law departments; Jan. 24, 2006 on EDGAR filings; Sept. 10, 2005 on costs of litigation support software, Feb. 23, 2006 on patents for such software, and Feb. 9, 2006 on the profusion of lit support vendors; Sept. 5, 2005 on myths of matter management software; Jan. 24, 2006 on options valuation and tracking; as well as Feb. 4, 2007 on Honeywell and its patent and trademark databases.).

In document search, some software locates documents based on concepts whereas some uses linguistic analysis. I am not competent to evaluate the two approaches against each other, but I will give my understanding of the basic difference.

Semantic-search software takes significant words in a set of documents and looks at every other such word in the set. It draws conclusions about what documents are related to each other according to the frequency with which certain words show up in proximity to other words. The software builds up relationships so that it can link one document to another based on those proximity and frequency connections. A leading vendor of such search software is Attenex with its Attenex Patterns 4.0. I appreciate the assistance of Attenex’s Michael Korch, who sent me material on this topic, but all errors are my own.

By contrast, with linguistic-concept software humans have identified and defined the key words in a collection of documents. One of the leading vendors of this approach is Cognition Technologies with CognitionSearch. Cognition Technology’s linguists have spent years compiling a linguistic analysis of the English language (think of it as a dictionary) which handles almost the entire common English language. With this work done, Cognition no longer needs new human work to handle a particular document base. If a new terminology has to be learned, such as specialized terms or company-specific product names, the software learns it automatically. CognitionSearch uses computational linguistic science to analyze a hierarchy of meanings of a word (ontology), all the forms the word might take (morphology), and a thesaurus of related concepts (synonymy). I appreciate the advice of Brian Maser of Cognition for this summary.

By contributing author Brad Blickstein, Blickstein Group, on legal service providers:

Consolidation in the electronic discovery industry has been a foregone conclusion for a long time, although a walk through the LegalTech show last month would contradict the theory. We all think it’s bound to happen as corporations take more control of the discovery process.

One example was announced on March 1: Merrill’s purchase of LextraNet. (Both companies are private; no financial terms were disclosed.)

By contributing author Brad Blickstein, Blickstein Group, on legal service providers:

It seems that legal service providers, especially in process-heavy areas like e-discovery, come from three different schools of technology selection. There’s the “agnostic” school: “We may have our favorites, but we can work with anything.” There’s the “build it” school: “We use our own technology.” And finally the “preferred partner” school: “These are the partners we work with all the time.” Many are a combination.

Each has its advantages and disadvantages. Agnostics claim that they can best work with technology you already like–or they can recommend the “best in breed”–but it may be hard to know which firm to hold accountable. Builders can be held fully accountable, but their technology may not be as good as some provided by a company that specializes in building those applications. Partners seem like a good compromise, but very often companies choose their partners not only for quality but also for financial reasons (e.g. revenue sharing arrangements).

As a consultant to legal service providers, I am frequently asked to help them enunciate their product’s or service’s return-on-investment. Sometimes this is a formal project, where we create sophisticated ROI calculators; sometimes it’s just helping them to better talk about their value proposition. Almost always, part of the return comes from saving time spent by in-house counsel.

Historically, this time has been valued at an “in-house counsel hourly rate,” basically the annual fully-loaded compensation of the average in-house counsel, divided by 2000 hours. I’ll argue, however, that any time saved by in-house counsel is actually worth the average hourly rate paid to outside counsel, since more efficiency in-house should always result in less overflow work going outside.

Since outside counsel almost always cost more than inside counsel, your technology and other initiatives may be worth more than you think. [Brad Blickstein, Blickstein Group, on legal service providers]

Along with the requirements definition phase (See my post of July 15, 2006.), the traditional next step of IT staff and consultants when they choose software is to extrude a request for proposal. The RFP outlines the presumed requirements of the department for the software. It is more detailed than a request for information (RFI).

Unorthodox I may be, but my view is that RFPs consume far more time and cost and effort than they return in insights. Their pages of questions put vendors through agonies and then spill out in an enormous matrix that makes it difficult to narrow down the list of candidates.

A better procedure is to pick a handful of crucial aspects of the system and, after having seen initial demos, ask the vendors to respond in just those few areas and with thoughtful, complete responses. You can do this process two or three times as you narrow down what is important, set priorities and scale those attributes, and come to realize what few important factors differentiate the contenders.

Heresy it may be, but I question the galvanic twitch to start every software selection with a requirements definition. If your department wants to choose software, this step sucks up much time and money in interviews or focus groups. Yet many in-house counsel do not even know what their requirements are other than very high level notions that any consultant would already understand. It is also difficult to reconcile conflicting requirements, especially if one person – particularly a senior lawyer – staunchly advocates a particular “need.”

Third, even if you can catalogue and reconcile all of your requirements, if you ask vendors whether they can comply they often say they can – they don’t spell out the cost, difficulty, or timing of those customizations or workarounds. And after the dust clears many of the capabilities of software systems languish unused. Why bother to ask about gourmet cravings if people stick to meat and potatoes?

At least consider a different approach. Designate a short-list of plausible vendors and spend ample time on demonstrations and discussions with a few contenders. Then people in the department actually have a better sense of what the systems look like and can do.

The most effective training for lawyers is one-on-one right at the time they bump into a problem. For example, if a lawyer wants to customize a report in a matter management system, how better than to walk the lawyer through the steps in hands-on training? Immediacy, relevance, and personalization best imprints learning – but it is costly. As a side note, if lawyers practice with their own data – with due regard to keep the original data intact – they tend to retain the lessons longer.

A variation is peer training. I always learn when I watch someone else use a program. Often, it has never occurred to me to handle some function the way they do, such as Control V in Word for Paste (I always use a right click on the mouse or the Paste icon on the tool bar).

Next most effective is training for small groups of lawyers or paralegals or administrative assistants. It is better to keep people of the same level together, not mixed with bosses or reports, so that they feel comfortable asking questions and focusing on concerns of their level.