When to use an MSA with a SOW

Count the pages. The master services agreement published on this site is nine pages across twelve clause groups. The statement of work is four pages across nine sections, and it repeats almost none of them. The two documents share exactly one job, execution, and one topic that appears in both for different reasons.

That is the whole argument for splitting them. Everything negotiated once sits in the framework. Everything argued about per project sits in the project document, and the project document stays short enough that somebody actually reads it before starting work.

This is general information, not legal advice. Contract law differs by jurisdiction, and whether a particular structure or clause works where you are is a question for a lawyer admitted there.

One agreement, two documents

A master services agreement is a standing set of terms between two organisations. On its own it buys nothing and delivers nothing. The example here says so in its first clause: the agreement commits the customer to buy nothing and the supplier to deliver nothing, and work begins only when a statement of work is signed.

A statement of work describes one engagement. Scope, deliverables, dates, money, acceptance. It borrows the legal terms from the framework it names, and it can afford to be specific because nobody is renegotiating liability while writing it.

The two examples on this site are separate fictional engagements, not a matched pair, so the parties differ. What is comparable is their structure, and that is what the table sets out.

What the MSA carries

Read the framework example and every clause in it answers the same question: what is true no matter which project we are doing?

The intellectual property clause decides that background material stays with whoever brought it, that rights in deliverables pass on payment rather than on delivery, and that open source has to be disclosed. The confidentiality clause sets a five year survival period and a 24 hour breach notification. Warranties and liability set a professional standard of care, re-performance as the first remedy, a per engagement cap and the carve outs. Insurance is a table of covers with minimum limits and the evidence required. There is a dispute ladder with four timed steps before anybody can go to court, and a clause saying named people cannot be swapped out silently.

None of that changes when the next project starts, which is why it is written once. The clause US federal procurement rules would recognise here is the ordering principle rather than any single term: FAR subpart 11.1 puts performance oriented requirement documents ahead of detailed design ones precisely so the standing rules and the specific ask do not get tangled together.

What the SOW carries

The statement of work example is a claims database migration running 18 weeks. Its nine sections are almost entirely facts a court would never need to interpret and a project manager needs weekly.

Document control opens it: the SOW number, both companies, the effective date, the master services agreement it sits under with that agreement’s date, the term, and a named contact on each side. Then scope as five activities, five deliverables each with a format, an owner and the week it is due, a five phase schedule, and the money as four roles with a day rate and estimated days totalling $412,000 before GST.

The two sections that earn their place are acceptance and assumptions. Acceptance gives ten business days per deliverable and deems a deliverable accepted if nothing comes back, which converts silence into a decision instead of a stalemate. Assumptions lists five conditions the estimate depends on, including that the source data schema stays stable, and routes anything outside the defined scope to change control.

Section map

The table above is the two documents laid side by side, topic by topic, counted from the finished files rather than from a template. The pattern in the fourth column is the rule worth taking away: standing terms up, project facts down, and only two topics genuinely belong in both.

Term is the first. The framework has a three year term with rolling renewals; the SOW has an 18 week engagement. They are different clocks and confusing them is how a project ends up with no live agreement over it.

Money is the second. The framework holds the rate card in a schedule, fixes it for 24 months and then reviews it against the consumer price index plus two per cent. The project document holds the actual amount. Put the amount in the framework and every new engagement needs a variation.

Order of precedence and change control

If you write only one clause into the framework, write this one. The MSA example sets the order as: a signed variation first, then the statement of work for the engagement in question, then the agreement itself, then any schedule. It also states that terms printed on a purchase order, a quotation or a portal click through have no effect between the parties.

Two things follow. First, in that ordering the project document beats the framework, so a SOW that casually redefines liability actually does redefine it. That is a good reason to keep legal terms out of SOWs entirely. Second, the ordering is a choice, not a default. Plenty of frameworks put themselves above the project document instead.

Change control is the other half. The SOW example requires any change to scope, schedule or budget to be agreed in writing by both parties through a formal change request document, as specified in the master services agreement. That cross reference is only as good as the clause it points at. Before you copy that sentence, check that your framework actually defines a change request process, because a pointer to a clause that does not exist is worse than no pointer at all.

When one document is enough

The split costs something. Two documents means two signature events, two version histories and a cross reference that has to stay true.

One document is usually the better answer for a single fixed piece of work with no expectation of a second, for a small engagement where the framework would be longer than the job, and for any relationship where the other side will not negotiate a framework in reasonable time. A combined services agreement with the scope as a schedule is a perfectly ordinary shape, and the service agreement example on this site is that shape at 13 pages.

The split earns its keep from the second engagement onwards. Signing the framework once and then producing four page project documents is the difference between a week of legal review and an afternoon.

The pair of examples

Read the statement of work and the master services agreement together, then look at what neither of them repeats. If you want the short definition of each rather than the structure, the SOW and MSA question page covers that, and the sibling post on common contract clauses explains the framework clauses one by one.