<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Susskind on &#8220;The End of Lawyers&#8221;</title>
	<atom:link href="http://www.adamsdrafting.com/2007/10/23/susskind-on-the-end-of-lawyers/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.adamsdrafting.com/2007/10/23/susskind-on-the-end-of-lawyers/</link>
	<description></description>
	<lastBuildDate>Tue, 31 Jan 2012 01:23:03 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=abc</generator>
	<item>
		<title>By: Ken Adams</title>
		<link>http://www.adamsdrafting.com/2007/10/23/susskind-on-the-end-of-lawyers/comment-page-1/#comment-14720</link>
		<dc:creator>Ken Adams</dc:creator>
		<pubDate>Thu, 08 Nov 2007 13:21:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.adamsdrafting.com/2007/10/23/susskind-on-the-end-of-lawyers/#comment-14720</guid>
		<description>Nigel: I can’t speak for Susskind, but I don’t have an absolutist view of document assembly—I don’t foresee a Brave New World where all our drafting is done by machines. But I think that much drafting could, or should, be done by document assembly.
 
Now on to your points:
 
1. I suspect that you have more hands-on experience of document assembly than I do. But what I’ve seen and the glimpses I’ve been given of the imminent future indicate that the best document-assembly software is extremely versatile and is straightforward to use. The weak link in the system is now the human component, namely preparing the language that goes into the system—getting the logic down isn’t for everyone, and I suspect that that’s the source of most glitches. That’s why I’m now working closely with Business Integrity, developer of &lt;a href=&quot;http://www.business-integrity.com&quot; rel=&quot;nofollow&quot;&gt;DealBuilder&lt;/a&gt; document assembly software—adding my expertise to the mix would ensure that DealBuilder customers are covered when it comes to both the human component and the software component. 
 
2. It would be unrealistic to expect document assembly to allow you to produce a first draft that reflects all the terms of a complex transaction—at some point, it’s no longer economic to provide for additional permutations in a document-assembly template. But if you could produce in an hour a draft that includes 90% of what you need, you’d be much better off than you would have been had you prepared a draft by scissor-and-pasting it together from contract models. And of course addressing complexity takes people, not software—we’re talking about document assembly here, not artificial intelligence. But if you can draft a contract to reflect complexity, then you could just as readily draft a document-assembly template to replicate permutations of that complexity, subject to the economic constraints that I mentioned.
 
3 &amp; 4. Sure, deal documents can be voluminous. But that’s not an argument against document assembly. If anything, it’s an argument in favor.
 
Note that the key to successful document assembly is high volume—if you need to create a given kind of contract dozens, or hundreds, or thousands of times (the tipping point would depend on the kind of contract involved), you’d likely be willing to make the up-front investment in time and money to automate that contract. That’s why thus far DealBuilder software has mostly been used by large law firms and by major companies to generate sales documents. But another way to achieve the necessary high volume would be to offer to a broader audience versatile document-assembly versions of widely used business contracts. That’s something I’m currently exploring.
 
Incidentally, I think that an underappreciated feature of document assembly is its training function. You can annotate a document-assembly questionnaire to provide guidance regarding the factors that come into play in selecting among any given set of options. That sort of on-the-spot guidance is vastly more valuable than the same guidance doled out in a conference room or webcast, divorced from context.
 
Anyhow, I’m sure I’ll have occasion to revisit all these issues.</description>
		<content:encoded><![CDATA[<p>Nigel: I can’t speak for Susskind, but I don’t have an absolutist view of document assembly—I don’t foresee a Brave New World where all our drafting is done by machines. But I think that much drafting could, or should, be done by document assembly.</p>
<p>Now on to your points:</p>
<p>1. I suspect that you have more hands-on experience of document assembly than I do. But what I’ve seen and the glimpses I’ve been given of the imminent future indicate that the best document-assembly software is extremely versatile and is straightforward to use. The weak link in the system is now the human component, namely preparing the language that goes into the system—getting the logic down isn’t for everyone, and I suspect that that’s the source of most glitches. That’s why I’m now working closely with Business Integrity, developer of <a href="http://www.business-integrity.com" rel="nofollow">DealBuilder</a> document assembly software—adding my expertise to the mix would ensure that DealBuilder customers are covered when it comes to both the human component and the software component. </p>
<p>2. It would be unrealistic to expect document assembly to allow you to produce a first draft that reflects all the terms of a complex transaction—at some point, it’s no longer economic to provide for additional permutations in a document-assembly template. But if you could produce in an hour a draft that includes 90% of what you need, you’d be much better off than you would have been had you prepared a draft by scissor-and-pasting it together from contract models. And of course addressing complexity takes people, not software—we’re talking about document assembly here, not artificial intelligence. But if you can draft a contract to reflect complexity, then you could just as readily draft a document-assembly template to replicate permutations of that complexity, subject to the economic constraints that I mentioned.</p>
<p>3 &#038; 4. Sure, deal documents can be voluminous. But that’s not an argument against document assembly. If anything, it’s an argument in favor.</p>
<p>Note that the key to successful document assembly is high volume—if you need to create a given kind of contract dozens, or hundreds, or thousands of times (the tipping point would depend on the kind of contract involved), you’d likely be willing to make the up-front investment in time and money to automate that contract. That’s why thus far DealBuilder software has mostly been used by large law firms and by major companies to generate sales documents. But another way to achieve the necessary high volume would be to offer to a broader audience versatile document-assembly versions of widely used business contracts. That’s something I’m currently exploring.</p>
<p>Incidentally, I think that an underappreciated feature of document assembly is its training function. You can annotate a document-assembly questionnaire to provide guidance regarding the factors that come into play in selecting among any given set of options. That sort of on-the-spot guidance is vastly more valuable than the same guidance doled out in a conference room or webcast, divorced from context.</p>
<p>Anyhow, I’m sure I’ll have occasion to revisit all these issues.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nigel Madeley</title>
		<link>http://www.adamsdrafting.com/2007/10/23/susskind-on-the-end-of-lawyers/comment-page-1/#comment-14541</link>
		<dc:creator>Nigel Madeley</dc:creator>
		<pubDate>Wed, 07 Nov 2007 20:31:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.adamsdrafting.com/2007/10/23/susskind-on-the-end-of-lawyers/#comment-14541</guid>
		<description>Hmm.  Here&#039;s some reasons why I don&#039;t subscribe to that view:

1. The software just isn&#039;t that good - it takes a lot of time and effort to draft and mark up a complicated document so that a piece of software can produce a &#039;100%&#039; first draft (it&#039;s easier if you set your sights lower - say 70% - but then - guess what - a human has to check it and amend it to get it to 100%.  And how long have we been told that voice-recognition is on the way ... ?

2. People like to do complicated deals - the last one they did plus some other angle.  That takes people, not software.

3. Word processing allows everyone to say more and deals are more finely calculated (the influence of accountants?) so that more has to be said in the contract.  When I began in practice 25 years ago you could do a share sale contract in 30 pages - no more.  But then no-one then had to worry about pensions, European law or TUPE etc.

4. Governments pump out more and more law.  Lord Justice Carnwath recently asked the House of Lords to revise their practice direction that allowed their Lordships each to give an opinion - he pointed out that when the direction was made in the 1960s, no-one had heard of European Law and a year&#039;s legislation fitted into one bound volume.  Now it&#039;s several volumes - and shows no signs of slowing.</description>
		<content:encoded><![CDATA[<p>Hmm.  Here&#8217;s some reasons why I don&#8217;t subscribe to that view:</p>
<p>1. The software just isn&#8217;t that good &#8211; it takes a lot of time and effort to draft and mark up a complicated document so that a piece of software can produce a &#8217;100%&#8217; first draft (it&#8217;s easier if you set your sights lower &#8211; say 70% &#8211; but then &#8211; guess what &#8211; a human has to check it and amend it to get it to 100%.  And how long have we been told that voice-recognition is on the way &#8230; ?</p>
<p>2. People like to do complicated deals &#8211; the last one they did plus some other angle.  That takes people, not software.</p>
<p>3. Word processing allows everyone to say more and deals are more finely calculated (the influence of accountants?) so that more has to be said in the contract.  When I began in practice 25 years ago you could do a share sale contract in 30 pages &#8211; no more.  But then no-one then had to worry about pensions, European law or TUPE etc.</p>
<p>4. Governments pump out more and more law.  Lord Justice Carnwath recently asked the House of Lords to revise their practice direction that allowed their Lordships each to give an opinion &#8211; he pointed out that when the direction was made in the 1960s, no-one had heard of European Law and a year&#8217;s legislation fitted into one bound volume.  Now it&#8217;s several volumes &#8211; and shows no signs of slowing.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

