How to scope a fixed-fee SOW that doesn't lose money

Overruns are usually attributed to delivery — the team was slow, the client was difficult, the requirements changed. Trace them and the cause is almost always earlier: the estimate never included the work, or the document never excluded it.

This is good news. Delivery discipline is hard to change and slow to improve. A scope document is a two-week habit change with immediate financial effect.

The failure pattern is adding up the parts of the work the team can picture and applying a buffer. Buffers hide the fact that nobody knows how long the unpicturable parts take, and they get negotiated away first because they look like padding.

Decompose until each line resembles something the team has actually done, then estimate those lines against measured velocity. Where a line has no precedent, do not buffer it — carve it out as a separate discovery phase with its own small fixed fee. A client will accept "we'll spend two days establishing this, then price it" far more readily than a large number with no visible basis.

Every estimate rests on things that must be true: content is supplied by a date, one round of feedback consolidated from all stakeholders, staging access provided in the first week, third-party API documentation accurate. These are known at scoping time and forgotten by week four.

An assumptions list does two things. It makes the estimate conditional in writing, so a broken assumption is a re-estimate rather than an argument. And it surfaces the risks during the sales conversation, when the client is still receptive.

Exclusions are the things a reasonable client would otherwise assume are included. Data migration from the legacy system. Training. Content entry. Post-launch support beyond the warranty window. SEO redirects. Accessibility remediation. Browser support below a stated version.

Naming them feels adversarial. It is the opposite: an exclusion found in week one is a conversation, and the same exclusion found in week nine is a dispute. Clients who read a thorough exclusions list generally conclude the provider has done this before.

"Client approves the design" is not acceptance criteria. "The client's named approver signs off in writing within five business days of delivery; feedback is consolidated into one round" is. The distinction decides whether a milestone can be invoiced.

Write acceptance per deliverable, in terms someone can test without a judgment call. Tie payment milestones to accepted deliverables rather than calendar dates — a date-based milestone can be reached with nothing accepted, which is how projects run three months past invoice.

The common and expensive mistake is quoting fixed fee on work that belongs in a band, because the client asked for a number and nobody wanted to explain a range.

Most agencies have a change control clause and have never issued a change order. The clause is not the problem; the moment of use is. Scope changes arrive verbally on calls, in the middle of a friendly conversation, and re-pricing feels petty.

Make it small and routine. A change record is three lines — what changed, the effort delta, the decision — sent the same day, with the option to absorb, defer, or re-price. Used routinely it stops reading as escalation and starts reading as competence.

Before a fixed-fee SOW is signed: the estimate decomposes to lines the team recognizes; unknowns are carved into a discovery phase rather than buffered; assumptions are written; exclusions are written; acceptance is testable per deliverable; payment is tied to acceptance; change control has a stated rate and a lightweight process; and one person who will actually deliver the work has read the whole document.