Assumptions Log:
A Practical Guide to Recording, Testing and Managing Planning Assumptions

An assumptions log is a practical management tool used to record, track, test and review the assumptions that an organisation, project, service or decision relies upon.

At its simplest, an assumptions log asks:

What are we assuming to be true, why are we assuming it, what happens if we are wrong, and who is responsible for checking it?

That makes it useful for project management, business planning, strategy, charity governance, public sector programmes, property development, construction, technology implementation, financial forecasting, risk management and board reporting.

Projects and plans often have to move forward before every fact is known. That is normal. The danger comes when assumptions are made silently, treated as facts, and never revisited.

PMI describes assumptions as factors that, for planning purposes, are considered to be true, real or certain without proof. That is why assumption management matters: assumptions allow planning to proceed, but they also carry risk if they prove wrong.

Used properly, an assumptions log helps organisations move from hidden uncertainty to visible, managed judgement.

What is an assumptions log?

An assumptions log is a structured record of the assumptions that underpin a plan, project, forecast, decision or strategy.

A typical assumptions log includes:

1. Assumption reference
2. Date recorded
3. Assumption description
4. Area affected
5. Reason for the assumption
6. Evidence available
7. Impact if wrong
8. Linked risk
9. Linked decision
10. Validation method
11. Assumption owner
12. Review date
13. Status
14. Outcome
15. Action required

The purpose is not to create another spreadsheet for the sake of it. The purpose is to make assumptions visible, testable and reviewable.

ProjectManagement.com describes an assumptions log as a tool used to capture and track assumptions and the work being done to validate them, including details such as the assumption description, reason, owner, status and updates.

A good assumptions log should help answer:

1. What are we assuming?
2. Why are we assuming it?
3. What evidence supports it?
4. What evidence is missing?
5. Who needs to validate it?
6. When must it be checked?
7. What happens if it is wrong?
8. Does it create a risk?
9. Does it require a decision?
10. Has the assumption now become fact, risk or issue?

The best assumptions logs are active management tools. They are not static lists.

What is an assumption?

An assumption is something treated as true for planning purposes, even though it has not yet been fully confirmed.

For example:

1. The supplier will deliver by the agreed date.
2. Planning approval will be received within the expected timescale.
3. A key employee will be available for the project.
4. The customer will provide information on time.
5. Interest rates will remain within a forecast range.
6. A grant will be renewed.
7. A software integration will work as expected.
8. Demand will remain at current levels.
9. Costs will increase by no more than the budgeted amount.
10. Stakeholders will accept the proposed change.

Some assumptions are sensible and necessary. Others are weak, optimistic or untested.

The key is not to eliminate every assumption. That is impossible.

The key is to know what the assumptions are, understand how important they are, and test the ones that matter most.

A useful assumption statement should be specific.

Weak assumption:

Supplier will be fine.

Stronger assumption:

The main supplier will deliver the required materials by 30 June, based on the lead time quoted in its proposal dated 15 May.

The stronger version is clearer because it identifies what is being assumed, when it matters, and what the assumption is based on.

History and development of assumptions logs

Assumptions logs developed from wider project management and risk management practice.

As projects became more structured, organisations needed better ways to record not only risks and issues, but also the assumptions sitting underneath plans, budgets, schedules and business cases.

This matters because assumptions often sit quietly inside plans. A budget may assume prices. A programme may assume resource availability. A business case may assume demand. A funding plan may assume renewal. A property project may assume planning timescales. A software project may assume user adoption.

If those assumptions are wrong, the plan may fail.

Project Management Knowledge explains that an assumptions log is required during the project lifecycle to understand what assumptions have been made, and that assumptions are pieces of information upon which project plans and decisions are made but have not been verified.

Assumptions logs are also closely linked to the concept of RAID logs, which record:

1. Risks
2. Assumptions
3. Issues
4. Dependencies

This approach became popular because projects rarely fail from one isolated cause. They fail when uncertainty, untested assumptions, unresolved issues and unmanaged dependencies interact.

The assumptions log therefore plays a specific role: it records what the plan is relying on before those assumptions become risks, issues or change requests.

Assumptions log, risk register, issue log and dependency log

These tools are related, but they are not the same.

Assumptions log

An assumptions log records things that are being treated as true but have not yet been fully confirmed.

It asks:

What are we relying on, and how will we check whether it is true?

Risk register

A risk register records uncertain future events that may affect objectives.

It asks:

What might happen, how likely is it, how serious would it be, and what are we doing about it?

An assumption can create a risk.

For example:

Assumption: The supplier will deliver by 30 June.
Risk: If the supplier does not deliver by 30 June, installation will be delayed and the project completion date may slip.

Issue log

An issue log records problems that have already happened or are currently affecting delivery.

It asks:

What has happened, what impact is it having, and what action is being taken?

PMI explains the distinction between risks and issues by noting that an issue has already occurred, while a risk is a potential future event.

The same logic helps distinguish assumptions from issues.

An assumption is something not yet confirmed.

An issue is something that has already become a problem.

Dependency log

A dependency log records something the project or organisation depends on.

It asks:

What do we need from someone or something else, and when do we need it?

A dependency may also be linked to an assumption.

For example:

Dependency: The landlord must provide access to the site by 1 July.
Assumption: Access will be provided on time.
Risk: If access is delayed, survey work and contractor mobilisation will slip.

Decision log

A decision log records important decisions made.

It asks:

What was decided, who decided it, when, and why?

Some assumptions require decisions.

For example, if a financial forecast assumes a 5% cost increase, the board may need to decide whether that assumption is prudent enough.

Why assumptions logs matter

Assumptions logs matter because many plans look more certain than they really are.

A spreadsheet can make a forecast look precise. A project plan can make a timeline look fixed. A board paper can make a decision look settled. A business case can make benefits look predictable.

But underneath those documents may be assumptions.

For example:

1. Customers will buy at the expected price.
2. Staff will have capacity.
3. Funding will be received.
4. Costs will remain within budget.
5. Suppliers will perform.
6. Stakeholders will support the plan.
7. Technology will work.
8. Regulations will not change.
9. Planning permission will be granted.
10. Demand will grow as expected.

If these assumptions are not recorded, they are easy to forget.

An assumptions log supports:

1. Better planning
2. Better risk management
3. Better governance
4. Better board reporting
5. Better forecasting
6. Better project control
7. Better stakeholder communication
8. Better decision-making
9. Better accountability
10. Better learning

It also helps avoid the dangerous phrase:

We assumed that would happen.

A good assumptions log forces the next question:

Why did we assume that, and did anyone check?

When to use an assumptions log

An assumptions log is useful whenever a plan relies on facts that are not yet fully confirmed.

Common uses include:

1. Project management
2. Programme management
3. Business planning
4. Strategic planning
5. Financial forecasting
6. Property development
7. Construction projects
8. IT implementation
9. Procurement
10. Grant applications
11. Charity governance
12. Public sector projects
13. Risk management
14. Scenario planning
15. Business cases
16. Investment appraisal
17. Change management
18. New product development
19. Service redesign
20. Board reporting

It is especially useful where uncertainty is high, decisions are material, and incorrect assumptions could affect cost, timing, quality, compliance, reputation or strategic objectives.

It is less useful if used as a dumping ground for every casual thought. The best assumptions logs focus on assumptions that matter.

Assumptions logs in different industries

SMEs and owner-managed businesses

For SMEs, assumptions are often made informally.

A business owner may assume:

1. A customer will renew.
2. A debtor will pay next week.
3. A supplier will hold prices.
4. A staff member will stay.
5. Demand will remain stable.
6. The bank will extend facilities.
7. A new service will sell.
8. Costs can be absorbed.
9. Cash flow will improve next month.
10. A system will save time.

These assumptions can have major consequences.

For example, a cash flow forecast may assume that large customer receipts arrive on time. If they do not, wages, VAT, supplier payments and loan repayments may become difficult.

For SMEs, the assumptions log should be simple and practical. It should focus on cash, customers, people, suppliers, systems and major decisions.

Manufacturing

Manufacturing businesses rely on assumptions about supply chains, production capacity, labour, quality, machinery and demand.

Typical assumptions include:

1. Materials will be available.
2. Suppliers will maintain quoted prices.
3. Machines will operate at expected capacity.
4. Labour will be available.
5. Scrap rates will remain within tolerance.
6. Customer orders will continue.
7. Delivery lead times will remain stable.
8. Energy costs will follow budget.
9. Quality standards will be met.
10. Maintenance downtime will be manageable.

If these assumptions prove wrong, the impact can be significant.

For manufacturing, an assumptions log should connect to production planning, stock control, supplier management, quality control, maintenance and cost forecasts.

Retail and ecommerce

Retail and ecommerce businesses make assumptions about customer behaviour, stock, pricing, delivery, returns and marketing.

Typical assumptions include:

1. Website conversion rates will remain stable.
2. Customer acquisition cost will stay within budget.
3. Stock will arrive before peak demand.
4. Return rates will remain manageable.
5. Discounts will increase volume enough to protect margin.
6. Delivery partners will meet service levels.
7. Customers will accept price changes.
8. Search demand will continue.
9. Marketplace rules will not materially change.
10. Customer reviews will support sales.

For ecommerce, assumptions can move quickly. A small change in conversion rate, advertising cost or return rate can materially affect profitability.

An assumptions log helps management understand which forecasts are evidence-based and which are optimistic.

Professional services

Professional services firms rely on assumptions about client behaviour, staff capacity, billing, deadlines and scope.

Typical assumptions include:

1. Clients will provide information on time.
2. Staff will have enough capacity.
3. Fees will cover the time required.
4. Scope will remain unchanged.
5. Technical queries will be resolved quickly.
6. Software will produce reliable data.
7. Key staff will remain available.
8. Client approval will be received by the deadline.
9. Work in progress will convert into billing.
10. Debtors will pay within agreed terms.

For accountants, solicitors, consultants, architects and advisers, assumptions logs can help manage client projects, recurring work, advisory engagements and internal change.

They are especially useful where deadlines and client dependencies matter.

Charities and voluntary organisations

Charities often rely on assumptions about funding, volunteers, service demand, referrals, staff capacity and partnerships.

Typical assumptions include:

1. A grant will be renewed.
2. Donations will remain stable.
3. Volunteers will be available.
4. Referral demand will stay within capacity.
5. A partner organisation will deliver its part of the service.
6. Staff costs will remain within budget.
7. Beneficiaries will engage with the service.
8. Trustees will approve a decision.
9. Reporting requirements will remain manageable.
10. Reserves can cover a shortfall.

For charities, assumptions can affect both financial sustainability and frontline impact.

An assumptions log should link to the risk register, reserves planning, funding strategy, service delivery and trustee reporting.

Public sector and local government

Public bodies rely on assumptions about funding, demand, policy, procurement, consultation, legal duties and delivery capacity.

Typical assumptions include:

1. Demand will follow forecast.
2. Government funding will continue.
3. Procurement will complete on time.
4. Contractors will deliver to specification.
5. Consultation will not materially delay the project.
6. Digital uptake will meet expectations.
7. Residents will use new channels.
8. Staff capacity will be available.
9. Legal powers are sufficient.
10. Savings targets are achievable.

In public sector work, assumptions need careful management because they can affect public money, statutory duties, residents, service users and political accountability.

An assumptions log can strengthen transparency and decision-making.

Property and construction

Property and construction projects are full of assumptions.

Typical assumptions include:

1. Planning consent will be granted.
2. Build costs will remain within budget.
3. Ground conditions will match survey findings.
4. Utilities connections will be completed on time.
5. Contractors will be available.
6. Interest rates will remain within appraisal assumptions.
7. Tenants or buyers will be found at forecast values.
8. Legal title issues will be resolved.
9. Access will be available.
10. Weather delays will be manageable.

A single incorrect assumption can affect programme, cost, funding, viability and stakeholder confidence.

For property and construction, the assumptions log should sit alongside the risk register, cost plan, programme, planning strategy, legal review and financial appraisal.

Technology and software

Technology projects often rely on assumptions about users, systems, data, integration, security and adoption.

Typical assumptions include:

1. Existing data is accurate.
2. Users will adopt the new system.
3. Integrations will work.
4. Supplier timelines are realistic.
5. Cyber controls are sufficient.
6. The platform can scale.
7. Training will be completed on time.
8. Legacy systems can be retired.
9. The product solves a real customer problem.
10. Support volumes will be manageable.

For software and digital transformation, assumptions logs are especially useful because technical confidence can sometimes hide business uncertainty.

The key question is not only:

Can we build it?

It is also:

What are we assuming about users, data, adoption, cost and value?

Healthcare and social care

Healthcare and social care organisations need to manage assumptions carefully because safety, quality and dignity matter.

Typical assumptions include:

1. Staffing levels will be sufficient.
2. Agency cover will be available.
3. Service users will respond to a new model.
4. Families will accept communication changes.
5. Digital records will be adopted properly.
6. Training will be completed by deadline.
7. Inspection requirements are understood.
8. Referral volumes will be manageable.
9. Commissioners will maintain funding.
10. Safeguarding processes will be followed.

In this sector, assumptions should never replace professional judgement or safeguarding processes.

They should support safe planning, workforce management, service quality and regulatory compliance.

Education and training

Education providers rely on assumptions about learner demand, funding, staffing, curriculum, employer engagement and outcomes.

Typical assumptions include:

1. Learners will enrol in sufficient numbers.
2. Funding rules will remain stable.
3. Tutors will be available.
4. Learners will complete the course.
5. Employers will provide placements.
6. Digital platforms will work.
7. Attendance will meet expectations.
8. Assessment deadlines will be met.
9. Accreditation will be retained.
10. Progression outcomes will be achieved.

For education, an assumptions log should link to learner outcomes, funding compliance, staffing, quality assurance and safeguarding.

How to create an assumptions log properly

1. Define the purpose

Start by deciding what the assumptions log is for.

It may cover:

1. A project
2. A business case
3. A forecast
4. A strategy
5. A funding plan
6. A construction scheme
7. A software implementation
8. A charity service
9. A public sector programme
10. A board decision

The scope matters.

An organisational assumptions log may focus on major strategic and financial assumptions. A project assumptions log may focus on delivery, timeline, resources, dependencies and stakeholders.

2. Identify assumptions

Assumptions can be found in:

1. Project plans
2. Budgets
3. Forecasts
4. Board papers
5. Business cases
6. Grant applications
7. Contracts
8. Emails
9. Meeting notes
10. Risk registers
11. Tender documents
12. Financial models
13. Strategy documents
14. Sales plans
15. Programme schedules

Useful prompts include:

1. What are we treating as true?
2. What has not yet been confirmed?
3. What would undermine this plan if it changed?
4. What are we relying on someone else to do?
5. What are we assuming about cost?
6. What are we assuming about timing?
7. What are we assuming about demand?
8. What are we assuming about people?
9. What are we assuming about funding?
10. What are we assuming about stakeholders?

Many assumptions are hidden in ordinary phrases such as:

1. This should be fine.
2. We expect that to happen.
3. That is already in hand.
4. They normally deliver on time.
5. We should be able to absorb that.
6. Demand should continue.
7. Approval should be straightforward.
8. The system should integrate.

These phrases are useful warning signs.

3. Write assumptions clearly

A good assumption should be specific, testable and linked to the plan.

Weak assumption:

Costs will be okay.

Stronger assumption:

Build costs will not exceed the current cost plan by more than 5%, based on contractor estimates received in May 2026.

Weak assumption:

Customer demand will be strong.

Stronger assumption:

At least 50 customers per month will purchase the new subscription package within six months of launch, based on current enquiry levels and pilot feedback.

The stronger versions can be tested.

4. Record the reason for the assumption

Every assumption should include the reason behind it.

For example:

1. Supplier quotation
2. Historic trend
3. Professional advice
4. Customer feedback
5. Market research
6. Contract term
7. Management judgement
8. Forecast data
9. Pilot result
10. Previous experience

This helps separate evidence-based assumptions from optimistic guesses.

An assumption based on a signed contract is stronger than one based on hope.

5. Assess importance

Not every assumption needs the same level of attention.

Assess each assumption by asking:

1. How important is it?
2. What happens if it is wrong?
3. Does it affect time?
4. Does it affect cost?
5. Does it affect quality?
6. Does it affect safety?
7. Does it affect compliance?
8. Does it affect reputation?
9. Does it affect customer or service user outcomes?
10. Does it affect the decision being made?

High-impact assumptions should be reviewed more carefully.

6. Link assumptions to risks

Many assumptions create risks.

For example:

Assumption: The grant will be renewed.
Risk: If the grant is not renewed, the charity may face a funding gap and need to reduce services.

Assumption: The customer will approve the design by Friday.
Risk: If approval is delayed, the project programme will slip.

Assumption: Existing data is accurate.
Risk: If data is incomplete or inaccurate, the system migration may fail or produce unreliable reporting.

Assumptions should not sit separately from risk management. They should feed into the risk register where appropriate.

7. Assign an owner

Each important assumption should have an owner.

The owner is responsible for:

1. Monitoring the assumption
2. Checking whether it remains valid
3. Gathering evidence
4. Updating the status
5. Escalating concerns
6. Linking to risks or issues
7. Closing the assumption when resolved

An assumption without an owner is unlikely to be tested.

8. Define validation action

For each significant assumption, record how it will be checked.

Validation may include:

1. Confirming in writing
2. Reviewing a contract
3. Obtaining professional advice
4. Testing with customers
5. Running a pilot
6. Checking supplier lead times
7. Updating a financial forecast
8. Reviewing market evidence
9. Confirming staff availability
10. Reviewing legislation
11. Testing data quality
12. Checking project dependencies

Validation turns assumptions into managed work.

9. Review regularly

Assumptions change.

An assumption that was reasonable at the start of a project may become weak later.

Review assumptions when:

1. A project milestone is reached
2. A budget is updated
3. A forecast changes
4. A risk increases
5. A supplier position changes
6. A stakeholder changes position
7. A decision is delayed
8. A contract is signed
9. A funding outcome is known
10. External conditions change

ProjectManagement.com notes that assumptions should be tracked along with the work being done to validate them.

That means review is not optional. It is the point of the tool.

10. Close or convert assumptions

An assumption should not remain open forever.

Eventually it should be:

1. Confirmed as true
2. Confirmed as false
3. Replaced by a new assumption
4. Converted into a risk
5. Converted into an issue
6. Converted into a decision
7. Closed because it is no longer relevant

This is where the assumptions log connects to wider project and management control.

Common mistakes in assumptions logs

Mistake 1: Not recording assumptions at all

This is the biggest mistake.

If assumptions remain hidden, they cannot be tested or challenged.

Mistake 2: Treating assumptions as facts

An assumption is not a fact.

It may be reasonable. It may be well informed. But until it is confirmed, it remains an assumption.

Mistake 3: Recording vague assumptions

Vague assumptions are difficult to test.

For example, “stakeholders will support the project” is too broad.

A better assumption would identify which stakeholders, what support is needed, and by when.

Mistake 4: No owner

If nobody owns the assumption, nobody will validate it.

Ownership is essential.

Mistake 5: No review date

Assumptions should be time-bound.

If an assumption matters to a decision, forecast or project milestone, it should have a review date.

Mistake 6: Not linking assumptions to risks

Incorrect assumptions often become risks.

If the risk is not recorded, the organisation may not prepare a response.

Mistake 7: Keeping old assumptions open

An old assumption can create confusion.

Once confirmed, disproved or irrelevant, it should be updated or closed.

Mistake 8: Only recording negative assumptions

Some assumptions relate to opportunities.

For example, a business may assume demand for a new service will grow. If that proves true, there may be an opportunity to invest, expand or reallocate resources.

Mistake 9: Not challenging optimism

Assumptions can reflect what people want to be true.

A good assumptions log should encourage challenge.

Mistake 10: Treating the log as administration

An assumptions log is not paperwork.

It is a tool for better decision-making.

Limitations and weaknesses of assumptions logs

Assumptions logs are useful, but they have limits.

They depend on honesty

People must be willing to admit what is not yet known.

In some organisations, assumptions are hidden because uncertainty feels uncomfortable.

They can become too long

If every minor assumption is recorded, the log becomes difficult to use.

Focus on assumptions that matter.

They can create false confidence

A neat log may make a team feel in control, even if assumptions are not being tested properly.

The value lies in review and validation, not the spreadsheet.

They do not remove uncertainty

Some assumptions cannot be fully confirmed in advance.

In those cases, the organisation must decide whether to accept the uncertainty, reduce it, transfer it or prepare contingency plans.

They require regular review

An assumptions log becomes stale quickly if not reviewed.

Old assumptions can mislead decision-makers.

They do not replace judgement

The log supports judgement. It does not make decisions automatically.

Leaders, managers, trustees and boards still need to interpret the information and act.

They may expose uncomfortable weaknesses

A good assumptions log may reveal that a plan depends on optimistic forecasts, unconfirmed funding, weak evidence or external parties.

That can feel difficult, but it is better to know early.

Assumptions log compared with other strategic and management tools

Assumptions log and risk register

The assumptions log records what is being treated as true.

The risk register records what could go wrong.

Incorrect assumptions often become risks.

Use the assumptions log to identify uncertainty. Use the risk register to manage the consequences.

Assumptions log and issue log

An assumption is something not yet confirmed.

An issue is something that has already become a problem.

If an assumption proves false and is now affecting delivery, it may need to move to the issue log.

Assumptions log and dependency log

A dependency is something needed from another person, team, supplier or organisation.

An assumption may be made about whether that dependency will be delivered.

Use the dependency log to track what is needed. Use the assumptions log to track what is being assumed about it.

Assumptions log and decision log

Some assumptions underpin important decisions.

A decision log records what was decided. The assumptions log records what the decision relied upon.

This is useful for accountability and later review.

Assumptions log and change log

If an assumption changes, the project may need a formal change.

For example, if a cost assumption proves wrong, scope, budget or timing may need to change.

Assumptions log and business case

A business case depends heavily on assumptions.

These may include demand, cost, timing, savings, benefits, funding, inflation, resource availability and stakeholder behaviour.

An assumptions log helps make the business case more transparent.

Assumptions log and financial forecast

Forecasts are built on assumptions.

Examples include sales growth, margin, costs, payment timing, interest rates, wage increases and capital expenditure.

A forecast without visible assumptions is hard to challenge.

Assumptions log and scenario planning

Scenario planning explores different possible futures.

Assumptions logs record the assumptions being used in the current plan.

Scenario planning can test whether those assumptions hold under different conditions.

Assumptions log and OKRs

OKRs define objectives and measurable key results.

An assumptions log can record what is being assumed about the resources, timescales, behaviour or external conditions needed to achieve those OKRs.

Assumptions log and Lean Canvas

Lean Canvas turns a business idea into testable assumptions.

An assumptions log can then track those assumptions, evidence and validation actions.

This is particularly useful for startups, new products and service pilots.

Alternatives and complementary frameworks

RAID log

A RAID log records risks, assumptions, issues and dependencies.

It is useful where all four areas need to be tracked together.

Risk register

Use a risk register to manage uncertain future events arising from assumptions.

Issue log

Use an issue log when an assumption has failed and a current problem now needs resolution.

Dependency log

Use a dependency log where delivery depends on another person, team, supplier or stakeholder.

Decision log

Use a decision log to record important decisions and the assumptions behind them.

Scenario planning

Use scenario planning where assumptions are uncertain and different futures need to be explored.

Sensitivity analysis

Use sensitivity analysis to test how financial outcomes change if assumptions move.

For example, sales volume, wage costs, build costs, interest rates or customer payment timing.

Business case review

Use a business case review to test whether the underlying assumptions remain valid.

Pre-mortem analysis

A pre-mortem asks the team to imagine that the project has failed and work backwards to identify why.

This can reveal hidden assumptions.

A practical assumptions log template

A useful assumptions log should include:

1. Assumption reference
2. Date recorded
3. Raised by
4. Assumption description
5. Area affected
6. Reason for assumption
7. Evidence available
8. Confidence level
9. Impact if wrong
10. Linked risk
11. Linked dependency
12. Linked decision
13. Validation action
14. Assumption owner
15. Review date
16. Status
17. Outcome
18. Action required
19. Closure date
20. Notes

Example:

Assumption reference: A001

Assumption description: The main supplier will deliver the required materials by 30 June.

Reason for assumption: Delivery date stated in supplier quotation dated 15 May.

Area affected: Project programme and installation schedule.

Impact if wrong: Installation will be delayed, potentially pushing completion back by two weeks and increasing contractor costs.

Linked risk: Supplier delivery delay.

Validation action: Obtain written confirmation from supplier and request updated production schedule.

Owner: Project Manager.

Review date: 10 June.

Status: Open.

Outcome: Awaiting supplier confirmation.

Questions to ask when reviewing an assumptions log

Identification questions

1. What are we assuming?
2. Where is this assumption recorded?
3. Who made the assumption?
4. Why was it made?
5. What plan, forecast or decision relies on it?
6. Is it specific enough?
7. Is it measurable or testable?
8. Is it still relevant?
9. Are there hidden assumptions in the plan?
10. What are we treating as certain without proof?

Evidence questions

1. What evidence supports the assumption?
2. Is the evidence current?
3. Is the evidence reliable?
4. Is it based on fact or judgement?
5. Has anyone challenged it?
6. Has it been confirmed in writing?
7. Does professional advice support it?
8. Does customer evidence support it?
9. Does financial data support it?
10. What evidence is missing?

Impact questions

1. What happens if the assumption is wrong?
2. Does it affect cost?
3. Does it affect time?
4. Does it affect quality?
5. Does it affect safety?
6. Does it affect compliance?
7. Does it affect reputation?
8. Does it affect customers or service users?
9. Does it affect the business case?
10. Does it affect strategic objectives?

Validation questions

1. How can the assumption be checked?
2. Who will check it?
3. When must it be checked by?
4. What information is needed?
5. Who needs to confirm it?
6. Is a pilot or test required?
7. Is external advice required?
8. Does it need to be escalated?
9. What would prove it true?
10. What would prove it false?

Risk questions

1. Does this assumption create a risk?
2. Is the risk already in the risk register?
3. What is the likelihood of the assumption proving wrong?
4. What would the impact be?
5. Are controls in place?
6. Is contingency needed?
7. Is the risk within appetite?
8. Does the board or project sponsor need to know?
9. Has the assumption become an issue?
10. What action is required?

Governance questions

1. Who owns the assumptions log?
2. How often is it reviewed?
3. Which assumptions are reported to the board or steering group?
4. How are assumptions linked to risks and issues?
5. How are changes recorded?
6. Are old assumptions closed?
7. Are important assumptions challenged?
8. Are decisions linked to assumptions?
9. Is the log informing real decisions?
10. What lessons are being learned?

The best way to think about an assumptions log

An assumptions log is not just a project document.

It is a way of making uncertainty visible.

A good assumptions log should be:

1. Clear
2. Specific
3. Evidence-based
4. Owned
5. Reviewed
6. Linked to risk
7. Linked to decisions
8. Focused on material assumptions
9. Updated regularly
10. Used in management discussions

A weak assumptions log says:

“Here are some things we think are true.”

A strong assumptions log asks:

“What are we relying on, how confident are we, what happens if we are wrong, and who is checking?”

The key question is not simply:

What assumptions have we made?

The better question is:

Which assumptions matter most, what evidence supports them, and what action is needed to confirm or manage them?

Conclusion: an assumptions log turns hidden uncertainty into managed judgement

An assumptions log remains useful because every plan relies on assumptions.

That is not a weakness. It is reality.

The problem is not making assumptions. The problem is making them silently, failing to test them, and then being surprised when they prove wrong.

Used badly, an assumptions log becomes another administrative document.

Used properly, it becomes a practical management tool. It helps teams, managers, trustees and boards understand what a plan depends on, which assumptions are uncertain, what evidence is missing, and what needs to be checked.

The real value is not in recording assumptions.

The real value is in challenging, validating and managing them.

A strong assumptions log helps an organisation move from saying, “We assumed that would happen,” to asking, “What did we assume, why did we assume it, and did we check it before it mattered?”