The Ordinary Review

Careful reporting on everyday money

Corporate

One Website Rebuild, Four Missing Sentences. What a Scope of Work Should Settle First

A rebuild that stalled for reasons nobody traced back to the engagement letter, and the four sentences that would have kept it moving.

Theodore Kranz|

A two-page printed scope of work document on a desk beside a laptop showing a half-built website, with a pen resting across one paragraph that has been under...
A two-page printed scope of work document on a desk beside a laptop showing a half-built website, with a pen resting across one paragraph that has been under...

The engagement that produced this case was ordinary in every respect that anyone noticed at the time. A regional distributor of commercial equipment hired a small consultancy to rebuild its website and connect it to the inventory system the warehouse already ran on, and both sides signed a scope of work that fit comfortably on two pages. Nobody argued about it. Eleven months later the relationship ended with unpaid invoices on one side, an unfinished site on the other, and a shared conviction that the other party had behaved badly. Almost none of what went wrong was a disagreement about quality.

The word "existing" did more work than anyone asked it to

The scope committed the consultancy to integration with the client's existing inventory system. That phrase passed inspection on both sides because each party read it against a different picture. The consultancy understood it as a connection to whatever interface the system already exposed; the distributor understood it as the warehouse counts appearing on product pages, by whatever route that required. The system in question exposed nothing usable, and the work of building a route cost weeks that no one had budgeted. A scope that named the system, named the method of connection, and said who owned the problem if the method turned out not to exist would have moved that discovery to week one, when it was still a planning question rather than a blame question.

This is the consequence people rarely trace back. The project did not fail at the integration. It failed three months later, over something else entirely, because the integration had already consumed the goodwill and the schedule buffer that the something else needed. Vague nouns in a scope do not usually blow up where they sit. They borrow time from the rest of the job.

Approvals have a name, a window, and a default

The second absence was quieter and more expensive. The scope said the client would review and approve designs. It did not say who at the client could approve them, how long the client had, or what happened if nobody answered. In practice, three people reviewed everything, two of them sporadically, and the owner reserved a final look that sometimes came a week after the other two had signed off. Each round reopened decisions the previous round had closed. A scope with a single named approver, a fixed review window measured in business days, and a stated default when the window passes turns that drift into a procedural matter rather than a relationship one. The consultancy's later contracts carried all three, and the difference showed up not in fewer disputes but in shorter weeks.

Set the two versions side by side and the thin one looks friendlier. It asks less of the client, commits nobody to a calendar, and signs faster. It also converts every ordinary scheduling delay into an unlogged, unpriced cost that the vendor absorbs until it cannot, at which point the vendor raises it, and the client hears a complaint where the vendor meant a fact.

Acceptance is a test, not a feeling

By month eight, the site worked. Whether it was finished was an open question, because the scope described deliverables and never described acceptance. The distributor kept finding things: a filter that sorted oddly on one browser, a form that sent to the wrong mailbox, a product category that nobody had mentioned until it was missing. None of these were unreasonable. Collectively they made completion a horizon rather than a date, and the final payment sat behind that horizon. A scope that defines acceptance as a written test, run against conditions both parties agreed to before the work started, gives both sides an end. It also tells the client exactly what to supply, and when, for the test to be possible.

The useful phrasing is dull and specific: the deliverable is accepted when it passes the listed checks on the listed devices, defects found afterward are handled under warranty for a stated period, and new capability found afterward is a change. That sentence ends more arguments than any amount of good faith, because it separates a bug from a wish while both parties still agree on which is which.

Price the change before anyone wants one

What the distributor and the consultancy never had was a mechanism. There was no stated hourly rate for out-of-scope work, no requirement that changes be written, no rule that work paused until a change was authorized. So additions arrived by email, were done out of politeness, and showed up on an invoice three weeks later as a surprise. A scope that fixes the rate, the form, and the authorization step in advance makes the first change request a two-minute transaction instead of a negotiation conducted under deadline. It is worth noting that scopes carry weight beyond billing: the Department of Labor is responsible for how workers are classified as employees or independent contractors, and a document that specifies outcomes rather than directing daily method sits on the right side of that line.

Practitioners who have written a few hundred of these converge on the same habits. Name the systems. Name the approver. Define done. Price a change before anyone needs one. Four sentences, added before the kickoff call, would have cost this engagement an afternoon and saved it the year.

More from the desk