Skip to content

Assumptions and Constraints Register

At a glance

  • Purpose: Record what you are taking for granted, what limits you must work within, and what happens if either turns out to be wrong.
  • Use it when: From the first planning conversation onwards, and at every review. Every false assumption is a risk, so this register is a direct input to the risk register.
  • Owner: The project manager, with each assumption owned by whoever can confirm or refute it.
  • Related: Module 02 · Module 08 · Lab 04

How to use this template

  1. Read your brief, plan, and charter, and pull out every statement presented as fact but actually believed. "The IT office will approve within two weeks" is an assumption; a fixed launch date is a constraint.
  2. Write each assumption so it could be shown false. If you cannot imagine the contrary, it does not belong here.
  3. Classify each constraint by how negotiable it actually is — not as the brief describes it.
  4. Rate each assumption for damage if false, and sort. The riskiest assumptions are the ones to convert into facts this week.
  5. Transfer anything with high damage to the Risk Register with a response and an owner.

Field descriptions

Field What goes in it Watch out for
ID A reference (A1, C1) you can cite elsewhere Renumbering later; allocate in blocks
Statement The assumption or constraint, written so it can be tested Vague statements nobody can disprove
Type Time, cost, scope, quality, regulatory, technical, resource Missing regulatory — it is the one people forget
Flexibility (constraints) Fixed / negotiable with approval / influenceable Accepting the brief's word that something is "fixed"
Owner Who can confirm or refute it Naming the project manager for everything
Consequence if false (assumptions) or breached (constraints) What actually happens, in time, money, or quality "It would be a problem" — say how much of a problem
Warning sign The first observable signal A signal you would only see after the damage
Status Open / confirmed / refuted / closed Leaving confirmed items cluttering the list

Blank template

# Assumptions and Constraints Register — [Project name]

| | |
| --- | --- |
| **Owner** | [Who maintains this register] |
| **Last reviewed** | [YYYY-MM-DD] |

## A. Constraints

| ID | Constraint | Type | Flexibility | Evidence | If breached | Owner |
| --- | --- | --- | --- | --- | --- | --- |
| C1 | [The limit] | [Time/cost/scope/quality/regulatory/technical/resource] | [Fixed / negotiable with approval / influenceable] | [Where this came from] | [What happens] | [Who] |

## B. Assumptions

| ID | Assumption | Owner (who can confirm) | Damage if false | Cost if false | Warning sign | Status |
| --- | --- | --- | --- | --- | --- | --- |
| A1 | [Stated so it could be shown false] | [Role] | [High/Med/Low] | [Time, money, or quality] | [First signal] | [Open] |

## C. Open questions

| ID | Question | Who can answer it | Needed by | Impact if unanswered |
| --- | --- | --- | --- | --- |
| Q1 | [Question] | [Role] | [YYYY-MM-DD] | [What it blocks] |

## D. Contradictions found

[Where the brief says one thing and a conversation says another, record both and who
adjudicates. This section is often the most valuable part of the register.]

Worked example

From Lab 04, on the mobile banking application. Some of the bank's brief statements, classified:

Statement Constraint? Assumption? Why
"Launch before the end of the financial year" ✔ A date, set by the programme
"No supplementary budget will be requested" ✔ A cost limit, but negotiable with approval — someone owns it
"Meets the regulator's authentication requirements" ✔ ✔ A regulatory constraint and an assumption that the current requirements have been read
"The call centre will handle enquiries using existing staff" ✔ An assumption about capacity made without the call centre manager
"The core banking API is documented" ✔ Four-year-old documentation with two endpoints "subject to change"
"60% of portal users install within six months" An outcome, not a constraint — and the project does not own adoption

The register's most useful entries are the last three: each is a belief presented as a fact, and each becomes a risk with a price once written down.

Common mistakes

  • Mixing the two. A constraint is a limit you work within; an assumption is a belief that could be false. Putting them in one list hides which ones you can test.
  • Assuming the brief is right about flexibility. "Fixed budget" usually means "nobody has asked for more yet".
  • Assumptions that cannot be falsified. If no observation could contradict it, it is not an assumption.
  • No owners. An unowned assumption is nobody's job to confirm, so it will be discovered late.
  • Never reviewing. Assumptions become false as the project progresses; a register reviewed once is a snapshot, not a control.
  • Forgetting the regulatory category. Compliance assumptions are the most expensive ones to get wrong and the least likely to be on anyone's list.