I typically represent customers in contract negotiations with their upstream suppliers. That means I do lots of deals with many of the same names on the other side of the table, again and again (Microsoft, Oracle, IBM, etc.)
After over a decade of doing this, I notice that my clients really want the answer to two questions:
1. What are the market standard terms for the transaction?
2. What did we (i.e., the client) agree to in the past?
In big law firms, the answer to these two questions is all too often locked into silos. Either knowledge of past deals is hidden from software because it's buried in MS format binary files, or it's buried in someone's head. It's quite common to see intraoffice communiqués go out by email: "Has anyone done XYZ for ABC in the past?" You might get a few responses...or none at all. It's very spotty, and not a good way to build institutional knowledge. At some firms, there might be a Sharepoint or Lotus Notes "knowledgebase" (ugh!), but those are often next to useless and involve a lot of manual human overhead to maintain.
When people think of technologies to enable deal law practice, they often go straight for document assembly or document management. Document assembly and templating is a bore, IMO. It's an area that is already too full of competitors who are trying to solve problems that I don't actually have. Since I tend to represent customers, I don't usually get to create the first draft of the contract. I've actually built a custom document repository with some nice features (e.g., email dropboxes, etc.) but that's just housekeeping, IMO. The real magic lies elsewhere...
In my view, the "document-oriented" viewpoint is the wrong way to approach these problems. Instead, law firms and their clients should be looking ways to break down the document barriers and convert contracts into seamless, actionable data.
Litigation, and patent/corporate due diligence are currently ahead of my practice area in this respect. My practice area (commercial transactions) involves a completely different set of problems and skills, and is an emerging market for technology applications. I'm biased, but I think my practice is harder to commoditize than, say, searching through millions of emails to find phrase matches or potentially privileged communications.
Since leaving big law, I've worked with other lawyers to develop systems for extracting and archiving the information we need to answer the two big questions: What did the client do in the past, and what is everybody else in the market doing today?
Other areas where we use/develop technology in ways that big firms can't:
- Task assignment systems for delegating work to non-lawyers or offshore lawyers, while retaining a clear, auditable record of who did what. Think project checklist templates similar to Basecamp, but more focused on our use cases.
- Interfaces to our timekeeping APIs (Harvest and Freshbooks) for custom reporting/visualization on how we spend our time. This helps us accurately quote fixed fees for projects, and surfaces interesting data about role in the contracting process.
It's a really interesting area. If you're involved in it at all, get in touch with me. I love talking about it with people who "get it". I'm a coder and a lawyer, so I'm perpetually stuck in both (and neither) of the two worlds of law and coding.
Not much to add but to say it's great to read about people with both knowledge and a solid passion in what they do. I wonder how we can seek out these kinds of "big" problems and push energy their way rather than trying to create just more social fluff..
Re your comments document orientation. This is a very good point and one that I have given a bit of thought. Contracts do indeed consist of business data and should be treated as such. To create such data in Microsoft Word and keep it in Word documents is as criminal. But the problem is worse than that. Contracts are also business logic manifest in a completely useless format called human language. If you are interested you should check these links out: http://contracts.scheming.org/http://www.stefansen.dk/presentations/isola-contracts.pdf
I believe the ISDA contracts are pretty close to being so standardized as to lend themselves to this.
The problem with composing contracts from modular units is negotiations. You would need both parties to agree to work within a closed system of modules at the outset. Otherwise, you are right back to where we are today – everything is composed more or less ad hoc.
At the end of the day, contracts will always need interpretation. Contracts are simply a manifestation (in whatever form) of what two or more people expect to happen.
A purely top-down, closed-system approach will fail to cover all situations. Likewise, a bottom-up, arbitrary system will not lend itself to systemization.
Interestingly, this dynamic is quite old in the law. There are two major types of legal system: civil and common. Civil is a top-down system where a code of laws tries to anticipate every eventuality. Common is a bottom-up system where individual cases set precedent by analogy to future situations.
In practice, both systems tend toward the middle. Civil law systems still require judges to interpret specific application of the laws. Common law systems still require codified rules to maintain credibility/consistency.
Can you go into more detail about the tools you use?
This seems like a good opportunity (as a software product) for selling to smaller firms.