How do I track assumptions that could change a project plan?
Quick answer
Create a short assumptions register alongside the project plan. For each uncertain belief, record its owner, why it matters, how and when it will be checked, and what part of the plan could change. Keep confirmed requirements separate, and revisit assumptions at milestones or when relevant information arrives. If an assumption proves false, note the impact and agree on the plan change rather than quietly treating the old belief as fact.
The question, the details, the next step.
What belongs in an assumptions register, and how is it different from a requirements list?
An assumptions register records beliefs the plan currently relies on but has not confirmed. A requirements list records what the project has been asked or agreed to deliver. Keep them separate: a belief may later be checked and rejected, while a confirmed requirement should not be silently downgraded to a guess.
For each assumption, capture:
- A clear statement of the belief, written so it can be checked.
- The owner who will arrange or obtain the check.
- The validation method and a date or milestone for doing it.
- The likely impact if it is wrong, such as a change to timing, scope, cost, or dependencies.
- The trigger for revisiting it and its current status.
Example: “The draft review can be completed within three working days” is more useful than “review will be quick.” The first can be checked against an agreed review date. It is still an assumption until confirmed by the relevant people.
How do I make vague assumptions specific enough to track?
Write each one as a testable sentence, then ask: what evidence would make us keep, change, or reject it? Avoid hiding several uncertainties in one sentence.
For example, “The launch will be straightforward” is too broad. Break it into separate statements if the plan depends on them: “The required content will be approved by [date]” and “The team has capacity for the planned review.” Each has a different check and may have a different owner.
A copyable row is:
ID | Assumption | Owner | Check and due point | If wrong, plan impact | Revisit trigger | Status
Use plain status labels such as “open,” “confirmed,” “rejected,” or “revised.” “Confirmed” should mean there is a stated basis for treating it as settled, not merely that nobody has objected. If you cannot name a practical check, record that limitation and identify what decision-maker needs to assess the uncertainty.
Can you show how to use the register with a project example?
Suppose a team is planning a small internal training guide. These details are illustrative placeholders, not facts about a real project.
- A1 — Assumption: The draft can be reviewed within three working days. Owner: [review coordinator]. Check: Ask reviewers to confirm a review window by [date]. If wrong: Move the approval milestone or reduce the review scope. Trigger: No response by [date]. Status: Open.
- A2 — Assumption: Existing approved material can be reused. Owner: [content owner]. Check: Review the relevant material and confirm suitability by [milestone]. If wrong: Allow time to create or approve replacement content. Trigger: Material is unavailable or unsuitable. Status: Open.
At the next planning check, the team might learn that reviewers need five working days. Update A1 with the new evidence and status, then record the effect—for example, shift the approval milestone by the agreed amount or discuss another response. Keep a brief note such as “revised after review window confirmed” so the change is understandable later. Keep dates, owners, and decisions as placeholders until the team confirms them.
How often should I review it, and what should I do when an assumption changes?
Review the register when the project plan is reviewed, at milestones that depend on open assumptions, and when a stated trigger occurs. You do not need to revisit every item on every check-in. Focus first on assumptions whose failure could materially affect a planned decision or activity.
When new information changes an assumption:
- Update its status and add a short note about what changed and when.
- Compare the new information with the plan elements that depend on it.
- Identify options, such as adjusting timing, scope, sequence, or asking for a decision.
- Agree who will make or approve the change, then update the plan and tell affected people.
- Keep unresolved assumptions visible; do not present them as confirmed requirements.
The register helps surface uncertainty; it does not determine the right project trade-off by itself. If the evidence is incomplete or the impact is unclear, record what is unknown and bring the decision to the appropriate project lead or stakeholder.
A practical checklist
Separate unconfirmed beliefs from agreed requirements.
Write each assumption as a specific, checkable statement.
Name an owner, validation method, and due point or milestone.
Record the consequence if the assumption is wrong and a trigger for review.
Update status and note the reason when evidence changes.
Review affected plan items and agree changes with the appropriate decision-maker.
A few more useful answers
Should every assumption have a separate row?
Use separate rows when beliefs have different owners, checks, triggers, or impacts. Splitting them makes it clearer which part has been confirmed and which still needs attention.
What if nobody can validate an assumption yet?
Keep it marked as open, state what is unknown, and note who can decide how to proceed or when it should be reconsidered. Do not turn lack of evidence into confirmation.
Should I delete an assumption once it is confirmed?
Usually keep a brief record of its status and how it was confirmed, especially if the plan depends on it. This makes later changes easier to understand.