Document assembly: Difference between revisions
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{a|tech| | {{a|tech| | ||
{{Image|Self-adjusting thank you letter|jpg|[[nigel molesworth|Molesworth]]’s [[self-adjusting thank-you letter]], the first recorded instance of document assembly in legal history}} | |||
}}Not the [[Mediocre lawyer|lawyer]]-killing | }}Not the [[Mediocre lawyer|lawyer]]-killing disruptive [[legaltech]] that [[thought leader|thought leaders]] thought it might be way back in 2006.<ref>[https://doi.org/10.1093/ijlit/eal019 Darryl R Mountain: ''Disrupting Conventional Law Firm Business Models using Document Assembly''] International Journal of Law and Information Technology, Volume 15, Issue 2, Summer 2007, Pages 170–191. </ref> | ||
It is specified by IT folk who don’t understand the business | Its capabilities are limited, it costs a lot (no one has figured out a sensible model for how to price it... by document? by structure? by user?) it is difficult to implement, and it ''really just isn’t very good''. Candidly, it has barely evolved past its original invocation, by [[noble, fearless and brave]] legal pioneer [[nigel molesworth]], whose first prototype is pictured at right. | ||
It is specified by [[IT department|IT folk]] who don’t understand the business application, sold to users who don’t understand the technological benefits of automation, let alone the challenges sub-optimal legal language poses to that benefit, and is commissioned and configured by [[management consultant]]s who (a) don’t understand (that is, ''{{risk|fear}}'') the business application, (b) don’t trust (that is, ''{{risk|fear}}'') the legal users; and (c) are motivated to retain control of the process and quash any instinct for flexibility or creativeness by lawyers, whom they are trying to reconceptualise as mute users of overweening {{t|technology}} — that is to say, '''''[[user]]s'''''. | |||
===If document assembly is the answer...=== | ===If document assembly is the answer...=== | ||
| Line 10: | Line 12: | ||
“Document assembly: brilliant: saves time, reduces error, enforces standards, reduces costs.” | “Document assembly: brilliant: saves time, reduces error, enforces standards, reduces costs.” | ||
Before plunging | Before plunging your pinkly into those warm amber depths, it is worth being self-analytical for a moment. Consider ''what you already do'', what is wrong with it, and therefore by deduction ''what you are trying to fix''. It might surprise you. | ||
We take it as a given that you will say your processes are lengthy, un-standardised, expensive to maintain and prone to error. This may even be one of those rare things about which the organisation finds consensus. It may seem so self-evident that the firm’s usual period of obligatory bureaucratic introspection can be dispensed with. | |||
Resist this thought. For these things are relative, and you must judge them against your objective. If you are managing a one-off, $10bn risk, who ''cares'' how long, bespoke and expensive your legal document is, as long is it aids your management of that risk?<ref>It won’t, of course, but [[don’t take a piece of paper to a knife fight|that is another story]].</ref> | |||
A [[root cause analysis]] may help you get to the heart of the matter. | |||
If the subject matter is it quotidian, throughput high and the usual negotiation load light — [[terms of business]], say — then fix your contract form so it doesn't ''need'' automation. Genericise it. Cut out some of the [[verbiage]]. Drop an [[indemnity]]. Seriously, will you miss it? | |||
If heavily negotiated, then — firstly, same; see what you can simplify and strip out to save having to argue about it — but once you've done that, ask ''how much time will automating save''? A draft that takes 30 minutes to prepare in the context of a three-month negotiation, as is common for an {{isdama}}, is really not the problem you need to be solving. | |||
{{sa}} | {{sa}} | ||
*[[Reg tech]] | *[[Reg tech]] | ||
*[[Nigel molesworth]] | *[[Nigel molesworth]] | ||
{{ref}} | {{ref}} | ||
Latest revision as of 12:58, 11 October 2022
|
JC pontificates about technology
An occasional series.
|
Not the lawyer-killing disruptive legaltech that thought leaders thought it might be way back in 2006.[1]
Its capabilities are limited, it costs a lot (no one has figured out a sensible model for how to price it... by document? by structure? by user?) it is difficult to implement, and it really just isn’t very good. Candidly, it has barely evolved past its original invocation, by noble, fearless and brave legal pioneer nigel molesworth, whose first prototype is pictured at right.
It is specified by IT folk who don’t understand the business application, sold to users who don’t understand the technological benefits of automation, let alone the challenges sub-optimal legal language poses to that benefit, and is commissioned and configured by management consultants who (a) don’t understand (that is, fear) the business application, (b) don’t trust (that is, fear) the legal users; and (c) are motivated to retain control of the process and quash any instinct for flexibility or creativeness by lawyers, whom they are trying to reconceptualise as mute users of overweening technology — that is to say, users.
If document assembly is the answer...
The intuitive case is obvious:
“Document assembly: brilliant: saves time, reduces error, enforces standards, reduces costs.”
Before plunging your pinkly into those warm amber depths, it is worth being self-analytical for a moment. Consider what you already do, what is wrong with it, and therefore by deduction what you are trying to fix. It might surprise you.
We take it as a given that you will say your processes are lengthy, un-standardised, expensive to maintain and prone to error. This may even be one of those rare things about which the organisation finds consensus. It may seem so self-evident that the firm’s usual period of obligatory bureaucratic introspection can be dispensed with. Resist this thought. For these things are relative, and you must judge them against your objective. If you are managing a one-off, $10bn risk, who cares how long, bespoke and expensive your legal document is, as long is it aids your management of that risk?[2]
A root cause analysis may help you get to the heart of the matter.
If the subject matter is it quotidian, throughput high and the usual negotiation load light — terms of business, say — then fix your contract form so it doesn't need automation. Genericise it. Cut out some of the verbiage. Drop an indemnity. Seriously, will you miss it?
If heavily negotiated, then — firstly, same; see what you can simplify and strip out to save having to argue about it — but once you've done that, ask how much time will automating save? A draft that takes 30 minutes to prepare in the context of a three-month negotiation, as is common for an ISDA Master Agreement, is really not the problem you need to be solving.
See also
References
- ↑ Darryl R Mountain: Disrupting Conventional Law Firm Business Models using Document Assembly International Journal of Law and Information Technology, Volume 15, Issue 2, Summer 2007, Pages 170–191.
- ↑ It won’t, of course, but that is another story.