• using the right terminology; and

• at making sure that the technical and legal bits of the contract actually work together.

This time, I’ll make a few suggestions about how one should actually write the substance of a technical schedule or a statement of work.

Use the active voice

It’s important to understand that what you are writing is, in essence, a set of obligations. So, it’s very important to be completely clear whose obligation is whose.

I often see these documents written partially or even entirely using the passive rather than active voice i.e. “X will be done” or “X needs to be done before Y can be done”.

The passive voice may feel more natural or elegant, or even somehow more “official”, but it leads to ambiguity and you should avoid it wherever possible.

It is almost always better to write using the active voice i.e. “the Supplier will do this” or “the Customer must do X before the Supplier can do Y”.

That way, there can be no misunderstanding or ambiguity about who needs to do what.

Spell it out, even if it seems obvious

When you’re in the weeds on a project, some things may seem so completely obvious to you that they go without saying. That, however, is rarely the case.

It is always a good idea to ask yourself whether someone picking up your work in three or five years’ time, without any of the background knowledge that you have, could readily and unambiguously understand what you have written and what it all means.

For statements of work in particular, especially if it is to be one in a series as part of a larger project, I like to have a background section setting out what has happened previously on the project, what is happening next, and how the instant statement of work fits into it all.

Headings are your friend

This seems like a small thing, perhaps even a blindingly obvious thing, but you should break up your work into small sections, and give each section its own heading. Then, break it down even further.

Two or three layers of sub-headings can be very helpful, both to provide a framework for you to organise your thoughts around, and to give the reader clear signposts on the structure of your document.

One thing at a time

I see a lot of service descriptions and (especially) statements of work that jump around subject areas, sometimes even from one sentence to the next.

You will have a much better document if you stick to one subject per section. If you feel like you need to deal with multiple subjects in one section, that is a sign that you need another layer of sub-headings!

Begin at the beginning, and when you get to the end, stop

Related to the previous suggestion, you should define the structure of your document at the outset, and then clearly and methodically stick to that structure.

For instance, as a high level guide, you might structure a statement of work for a professional services engagement like this:

• A background section explaining how you got to where you are and what you’re now looking to achieve. You can also use this section to identify the agreement under which the statement of work is made.

• A section setting out the activities the supplier is going to perform, and the timetable (or estimated timetable) for their performance.

• A section setting out the deliverables which will be the end result of the supplier’s activities.

• A section setting out the dependencies the supplier has on the customer, what the customer needs to do, and what happens if they don’t.

• A section setting out the assumptions the supplier is making, and what happens if they aren’t true.

• A section setting out how any acceptance testing or review period will work.

• A section setting out the commercials; pricing, rate cards and so on, and any conditions to the supplier getting paid (e.g. acceptance of a deliverable or achievement of a milestone).

• A section setting out how change will be handled.

• A section setting out any project management matters, like regular governance meetings.

Practice makes perfect

There is a real art to writing these kinds of documents, and it takes a lot of practice to do it well. I’ve done loads of them over the years, and I’m still learning and (hopefully!) improving with every project.

Anything else?

These suggestions are just my thoughts, and they are just suggestions. You may very well have different ideas, or additional tips.

Do ping me on LinkedIn if you have something to add!