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: identify them, log them in a register, validate them at the right ceremonies. That's reasonable inside a company running its own program of work, and 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. What follows is the definition, twelve examples with what each one bills at when it fails, and the sentences that go into the scope, on a worked $34,200 project.

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 puts that number on the record, which makes it a commercial section rather than a planning one and puts it in the scope of work, beside the deliverables and the price.

What are the types of project assumptions?

Most assumptions on client work fall into five kinds, and running down the list is a quick check that you haven't left a whole category unwritten:

• Client-supplied inputs. Copy, data, images and exports, in a stated count and shape, by a stated week.
• Availability and review. Who gives feedback, how fast it comes back, and how many rounds the fee includes.
• Scope and volume. The quantities the price was built on, such as templates, pages, records and variants.
• Technical access. The credentials, environments and existing systems your team needs to reach, and when.
• External dependencies. Third-party services and suppliers outside both teams whose behavior the plan relies on.

What are examples of project assumptions?

Good ones are specific, countable and about the client, and each one is only finished when you can say what it bills at if it fails. These twelve come from the scope for Ravenhill Ceramics Co., a tableware brand paying $34,200 for a twelve-week catalog migration and storefront rebuild, which the rest of this page follows:

Compare those with the ones in most templates, along the lines of stakeholders being available or resources being adequate. Nobody can be wrong about a sentence like that, and 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. Notice too how much of the table is about people rather than technology, since late copy and diffuse feedback cause more agency overruns than any technical surprise does.

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 and priced around, which makes it the one that can quietly move the size of the job after the fee is agreed.

A constraint is a limit that was already true on signing day, like a launch date fixed by a trade show. You priced it in rather than around, so it goes in the constraints section instead.

A risk is something that might happen. Give it a named trigger and a price and it has become an assumption in everything but the label.

A dependency runs the other way: it's something the client owes you by a date, and it belongs in a dated dependencies section of its own. If the condition is about the shape of what they hand you rather than when, and the shape is what moves the fee, write it as an assumption with a rate.

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. Both protect the fee, and they fail in opposite directions.

An exclusion is argued about when the client wants the thing you excluded, which makes it an ordinary purchase settled on the line between in scope and out of scope, painless if the exclusion had a rate written beside it. An assumption is argued about when what the client promised turns up in a different shape. Nobody is asking for anything new; there's simply more of the same work than the fee covered, which is a much harder conversation to open without a written number.

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. Most assumptions start life as something like the left-hand version below, and become usable once four things are added: a named party, a threshold you can observe, a date, and a rate.

On Ravenhill, the assumptions section of the signed scope is where the catalog got pinned down:

The rates turn background information into a working clause. Anyone can tell from clause 4.1 what happens to the fee if the catalog is bigger than expected, before anybody knows how much bigger, which is the only moment both sides can agree a number without feeling cornered. Clause 4.4 is the sentence most assumptions sections are missing: without it the list reads as context, and with it the awkward mid-project conversation was 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; the job was simply larger than the shape it was priced against.

Because clauses 4.1 and 4.2 were already on the page, the arithmetic took ten minutes. The 440 extra records came to $2,640 at $6, the 610 images to $5,490 at $9, and the change went to Priya that afternoon at $8,130 with two weeks added. She approved it in writing before the work started, because she could see how each half of the figure was reached.

That $8,130 is a little under a quarter of the original fee, on a project where nobody would have said the scope had changed. With the assumptions written as background, the agency is choosing between absorbing it and reopening a settled fee, which is the conversation most of the annual cost of scope creep is made of.

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. The log tracks which assumptions are still unconfirmed and who's chasing each one. What it can't do is settle money, because the client never signed it, so the useful version carries the rate from the scope in its own column. This is Ravenhill's at the end of week three:

Keep the log for everything still moving, and put the rows that touch the fee into the signed document with a price beside each. On most agency projects that's 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: what you'll produce, when, what you won't touch, and what it costs. The assumptions section is the one place the paperwork describes what the other party has to do for the price to hold, which is why it feels uncomfortable to write and why it's worth the ten minutes. Written with a count and a rate in the same sentence, it reads as an offer rather than a demand: 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