They're important parts of many contracts, especially in the IT space where I do most of my work, and – rightly or wrongly – it often falls to technical or operational experts rather than lawyers to do a lot of the heavy lifting in writing and negotiating them.

Over the next few articles I will go into how one should structure these documents, and how to ensure that they work correctly together with their governing legal terms.

This time, however, I’ll go into the importance of terminology.

At the risk of stating the obvious, writing text to be included in a statement of work or a technical schedule forming part of a contract isn’t like writing in other contexts.

In many ways, it’s more like writing code than writing prose. Your precise choice of words can determine whether or not particular functions of the underlying legal terms are invoked in the correct way, or even whether they apply at all.

Here’s how that works.

Defined terms and why we use them

Most contracts include lists of defined terms with very specific meanings. For instance, a contract might define:

• “Supplier” as XYZ Limited, a company incorporated in England with company number 1234567 and which has its registered office at 123 Some Street, Anytown AB12 3CD

• “Services” as the services described in Schedule 2

• “Service Levels” as the service levels described in Schedule 3

It is a convention when drafting contracts to capitalise defined terms. Those defined terms are then invoked, in their capitalised form in the clauses of the contract in order to grant rights, or to impose obligations.

So, the contract might contain a clause that says:

The Supplier will provide the Services in accordance with the Service Levels.

That clause does not need to set out who the Supplier is, what the Services are, or where the Service Levels are defined. They are simply invoked by using the correct defined terms.

Know what terms have been defined, and use them

When writing the technical schedule or statement of work, it is very important that you know what defined terms the contract provides and what they mean.

Then, crucially, use them in the schedule or the SOW each and every time you describe or refer to the thing they define, so that the correct functions of the contract are invoked.

For instance, if the contract uses the defined term "Customer Dependencies" to refer to a set of things which the customer needs to do to enable the supplier to do their job, and those things are then to be listed out in a statement of work, you should make sure when listing them out in that statement of work that you also use the term “Customer Dependencies” to refer to them.

By doing that, you ensure that you are invoking the correct functions of the underlying contract (for example, by giving the supplier a let on time for delivery while it’s waiting for the customer to do what it needs to do).

If you instead talk about “prerequisites” or “Customer obligations”, you won’t necessarily be clearly and unambiguously invoking those functions, and you leave the question of whether or not those functions apply open to interpretation.

It feels odd - but do it anyway

It’s important to acknowledge that this is a very unnatural way of writing. One’s instinct is always going to be to reach for synonyms and different ways of phrasing things, and to avoid repetition.

 In most other contexts that’s fine, even good practice, but when writing something for inclusion in a contract it’s anathema.

It may sound stilted, even robotic, but consistently using the correct defined term greatly helps clarity of interpretation.

If you have a defined term of “Service Levels”, use it. Don’t assume that other terms like “agreed SLAs” or “KPIs” will be interpreted as meaning the same thing.

Understand the legal front end

This all of course pre-supposes that you are actually made aware of the terminology and structure used by the legal terms of the contract.

Technical and operational people are often kept at arm’s length from the legal “front end”, which is perfectly reasonable and understandable (it’s not really their job, and that’s what lawyers are for, right?).

However it does mean that, when they come to write the statement of work or technical service description that has to work with those legal terms, they simply don’t know what it is they are writing to work with.

I therefore think it's a good idea, before you put pen to paper, to get your deal lawyer to explain at a high level how the contract works, and to point you to the defined terms that are likely to be relevant to your work.

Something I’ve started doing on some deals I work on is putting together a “cheat sheet” of key terms, and things that the contract assumes the technical schedules or SOW will deal with, and providing that to the technical teams responsible for producing first drafts of the technical elements of the document suite.