Writing assumptions so a broken one is observable

An assumption is a condition your estimate depends on, which you believe is true, and which you have not verified. That last clause is what separates it from a fact. Once you verify it, it stops being an assumption and becomes a constraint or a requirement.

The estimate is conditional on every one of them, whether or not you wrote them down. Writing them down does two things: it makes the conditionality contractual, so a broken assumption triggers a re-estimate rather than a debate, and it surfaces the risks during the sales conversation, when the client is still in a mood to solve them.

Atlassian's estimation guidance lists documenting them among its best practices, on the grounds that cataloguing all assumptions made during the estimation process gives you reference points to adjust against as the project progresses. Reference points is the right phrase. An assumption is a marker you can later stand next to and say, this is the thing that changed.

The register does not have to be long. Six good entries beat thirty vague ones, because a long register is not read and an unread register cannot be invoked.

Here is the check. Hand the entry to somebody who was not in the sales conversation. Could they determine, on any given Tuesday morning, whether it is currently true, without asking anyone's opinion?

"Client provides timely feedback" fails. Timely is an adjective, and adjectives get arbitrated. "Consolidated written feedback within five business days of each delivery" passes, because on day six you point at a calendar rather than at a person.

"The API is well documented" fails twice over: it is a judgement, and it does not say what happens if it is not. "The vendor's REST API supports filtering orders by modified date, as documented on 14 March" passes, because it names a capability that either exists or does not.

"The client has a test environment" is nearly there but is missing the thing you need. Test environments exist in many degrees of usefulness. "The client provides a non-production environment with a copy of production data, refreshed at least weekly, available from project week one" is a condition you can check on a Tuesday.

The pattern is consistent: replace the adjective with a number, a date, or a named artifact. Anything left that cannot take one of the three is not an assumption, it is optimism, and it should either be investigated during scoping or converted into an exclusion.

The consequence field is the one that changes the conversation, and it is the one almost nobody fills in. "Each additional consolidated review round beyond the one included adds 6 hours and 3 business days" is priced in the document the client signed. Invoking it in week seven is arithmetic. Without it, invoking it is a request, and requests made under schedule pressure get refused.

The owner field has to be a person, not an organisation. "The client" is nobody. A named approver is somebody, and naming them during scoping is also how you discover that there are actually four approvers and the estimate assumed one.

The check point stops the register from being retrospective. An assumption tested only when it has already caused a problem was not managed, it was recorded. Put staging access on the week-one status agenda and its failure costs you a conversation instead of a fortnight.

Keep the condition and the consequence in separate fields even when it makes the sentence clumsy. They get read by different people at different times: the condition by whoever is checking, the consequence by whoever is invoicing.

Content will be supplied on time becomes: all final copy and imagery for the eleven templates listed in appendix B is supplied through the shared folder by 12 May. Consequence: each week of delay moves the launch date by one week and the fee is unaffected up to four weeks, after which remobilisation is charged at the rate card.

Requirements are stable becomes: the requirements document dated 3 April is the baseline; changes to it are handled through change control. This one is doing more work than it looks like, because it converts a vague expectation into a reference to a specific artifact with a date on it. Atlassian's guidance on requirements documents describes exactly this function, a single agreed statement of what is being built and what it must do that everything else is measured against.

One round of feedback becomes: feedback on each deliverable is consolidated by the named approver into a single written response within five business days. Conflicting instructions from different stakeholders are resolved by the approver before submission. That second sentence is where the hours actually go, and it is missing from most versions.

The environment is available becomes a named environment, a named access date, and a named person who grants it. And then the consequence, which for access problems is usually schedule rather than fee: the start date moves day for day.

Third-party behaviour becomes the hardest and most valuable one to write, because you are asserting something about a system you do not control. Name the vendor, the specific behaviour, the date you verified it, and what happens if it turns out otherwise. The full method for testing those before you quote is in estimating integration work you have not seen.

The register's job does not end at signature. It ends at handover, and between those two points it has to be looked at on a schedule, or it becomes a document that is quoted only during disputes.

Put it on the weekly status, as a standing item with three states per entry: holding, at risk, broken. Three states is enough. A traffic-light system with five states produces a debate about whether something is amber or yellow-amber, which is a debate about the register rather than about the project.

The instant an entry goes to broken, something has to happen the same day. A note to the owner, the consequence restated, and a decision about whether you are absorbing it, deferring it, or re-pricing. Absorbing is often the right answer commercially, and it is still worth recording, because an absorbed cost nobody sees is a discount the client never knew they received.

This is also where scope creep gets caught, and it is worth knowing what it looks like. Atlassian's description is that it rarely arrives as a dramatic demand and is usually a series of reasonable-sounding additions appearing after discovery, during the build and near the finish line. Reasonable-sounding additions are exactly the things a written assumption catches and a remembered one does not.

Retire entries as they resolve. An assumption that has been satisfied is closed, and closing it keeps the register short enough that people keep reading it. A register of forty items where thirty are historically satisfied is a register nobody scans.

Assumptions, exclusions and acceptance criteria are three views of the same boundary, and each entry belongs in exactly one of them. An assumption says: we believe this, and if it is false the price changes. An exclusion says: this is not in the price at all. Acceptance says: this is how we prove the thing we did build is done.

The commonest mistake is putting a hard exclusion into the assumptions list to soften it. "We assume no data migration is required" is not an assumption, it is an exclusion in disguise, and disguising it makes it weaker rather than politer. A catalogue of the ones worth stating explicitly is in the exclusions that prevent the disputes.

The mirror mistake is writing acceptance criteria as assumptions. "We assume the client will accept the dashboard" is not a condition, it is the deliverable. Acceptance is a separate section and it needs its own testable language, which for analytics work is harder than it looks and is covered in acceptance criteria for an analytics deliverable.

All three sit inside the same document and the same argument, which is set out end to end in scoping a fixed-fee statement of work. If you write these documents often, the register should be a template with the eight recurring entries already in it and blanks for the dates, which is what statement of work scoping produces.

One last habit worth forming. When a project goes badly, go back and read the assumptions register before you read anything else. In most cases the cause is sitting there, written down, unchecked since week two.