[legalxml-econtracts] Scenario: Law Firm Contract Creation andNegotiation

[Jason Harrop <jharrop@speedlegal.com>]

Hi

Please find attached a scenario which seeks to explain the law firm 
interest in our TC.

Comments are welcome.  Also, please feel free to distribute this 
document to people in law firms who are not members of our TC but may 
have an interest in our work.


cheers,

Jason




-- 

Jason Harrop
CTO, SPEEDLEGAL
jharrop@speedlegal.com

Melbourne
Mob +61 (0)402 02 66 34
Tel +61 (0)3 9670 0141
Fax +61 (0)3 9670 0142
www.speedlegal.com

SmartPrecedent(R) software
The most intelligent way to create documents

Title: OASIS LEGALXML ECONTRACTS TC - SCENARIO

OASIS LegalXML eContracts TC Requirements Process

Scenario - Law Firm Contract Creation and Negotiation

Name	Law Firm Contract Creation and Negotiation
Principal Stakeholders	Law firms
Scenario Owner	Jason Harrop, jharrop@speedlegal.com
Draft Number	2
Draft Date	16 January 2003
Contributors	Barry Hansen, bhansen@imany.com

Introduction

This document is a scenario developed as part of the eContracts requirements process.

The purpose of a scenario is to provide a context for a set of requirements important to some group of end-users (in this case, law firms). A scenario is intended to help members of the working group to understand the drivers behind stated requirements.

To that end, this document contains a Scenario Statement, and a set of Requirements extracted from the Scenario Statement.

As per the requirements process, contributions to this scenario are welcome. Please send your contributions to the Scenario Owner. The Scenario Owner will decide whether to accept your contribution or not. If your contribution is not accepted, you may create your own Scenario. For further details, please refer to the eContracts Requirements Process document

Scenario Statement

Law firms are currently re-evaluating their document processing strategies in light of Microsoft's announcement that the forthcoming release of Microsoft Word will be fully XML enabled (see for example http://www.microsoft.com/presspass/press/2002/Oct02/10-22Office11Beta1PR.asp). This scenario identifies some possible outcomes which an XML contract format could deliver law firms and their customers.

A lawyer (or solicitor) will typically come to be working on a contract in one of two ways:

1. their client instructs them to draft a contract which documents a deal

2. their client presents them with a document the other party (or one of the other parties) has prepared

In either case, someone created an initial draft of the contract, a series of subsequent drafts were produced, and in due course (all going well), a final document acceptable to all parties is ready for signature.

The initial draft will often be “cut and pasted” from an existing contract. Sometimes this existing document is a “precedent”, which a lawyer can expect to be of a high quality as a result of some precedent maintenance process.

A draft contract is a version produced by the lawyer and provided to his/her client for review. (Typically the client is actively discouraged from amending a draft – amendments made by a client are best seen as instructions to the lawyer.)

A draft may or may not be provided to the other side (or sides).

So, the business of the lawyer is to get from the starting point (ie a blank page, a precedent, or the other side's draft) to a result his client is satisfied with, with as little pain as possible. This means negotiating favourable (or at least acceptable) terms, and reflecting those terms accurately in the words of the contract, in an efficient manner.

Currently, most lawyers produce contracts using Microsoft Word (97 or later). Some still use WordPerfect.

The vision for XML contracts is to improve significantly on today's typical contract production process.

Improved Document Quality

It should be possible to improve the quality of a draft contract per unit of effort.

Quality has several aspects to it:

1. “legal quality”: degree to which the contract reflects the intent of the drafter, and is enforceable etc. All the terms you expect to see in the contract are actually there (for example, is a governing-law clause present?).

2. “document integrity”:

1. all the bits of the document which need to be there are included, for example, the parties, the terms, the execution/signature block
2. all terms are defined, all defined terms are actually used, there are no circular definitions
3. internal cross references are correct, and references to other documents are accurate.

3. “formatting quality”: in a word processor sense, how well formatted the document is. A significant amount of time is wasted applying formatting to headings etc, and re-formatting drafts received from other parties.

XML contracts should deliver improvements in each of these areas.

It must be possible to produce the vast majority of “formal” contracts currently produced in law firms. This means cover pages, table of contents, headers and footers, pictures, tables, equations, and arbitrary contents in schedules and annexures. Automatic numbering and cross-references should be supported, so the lawyer does not need to number the clauses, or worse, re-number them after a clause is inserted.

Put another way, it should be possible to convert most legacy contracts into the eContracts XML format, without loss of content. It is acceptable for the formatting to be handled by a stylesheet (ie in accordance with the practice of separating content from style), provided the stylesheet can capture the format adequately.

(TO DO: Example contracts to be provided)

Some contracts take the form of paragraphs in a letter. It would be good if eContracts can cover these informal contracts as well.

Second, it must be possible to enforce a consistent firm style across all contracts. For example, all exclusions of liability appear in capital letters.

Third, it must be possible to deliver the contract in various popular formats, including RTF, PDF, and XHTML.

Better Negotiation Support

As successive drafts are produced, the wording of various clauses will change, and some clauses will be added/removed.

The lawyer needs to keep track of the state of each clause, and manage the process to an acceptable final state.

It should be possible:

• to see the status of a clause (agreed, acceptable, not acceptable, amedments proposed etc)

• to identify the changes between different versions of a clause

• to capture the reasons for a change (audit trail / requirements traceability).

Word processors do not do a good job at any of this.

As law firms adopt Word 11 and use its XML features to draft contracts, law firms will increasingly send their draft contracts to their client and the other parties, in XML (rather than RTF, DOC, or PDF). Alternatively, their client and the other parties will see the document in a shared workspace. In either case, it must be possible to provide an instance of the XML contract which does not contain any sensitive information, and which the other party can work with.

Risk Management

When a law firm drafts a contract covering say infrastructure or finance worth $1 billion, it obviously exposes the law firm to more risk than a contract with a value of say $100,000.

The drafting process must address the risk. By capturing the value of the contract in the document, the workflow can automatically adapt to the value of the transaction (for example, by incorporating extra sign off steps).

Downstream processing

XML contracts should explicitly tag information which is necessary for the client's downstream applications.

For example, information regarding the parties, the commencement, term and renewal of the contract, must be tagged so that this can be automatically captured when the contract is fed into a contract management system.

Similarly, it is useful to capture the value of the contract, and any contract milestones.

Particular clients are likely to have their own systems, for which special information is required (ie information specific to an industry sector like insurance, finance, or construction). It would be useful if this information could be tagged in the contract so that it can be automatically extracted.

Knowledge re-use: Improved Drafting Efficiency

Firms will wish to store their precedent contracts in XML. Doing so enables the precedents to be managed more effectively. For example, if a piece of legislation changes, it should be possible to search for all contracts which contain a reference to that legislation.

Precedent contracts will often have additional text which guides a lawyer in their usage.

It should be easy to re-use existing precedent clauses in an XML contract. There is no reason to draft, say, a governing law clause from scratch.

Equally, XML contracts should encourage lawyers to submit original or impoved clauses, so other lawyers can re-use them.

Appropriate meta data must be captured, so it is easy to search across a library of existing clauses.

Archiving

A law firm will often need to locate its copy of a contract, possibly many years after it was signed.

It is obviously important that the document be in a format which is still readable, and it is expected that XML contracts will facilitate this.

Search

It is useful to be able to search by party, date, dollar value etc, as well as any other information which may have been tagged for the purposes of downstream applications.

It is also useful to search for contracts which contain a clause of a particular type (eg termination clause), or a clause containing a certain string of words.

Application / Tool Support

Lawyers must be able to create XML eContracts in the normal course of their daily practice.

XML eContracts must be supported by commonly available tools. Note: this need will be taken to have been met if the XML eContract format can be handled by Microsoft Word 11.

Summary of Key Benefits to Stakeholders

1. Better quality contracts produced more quickly
2. Streamlined contract negotiation
3. Integrate with client business processes
4. Improved knowledge re-use and precedent management

Requirements

The following requirements have been extracted from the Scenario Statement.

Important Note regarding Traceability: Why each requirement is important should be clear from the scenario above. If it isn't, the scenario or the requirements should be amended.

Functional Requirements

100. The document structure is flexible enough to represent the vast majority of “formal” contracts produced in law firms.

101. The document structure should be able to represent a law firm's precedent contracts.

102. The output document must be able to include

     1. cover pages

     2. table of contents

     3. headers and footers

     4. pictures

     5. tables

     6. equations

     7. arbitrary contents in schedules and annexures.

103. Automatic numbering and cross-references.

104. Formatting to be handled via a stylesheet, which typically will apply to a class of documents. The document author must not be able to change the formatting (ie override firm style) by applying formatting directly to a clause.

105. The document structure is flexible enough to represent “informal” contracts, for example, contracts which take the form of paragraphs in a letter together with somewhere to sign as acknowledgment.

106. Document meta-data to include:

     1. guidance notes for user.

107. Clause meta-data to include:

     1. clause type, so you can search for example for “governing law clause” or “termination clause”.

108. “document integrity”:

     1. eContracts schema enforces a document structure, ie all the bits of the document which need to be there are included, for example, the parties, the terms, the execution/signature block

     2. all terms are defined, all defined terms are actually used, there are no circular definitions

     3. internal cross references are correct, and references to other documents are accurate.

109. It must be possible to deliver a draft or the final XML eContract in various popular formats, including RTF, PDF, and XHTML, and the output in each of these formats should reflect the firm style.

110. It must be possible to deliver a draft or the final XML eContract in its XML format (ie as a single file which the recipient is able to work with)

111. Ability to keep track of the state of each clause (agreed, acceptable, not acceptable, amedments proposed etc)

112. Ability to identify the changes between different versions of a clause

113. Ability to capture the reasons for a change (audit trail / requirements traceability).

114. Markup the following:

     1. party name, party nickname, party contact details

     2. commencement date, term, expiry date

     3. renewal terms

     4. contract value

     5. contract milestones

     6. industry specific data

     7. other information used by contract management systems and other downstream applications

115. XML aware search

116. Re-use existing precedent clauses

117. Format to facilitate archiving

Non-Functional Requirements

200. Lawyers must be able to create XML eContracts in the normal course of their daily practice.

201. XML eContracts must be supported by commonly available tools. Note: this need will be taken to have been met if the XML eContract format can be handled by Microsoft Word 11.

Notes

Some of the things in this scenario may not be delivered by the XML contract schema per se. However, it should be possible to build tools which support the requirements, using XML contracts.