Anatomy of a SOW
Writing good Statements of Work, or “SOW”s is one of the most important keys to
success in any long term project. The structure it provides is often unseen
until well into projects that have gone off the rails in one way or another.
In this article, I’m going to walk through some of the things I’ve learned
about writing them over the course of several projects for different clients.
In the early stages of a project, well before a SOW is even drafted, you’ll often go through a “design study” phase. During that period, the main ideas for the What, How, and Why of the project get fleshed out in broad terms, but with enough detail that someone familiar with the field could read it and get up to speed quickly on your project.
SOWs are similar to design studies and whitepapers, but more contractual, and slightly less technical. They are usually meant as a bridge between you and your client to lay out the terms of what you’re going to build. While you may get along well with them now, the document you’re writing should be a clear guide for the off-chance that something goes wrong with either their expectations, or yours. If you’re prepared for that, by having written a good SOW, it’ll be much easier to manage those expectations, and keep everyone on track.
Authoring
Like your project, it is important to have a good skeleton laid out in advance, as that guides you through writing it. SOWs have a pretty standard structure, and once you’ve written one, you have a template for all of the rest of them you’ll ever write.
Sections
- Definitions
- Assumptions
- Abstract
- Purpose
- Deliverables
- Milestones
- Acceptance
- Budget
- Agreement
- Appendix
Definitions
Defining your terms helps to make sure that everyone is on the same page. Often with technical work, there is quite a lot of jargon, with subjective waffly meanings. By writing down what you mean, things become objective and the intent is clarified. That way you, and your client can speak on even terms, with a reduced chance of misunderstanding.
Assumptions
Writing down your assumptions helps to limit the scope of whatever you didn’t expect. And surprises always show up when you least expect them (Ha! Imagine that!) so it’s best to prepare for them as much as you can. By preparing for the unexpected, you’ll be giving yourself more room to negotiate later.
Abstract
Like any academic paper, it is useful to have a quick preliminary summary of what the project is about, and why it’s going to get built. This explains to the non-technical managers, sales-people, and finance-critters the Big Picture ™ of what you’re trying to accomplish. You’ll want this section to be short and concise in order to keep from losing their attention, but general enough to give them a working understanding of the project. Think of what you’d say in an Elevator Pitch, and put that in this section. Use keywords from your Definitions section, but don’t get too technical.
Purpose
This section is a good place to put the summary of the technical details. If the Abstract was the view from the plane at 10km staring down at the top of Everest, you’ll want this section to be right there at 8848m giving concrete details.
Deliverables
Deliverables are the bacon of a SOW, the raison d’être of a project. Often they are intermediate steps along the way to completion of a project, representing some modest amount of progress. Sometimes they are a finished product, other times they are a snapshot of development, or even a significant event like publishing a website or achieving successful bringup on a new piece of hardware.
Each deliverable should be something self-contained, with a clear purpose. If you can put a simple name on it, even better, because you’re going to be referring to it a lot.
Milestones
Milestones lay out the schedule of what is going to be built when, and by whom.
For a fixed-fee structured contract, it is a really good idea to structure the
delivery dates of each milestone such that they’re relative to the other
milestones they depend on. For example, if a farmer has two milestones, M0 and
M1, say, for raising a litter of piglets and delivering them to the butcher
once they’ve matured, then his M1 depends on M0. Since he’s done this many
times before, he knows it takes about 4 months to raise a piglet to maturity.
Instead of writing down in his SOW that he expects his Sow to give birth in
January, with delivery to the butcher in May, he should give an estimated time
for M0, and a relative time of M0 + 4mo for M1s delivery date. This
protects him from something he doesn’t have a lot of control over: when the Sow
delivers.
In a services organization, it isn’t advisable to promise too much about who specifically is going to be doing what work. Engineers are mostly interchangable, and frankly, your client shouldn’t care. On the other hand, it is good to clear up which parts of the project you will be implementing, and which parts of it your client needs to do. The Milestones table is a good place for that.
Acceptance
Acceptance criteria are the rubrics by which you measure completion of a project. It is critical that they be well defined, and objective so that you and your client can agree when Done is Done.
Sometimes projects call for the Acceptance Tests to be determined later in the project, instead of them being decided up front. That usually comes up when the experience of building each of the deliverables is thought to give more clarity on how to actually define “Done”. Be careful writing such an agreement however, since it lets some subjectivity and wiggle room in through the back door. While it may allow you more flexibility later, it comes with the price of allowing your customer to force scope-creep. Usually the latter overshadows any benefit of the former unless you’ve already developed a good working relationship with them.
Budget
The budget section of a SOW describes the payment schedule over the course of the project. Usually payments are contingent upon achieving milestones, and tied to making successful deliveries. Occasionally you might find a project where a “Pay for Performance” style of incentive is warranted. In those cases, it’s a good idea to negotiate up front what the limits are, so that neither party to the contract is surprised by having to pay too much / recieve too little respectively.
Agreement
Finally, the Agreement section is where the SOW becomes a contract, since this is where the signatures go. It’s important to get everyone on board with the all of the details before signing, so don’t sign your portion of it before you’ve achieved consensus with your client. A good way to protect yourself during this period, is to lock the document & track the changes. While Git is a good tool for that as far as developers are concerned, the finance and legal-critters tend to get scared off by it; better just use the tools in Microsoft Word to do that, it’ll make them happier. After all, a happy salesperson is a good ally to have: they will go to bat for you when you need them.
Appendix
Appended to the end of your SOW should be any supplemental materials that don’t fit well in the structure above. Refer to these in your descriptions where they provide useful insight that would otherwise take several pages to explain.