Assumption logs: the cheapest scope insurance an agency can buy

When an agency estimates a project, it makes dozens of assumptions without noticing. The client's API is documented. The content will be ready on time. There are 2,000 products, not 20,000. The client's IT team will provision environments within a week. Single sign-on uses a standard identity provider. Each of these shapes the number at the bottom of the proposal.

When one of them turns out to be wrong, the project gets harder and nobody can say exactly why, because the assumption was never written down. The team feels the effort increase, the client sees the same SOW they signed, and the conversation becomes about blame rather than about a changed fact.

Assumptions in many SOWs are written as vague comfort ("the client will provide timely feedback"). Those are nearly impossible to use as evidence. A useful assumption is testable: someone can look at it in month three and say whether it held.

The testable versions take slightly longer to write and save weeks of argument. They also tend to surface problems before signature, because the client reads "3,000 rows" and says "actually, it's closer to 40,000". That is a far better moment to learn it.

The SOW holds the initial assumptions. The log is the living version that the delivery team maintains. It does not need special software; a shared table works. Each row has:

• ID and the SOW section it supports, so it can be cited later.
• The assumption, written testably.
• Owner: who on the client or agency side is responsible for it holding.
• Status: holding, at risk or broken, with the date it changed.
• Impact if broken: a rough hours range and which deliverables are affected.
• Link to evidence: the email, ticket or message where it was confirmed or contradicted.

1. Who the approver is and how fast they respond.
2. When client content, data and assets arrive, and in what format.
3. Which third-party systems are involved, which versions, and whether sandboxes exist.
4. Data volumes for migration, imports and reporting.
5. Supported browsers, devices and operating systems.
6. Who provisions environments, accounts and access, and by when.
7. Accessibility, security and compliance standards the work must meet, named explicitly.
8. Languages and locales.
9. Who handles hosting, monitoring and post-launch support, and for how long.
10. How many stakeholders attend reviews, and who can change direction.

If your current template states half of these, it is better than most. If it states all ten testably, a large share of future scope conversations will be settled before they start.

A broken assumption is not a failure of the project. It is new information, and the log turns it into a clean change control event. When the client's data turns out to be 40,000 rows instead of 3,000, the PM does not need to argue that migration got harder. They point to A-07, show the CSV, and present an estimate for the difference.

Review the log at every milestone sign-off with the client present. Mark each assumption as holding or not. This turns the review into a shared check rather than an agency complaint, and it means broken assumptions are raised when they happen rather than discovered at the final invoice.

This is the most common objection we hear from sales leads, and it is mostly unfounded. Clients are not scared by assumptions. They are scared by surprises. A proposal that says "we have assumed your inventory API has a sandbox; if it does not, the integration estimate rises by 30 to 50 hours" signals experience. Procurement teams in particular tend to score detailed assumptions as lower risk, not higher.

Where assumptions do cause friction, it is usually because they read as a list of excuses: one-sided, vague and all about what the client must do. Write them as shared facts, give some of them to the agency as owner, and keep the tone neutral. The goal is a document both sides can check, not a pre-emptive defence.

The weakness of any log is that someone has to update it. TWINJAM's SOW parser extracts assumptions as boundary rules alongside deliverables and exclusions, then watches for messages and tickets that contradict them, such as a client mentioning a new identity provider or a data file far larger than assumed. The PM gets a private alert citing the assumption, and decides what to do.

Tool or no tool, the habit is what pays. Write assumptions you could test, assign each an owner, and check them at every milestone. It costs an hour per project and is the cheapest scope insurance an agency can buy.