Project assumptions belong in the scope, not a risk log.

Project assumptions are the conditions you treat as true in order to price and schedule a project, before anybody has confirmed them. On agency work they nearly always describe something the client has to supply: final copy by a certain week, one named reviewer instead of a committee, admin access to a system, a data export in a shape your team can actually use. An assumption isn't a guess about the weather, it's a bet on somebody else's behavior, and the version that earns its place in a document carries a rate so that losing the bet produces a quote rather than a bad afternoon.

Most of what's published about project assumptions describes an internal artifact. You identify assumptions, log them in a register, track them, validate them, and review the register at the right ceremonies. All of that is reasonable inside a company running its own program of work. It's the wrong shape for an agency selling a fixed fee to somebody else, because a client never signs your risk log, and an assumption the client never saw can't decide who pays. So the rest of this covers the definition and the examples, and then the sentence you actually write into a scope, with a real $34,200 project underneath it.

What are project assumptions?

A project assumption is a condition your plan depends on that nobody has confirmed yet, written down so that the estimate stops looking like a single unconditional number. Every fixed price contains a stack of them whether or not you list them, because you can't price twelve weeks of work without believing quite a lot about what those twelve weeks will contain.

The reason to write them down isn't tidiness. A fee is a promise about a specific quantity of work, and that quantity only holds still if the inputs hold still, so when you quote a catalog migration for 1,900 products the 1,900 is doing as much work as the dollar figure. The assumption is where that number goes on the record instead of sitting silently inside your estimate, and a scope with no assumptions section has quietly agreed to whatever turns up.

That makes assumptions a commercial section rather than a planning one, which is why they belong in the same document as the deliverables and the price. A scope of work is mostly a list of what you'll produce with money attached, and the assumptions are the conditions that list was priced under.

What are examples of project assumptions?

Good ones are specific, countable and about the client, and they read as conditions rather than as hopes. These five cover most agency projects and are worth adapting rather than inventing from scratch each time:

• Final copy for all pages arrives by the end of week two.
• One named person consolidates feedback, and feedback comes back within five business days.
• Hosting, domain and admin credentials are available in week one.
• Product photography already exists and is usable at full size.
• The third-party services being connected keep their current documented interfaces.

Compare those with the ones that show up in most templates, along the lines of stakeholders being available or resources being adequate. Nobody can be wrong about a sentence like that, which sounds harmless and is exactly the problem, since an assumption that can't be falsified can't trigger anything either. The test is whether you could tell, on a specific Tuesday, that the assumption has failed. If two people would read the same week differently, the sentence isn't finished.

The other thing worth noticing is how much of that list is about people rather than technology. Late copy and diffuse feedback cause more agency overruns than any technical surprise does, and both are cheap to write down before the project starts.

An assumption that can't be falsified can't trigger anything either.

How are assumptions different from constraints, risks and dependencies?

An assumption is something you believe without proof, a constraint is a limit you already know is real, a risk is something that might happen, and a dependency is a thing that has to happen first. The published guides on this term all draw those same lines, and the lines are correct as far as they go.

The distinction that matters on a paid project is narrower than any of them. A constraint was priced in because you knew about it when you quoted, so it can't produce a change order later, while an assumption was priced around and is the only one of the four that can quietly move the size of the job after the fee is agreed. Risks and dependencies fold into that same test, since a risk with a price and a named trigger has become an assumption in everything but the label, and a dependency the client owns is an assumption about the client that happens to sit on your schedule. If it's about something they hand you, write it as an assumption and put a rate on it.

What's the difference between an assumption and an exclusion?

An exclusion names work you are definitely not doing, and an assumption names a condition that keeps the work you priced the size you priced it. The two get filed together because they both protect the fee, and they fail in opposite directions, which is worth knowing before you find out the hard way.

An exclusion is argued about when the client wants the thing you excluded. Copywriting sits outside the fee, the client asks for copywriting in week five, and the conversation is about whether to add it and at what price, which is an ordinary purchase settled on the line between in scope and out of scope.

An assumption is argued about when the thing the client promised turns up in a different shape than the one you priced. Nobody is asking for anything new, the work is the same work, and there's simply more of it than the fee covered. That conversation is much harder without a written number, because the client is quite reasonably thinking that they haven't changed a thing.

How do you write a project assumption a client can sign?

Name the condition, name who supplies it, and put the rate for the gap in the same sentence. Ravenhill Ceramics Co. sells glazed tableware and hired an agency to move its product catalog onto a new storefront and rebuild the front end around it. The scope ran twelve weeks for a fixed fee of $34,200, and the assumptions section is where the catalog got pinned down.

The rates are the part that turns this from background information into a working clause. A reader who never meets your team can tell from clause 4.1 what happens to the fee if the catalog is bigger than expected, and they can tell before anybody knows how much bigger it is, which is the only moment when both sides can agree a number without either of them feeling cornered.

Clause 4.4 is doing the second half of the job, and it's the sentence most assumptions sections are missing. Without it the list reads as context, and context gets treated as context. With it, the section has a consequence attached, and the awkward mid-project conversation has already been agreed to in week one. Writing the scope section by section puts that clause next to the vague version most agencies start with.

Who pays when a project assumption turns out to be wrong?

Whoever the document says pays, and on Ravenhill the document said the client did. The export landed in week three at 2,340 product records rather than 1,900, and 610 of those records came through with no image attached to them. Nothing about the brief had changed and nobody had asked for anything extra. The job was simply larger than the shape it was priced against.

Because clause 4.1 and clause 4.2 were already on the page, the arithmetic took about ten minutes. The 440 records beyond the assumed count came to $2,640 at the stated $6 rate, the 610 images came to $5,490 at $9 each, and the change went back to Priya the same afternoon at $8,130 with two weeks added to the schedule. She approved it in writing before the migration work started, because she could see how each half of the figure had been reached.

That $8,130 is a little under a quarter of the original fee, on a project where nobody involved would have said the scope had changed. Run the same week with the assumptions written as background and the agency is choosing between absorbing $8,130 of work and reopening a fee both sides thought was settled, which is the conversation that most of the annual cost of scope creep is actually made of. Neither option is good, and the second one damages the relationship more than the first one damages the invoice.

Is an assumption log still worth keeping?

Yes, and it does a different job from the clause, so keeping one doesn't get you out of writing the other. An internal log tracks which assumptions are still unconfirmed and who's chasing each one, which is useful on any project long enough for people to forget what they assumed in week one.

What the log can't do is settle money, because the client never signed it, and that's the point where the standard advice and the commercial reality come apart. Every guide ranking for this topic will tell you to maintain a register, and none of them tells you to print the rate in the client's copy, so agencies end up tracking assumptions carefully in a file that carries no consequence outside the building. Keep the log for the ones still moving, and put the small number that touch the fee into the signed document with a price beside each. On most agency projects that second list runs three to five lines, and it's the only part of your assumption practice the client ever needs to read.

Assumptions are the only section of a scope written about the client

Everything else in the document describes your side of the deal. The deliverables say what you'll produce, the schedule says when you'll produce it, the exclusions say what you won't touch, and the fee says what all of that costs. The assumptions section is the one place where the paperwork turns around and describes what the other party has to do for the price to hold, which is exactly why it feels uncomfortable to write and exactly why it's worth the ten minutes.

Written the way clause 4.1 was written, with a count and a rate in the same sentence, it also stops being a demand and starts being an offer: here's what we priced, here's what more costs, and you'll know the figure before we do the work. Docket is the part that comes after that sentence, turning the moment an assumption breaks into a priced request the client approves in writing on the record. A project scope filled in as a sample shows where the section sits in a finished document, a statement of work wraps the same list in dates and payment terms, and the change request form is what clause 4.4 becomes on the day the export arrives wrong.

Frequently asked questions