Over the course of the 150 years I’ve worked in the IT field (and boy, the early years with wooden computers and coal-fired disk arrays were tough) I’ve built up a truckload of ulcers dealing with varying degrees of poorly written documents.
While I’m not an attorney, I have argued with them many times, in many places, about many subjects, usually non-legal so I don’t get sued by one of them. I also come from a family of them, and it’s led to a dispersal of family resources, to put it mildly. Aside from that, I have worked with a great many of them on a wide variety of projects. From business and technical contracts, to SLA’s, to U.S. patent and copyright filings. Most of what I’ve provided below comes from roughly twenty years of compiling notes after reviews with real attorneys, of which none would ever want to go on record as having known me.
It’s amazing how many people, even Fortune 100 companies, still have trouble nailing down ALL of their external agreements into a standard format. If you do nothing else, narrow down your official documents to the fewest templates as possible. The fewer the better. If you end up with variation templates, strive to merge them into one template using conditional terms to include/exclude them from scope based on conditions described elsewhere in the document. You can use condition statements just like program code logic (e.g. “if project involves drug shipments or large quantities of explosives, then…”)
Generic Field References
In most contracts, the involved parties are called out in the very beginning, along with key aspects (materials, systems, target identities, etc.). In most cases, they are aliased as well. Aliasing is a form of cross-referencing which serves to alleviate two main challenges:
- Updating repeated references throughout the document while ensuring none are overlooked.
- Simplifying the reuse of a standard template with minimal effort.
For example, …
“This document describes the terms and conditions pertaining to the services being provided by ACME Corporation (hereinafter “Provider”) and Contoso Corporation (hereinafter “Customer”)…”
“The Active Directory Domain structure for the Customer will employ the following…”
It’s pretty straightforward, used extensively, and legally tested for decades as well. However, I still run into documents where they either repeat the name all throughout, or (even worse) mix the usage throughout. As attorneys often say (while golfing, drinking and adding to your bill) “use what’s been tested in court before inventing a new wheel“.
As with patent applications, which I’ve worked on a great many over the years, being too vague opens all involved parties up to unwanted deviations in direction and scope. Be specific enough to prevent unwanted “scope creep”. Be careful not to nail down your verbiage after only a few customers, since you may encounter “nice” and agreeable folks at first, and then face-plant on a nasty situation a few projects later. Leave some wiggle room, but at least set aside “In Scope” and “Out of Scope” sections to cover your hind parts.
As with U.S. patent applications, be specific enough to mitigate undesirable changes in scope, while not boxing yourself into a loophole situation. Try to think of all angles to the subject matter being discussed in each section and as a whole. After you edit the document, read it as though you are an asshole customer who thrives on getting over on loopholes. “You didn’t say you don’t do ___!” and so forth.
Format vs. Content
Many procedure authors focuse more on format than on content. It’s fine to worry about format, but content HAS to have a higher priority. HAS to. HAS to. HAS TO. When a disagreement ensues, the format will mean nothing unless it directly impacts the content. Think of it as a list of food ingredients. The font, line spacing, coloring, and so on, are not nearly as important as the actual ingredients. If the format makes it difficult to read and comprehend the content, that’s another issue. Making the ingredients pretty doesn’t really matter if the baby food contains antifreeze.
Reinventing the Wheel
If you want to start a new document template, don’t blindly search the web or use a canned template from within MS Word. Do not do that. Start with a document that has been reviewed from a legal standpoint. You might be surprised how many examples you have already, from software licenses, to managed services SLA’s, to subscription contracts, and so on. Take the best of each as they pertain to the nature of what’s being addressed (how’s that for legalese?)
Protect your Protection
Your legal document is a tool of protection. It protects you and your customer as well. Make sure that you keep a tight control over it. Lock it with whatever means exist, from password locking to version controls, and revision history, etc.