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:
-
their client instructs them to draft a contract which documents a
deal
-
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:
-
“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?).
-
“document integrity”:
- all the bits of the document which need to be there are included, for
example, the parties, the terms, the execution/signature block
- all terms are defined, all defined terms are actually used, there are
no circular definitions
- internal cross references are correct, and references to other
documents are accurate.
-
“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
- Better quality contracts produced more quickly
- Streamlined contract negotiation
- Integrate with client business processes
- 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
-
The document structure is flexible enough to represent the vast majority
of “formal” contracts produced in law firms.
-
The document structure should be able to represent a law firm's precedent
contracts.
-
The output document must be able to include
-
cover pages
-
table of contents
-
headers and footers
-
pictures
-
tables
-
equations
-
arbitrary contents in schedules and annexures.
-
Automatic numbering and cross-references.
-
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.
-
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.
-
Document meta-data to include:
-
guidance notes for user.
-
Clause meta-data to include:
-
clause type, so you can search for example for “governing law clause”
or “termination clause”.
-
“document integrity”:
-
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
-
all terms are defined, all defined terms are actually used, there are
no circular definitions
-
internal cross references are correct, and references to other
documents are accurate.
-
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.
-
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)
-
Ability to keep track of the state of each clause (agreed, acceptable,
not acceptable, amedments proposed etc)
-
Ability to identify the changes between different versions of a
clause
-
Ability to capture the reasons for a change (audit trail / requirements
traceability).
-
Markup the following:
-
party name, party nickname, party contact details
-
commencement date, term, expiry date
-
renewal terms
-
contract value
-
contract milestones
-
industry specific data
-
other information used by contract management systems and other
downstream applications
-
XML aware search
-
Re-use existing precedent clauses
-
Format to facilitate archiving
Non-Functional Requirements
-
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.
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.