Assumptions Log Template – Free Word Download

Assumptions Log Template – Free Word Download

Introduction to the Assumptions Log

We have arrived at the final template in our comprehensive project management suite. We began with the Business Case (Why are we doing this?) and moved through Charters, Scopes, Risks, and Benefits. Now, we must address the invisible foundation upon which all those other documents rest: The Assumptions.

In project management, an assumption is any factor that is considered to be true, real, or certain for the purpose of planning, yet requires no proof at the time it is made. Every schedule, every budget, and every scope statement is built on a mountain of assumptions. You assume the concrete will dry in 48 hours. You assume the server price will stay stable. You assume the key stakeholder will not resign next week.

The danger lies not in making assumptions (which is necessary for planning) but in forgetting that they are assumptions. When an assumption is forgotten, it hardens into a “fact” in the mind of the Project Manager. If that “fact” turns out to be false, the project can suffer catastrophic failure. This phenomenon is often the root cause of the phrase “We didn’t see it coming.” In reality, the team likely did see it coming; they simply assumed it wouldn’t happen.

The Assumptions Log (often combined with a Constraints Log) is the tool used to document, validate, and track these factors. It is a “living document” that serves as a safety net. It converts implicit beliefs into explicit statements that can be tested. By writing them down, you invite stakeholders to challenge them. This template guides you through the creation of a rigorous log that will protect your project from the silent killer of unvalidated beliefs.

Assumptions Log Template – Free Word Download

Section 1: Distinguishing Assumptions, Constraints, and Risks

Guidance for Completion

Before you can log them, you must be able to identify them. Confusion often exists between these three concepts. You must clarify these definitions for your team to ensure the log is populated correctly.

The Definitions

  1. Assumption: A factor we believe to be true (usually positive or neutral) that allows us to proceed with planning.
    • Example: “We assume the permit will be issued in 10 days.”
    • Management: Validate it. (Check with the permit office).
  2. Constraint: A limiting factor that is imposed upon the project. It is a restriction we must work within.
    • Example: “The budget is capped at exactly $50,000.”
    • Management: Plan around it.
  3. Risk: An uncertain event that may happen in the future (usually negative).
    • Example: “The permit office might go on strike.”
    • Management: Mitigate it.

The Relationship

There is a tight relationship between these three.

  • If an Assumption proves false (The permit takes 20 days), it becomes an Issue.
  • If an Assumption is shaky (We are not sure about the permit), it generates a Risk.
  • A Constraint (Budget Cap) forces us to make Assumptions (We assume we can find cheaper labor).

Draft Example

“Project Context: Office Move.

  • Assumption: We assume the elevators are large enough to fit the new desks.
  • Constraint: We must move on a weekend to avoid disrupting business.
  • Risk: If the elevators are too small, we will have to carry desks up the stairs, delaying the move.”

Section 2: The Lifecycle of an Assumption

Guidance for Completion

An assumption is not a static entry. It has a lifecycle. It starts as a “guess” and ends as either a “fact” or a “fallacy.” You must track this status.

The Stages

  1. Identified: The assumption is logged. (e.g., “We assume X”).
  2. Validated: Evidence is found that proves it is true. (e.g., We measured the elevator; the desks fit). Action: Close the item.
  3. Invalidated: Evidence proves it is false. (e.g., We measured the elevator; the desks do not fit). Action: Raise an Issue or Change Request.
  4. Monitoring: We cannot prove it yet, so we must watch it. (e.g., We assume the weather will be clear on the day of the event).

Section 3: Categories of Assumptions

Guidance for Completion

To ensure you capture a holistic view of the project’s uncertainty, use categories to prompt your thinking. Do not just focus on technical assumptions.

Category 1: Resource and Availability

  • Assumptions about staff skills. (“We assume the team knows Python”).
  • Assumptions about availability. (“We assume the SME can dedicate 10 hours a week”).

Category 2: Financial and Budgetary

  • Assumptions about costs. (“We assume the exchange rate will stay below 1.5”).
  • Assumptions about funding. (“We assume the Q3 budget will be released on July 1st”).

Category 3: Technical and Scope

  • Assumptions about existing systems. (“We assume the legacy database is clean”).
  • Assumptions about integration. (“We assume the API documentation is accurate”).

Category 4: Schedule and Timeline

  • Assumptions about productivity. (“We assume we can lay 100 bricks per day”).
  • Assumptions about approvals. (“We assume the Steering Committee will approve the design in 48 hours”).

Category 5: Environmental and External

  • Assumptions about the market. (“We assume customer demand will remain flat”).
  • Assumptions about regulation. (“We assume the tax law will not change this year”).

Section 4: The Log Structure (Columns)

Guidance for Completion

This section outlines the fields required in your spreadsheet or register. Each column serves a specific management purpose.

Column 1: ID

  • Format: A-001, A-002.
  • Purpose: Unique tracking.

Column 2: Category

  • Format: Dropdown (Financial, Technical, etc.).
  • Purpose: Filtering and reporting.

Column 3: The Assumption Description

  • Format: “We assume that…”
  • Tip: Be specific. Avoid “We assume it will be fine.” Use “We assume availability of 99.9%.”

Column 4: Validation Strategy (The “Check”)

  • Format: Action statement.
  • Purpose: How will we prove this? (e.g., “Measure the elevator,” “Call the vendor,” “Run a pilot”).

Column 5: Impact of Falsehood (The “So What?”)

  • Format: Description.
  • Purpose: What happens if we are wrong? (e.g., “If wrong, the project is delayed by 2 weeks”).

Column 6: Owner

  • Format: Name.
  • Purpose: Who is responsible for the validation action?

Column 7: Due Date for Validation

  • Format: Date.
  • Purpose: When must we know for sure? (This is usually tied to a decision gate).

Column 8: Status

  • Format: Open, Validated, Invalid, Closed.

Section 5: Writing Effective Assumptions (Syntax)

Guidance for Completion

Vague assumptions are useless. You cannot validate a feeling. You must assume specific conditions.

The “Specificity” Rule

  • Bad Assumption: “We assume the vendor is good.” (Subjective).
  • Good Assumption: “We assume the vendor holds ISO 9001 certification and can deploy a team within 5 business days of contract signature.” (Testable).

The “Dependency” Rule

Often, assumptions are just dependencies in disguise.

  • Bad Assumption: “We assume Marketing helps us.”
  • Good Assumption: “We assume the Marketing Department will provide the final high-resolution logo files by October 12th.”

Draft Example

“Assumption A-010: We assume that the existing underground cabling conduits are free of blockages and can be reused for the new fiber optic lines.

Validation: Conduct a ‘rodding and roping’ test on a sample of 3 conduits by Week 2.

Impact: If blocked, we will need to dig new trenches (Civil Works), adding $50k to the budget.”

Section 6: Validation and “Confidence Checks”

Guidance for Completion

The goal of the log is to move items from “Assumed” to “Proven.” This is called the Confidence Check. You should schedule these checks regularly.

The Validation Methods

  1. Research: Read the manual, check the law, read the contract.
  2. Testing: Run a prototype, dig a test hole, run a script.
  3. Written Confirmation: Email the stakeholder and ask “Can you confirm X?”

Draft Example

  • Assumption: The client will provide data in CSV format.
  • Validation Action: Send an email to the Client IT Manager asking for a sample file.
  • Result: Client sends a PDF file.
  • Outcome: Assumption Invalidated.
  • Action: Raise a Change Request to build a PDF scraper tool.

Section 7: Impact Analysis (Sensitivity Analysis)

Guidance for Completion

Not all assumptions are equal. Some are “Load Bearing” assumptions; if they break, the whole project collapses. Others are cosmetic. You should rate the Stability and Impact of each assumption.

The Matrix

  • Stability: How likely is this to be true? (High/Low).
  • Impact: How bad is it if it is false? (High/Low).

The “Critical Assumptions”

Assumptions that are Low Stability and High Impact are effectively High Risks. These must be moved to the Risk Register immediately.

Draft Example

“Assumption: We assume the price of steel will remain under $800/ton.

Stability: Low (Market is volatile).

Impact: High (Steel is 40% of our material cost).

Action: This is too dangerous to remain an assumption. Move to Risk Register as ‘Risk of Material Price Inflation’ and mitigate by pre-purchasing.”

Section 8: The Constraints Log (Integrated Section)

Guidance for Completion

While this template focuses on assumptions, it is best practice to include a separate tab or section for Constraints. Constraints are the hard boundaries.

Types of Constraints

  1. Business Constraints: Deadlines, Budgets, Resource Caps.
  2. Technical Constraints: “Must use Azure,” “Must code in Java,” “Must run on Windows 10.”
  3. Regulatory Constraints: “Must store data in the EU.”

Managing Constraints

You cannot “validate” a constraint; you can only “challenge” it.

  • Constraint: “Must finish by Dec 31st.”
  • Challenge: “Why? What happens on Jan 1st?”
  • Outcome: “Tax laws change.” (Okay, it is a hard constraint). OR “The CEO wants it.” (This is a soft constraint; maybe we can negotiate).

Draft Example

IDConstraint DescriptionTypeFlexibilityImpact on Planning
C-01Total Budget Cap $100kFinancialHard (Zero variance)Scope must be prioritized (MoSCoW).
C-02No downtime during trading hoursOperationalHardDeployments must happen on weekends.
C-03Use existing logoBrandingSoft (Negotiable)Saves design time, but limits creativity.

Section 9: The “Silence” Assumption (Cultural Assumptions)

Guidance for Completion

The most dangerous assumptions are the ones about human behavior. We often assume that silence means agreement. We assume that people read their emails. We assume that people act logically.

Documenting Cultural Norms

Use the log to call out these behaviors explicitly. This can be uncomfortable but necessary.

Draft Example

“Assumption A-020: We assume that ‘Sign-off’ by the Department Head implies that they have consulted with their team. We assume we do not need to seek individual approval from every team member.

Risk: If the Head signs off without consulting, the team may revolt during UAT.

Validation: Ask the Department Head explicitly: ‘Have you shown this to your team?'”

Section 10: Integration with Risk and Issue Logs

Guidance for Completion

The Assumptions Log feeds the Risk Log. They are connected vessels.

The Flow of Data

  1. Assumption Logged: “We assume X is true.”
  2. Validation Fails: “X is actually false.”
  3. Decision Point:
    • Is it a problem now? -> Issue Log.
    • Is it a potential problem later? -> Risk Log.
    • Do we need to change the plan? -> Change Log.

Draft Example

  • Assumption: “We assume the soil is free of rock.”
  • Validation: Geotech survey finds rock.
  • Result: Assumption Invalid.
  • New Risk (R-055): “Risk of delay due to rock excavation.”
  • New Issue (I-003): “Need to hire a rock breaker machine immediately.”

Section 11: Review Cadence and Triggers

Guidance for Completion

Assumptions rot over time. An assumption that was true in January might be false in June. You must review the log at key points.

Review Triggers

  1. Phase Gates: Before moving from Design to Build, re-validate all design assumptions.
  2. Major Change Requests: If scope changes, do the old assumptions still hold?
  3. New Stakeholders: If a new Sponsor joins, do they share the assumptions of the old Sponsor?

Draft Example

“The Assumptions Log will be a standing agenda item at the monthly Project Board meeting. We will review only the ‘Open’ assumptions that are due for validation in the current month.”

Section 12: Sign-Off and Baselining

Guidance for Completion

You need the Sponsor to agree to the assumptions. This is your “Get Out of Jail Free” card. If the project fails because a documented, agreed-upon assumption turned out to be false, it is an organizational failure, not a Project Manager failure.

The Disclaimer

Include a statement that baselines the plan on these facts.

Signature Block

  • Project Manager: ___________________
  • Project Sponsor: ___________________
  • Statement: “I acknowledge that the project plan, schedule, and budget have been calculated based on the assumptions listed in this log. I understand that if these assumptions prove to be incorrect, the project baseline will require adjustment via the Change Control process.”

Detailed Scenario: The Construction Project

To illustrate the power of this log, let us look at a detailed example from a construction project.

Project: Building a new car park.

The Assumptions Log:

IDCategoryAssumptionValidation StrategyStatusImpact if False
A-01Geo-techWe assume the water table is at least 5 meters below ground level.Borehole samples in Week 1.OpenIf water is higher, we need expensive de-watering pumps ($20k).
A-02LegalWe assume the noise permit allows work between 07:00 and 19:00.Check Council website.Validated(Closed).
A-03SupplyWe assume the concrete plant can deliver 50 loads a day.Call supplier for capacity check.OpenIf they can only do 20, the schedule extends by 2 weeks.
A-04FinancialWe assume no tariffs will be placed on imported steel during the project.Monitor trade news.MonitoringCost of materials rises by 15%.

Scenario Outcome:

In Week 1, the borehole test (Validation A-01) shows water at 2 meters. The assumption is Invalidated.

  • Result: The Project Manager immediately raises a Change Request for de-watering pumps. The budget increases by $20k.
  • Benefit: Because this was logged and tested early, the pumps were ordered before the excavators arrived. There was no delay. If this assumption had not been logged, the excavators would have arrived, found water, and sat idle for a week while pumps were ordered. The log saved the project.

Common Pitfalls to Avoid

Pitfall 1: The “Secret” Assumption

The Project Manager assumes something but doesn’t write it down because “it’s obvious.” Nothing is obvious. Write it down.

  • Correction: Log even the basics. “We assume power is available at the site.”

Pitfall 2: Optimism Bias

Only logging positive assumptions. You should also log neutral ones.

  • Correction: Challenge the team. “What are we assuming goes right for this plan to work?”

Pitfall 3: Never Validating

Filling the log and then ignoring it. An unvalidated assumption is just a risk waiting to happen.

  • Correction: Assign an “Owner” and a “Due Date” to every row. Chase them.

Conclusion

The Assumptions Log is the unsung hero of project documentation. While the Risk Register gets all the attention (and the panic), the Assumptions Log quietly ensures that the project is standing on solid ground.

By completing this template, you are performing a rigorous structural integrity check on your project plan. You are asking: “Is this plan built on facts, or is it built on hope?”

Remember that in project management, hope is not a strategy. Documentation is a strategy. Validation is a strategy. Verification is a strategy.

As you conclude this set of 20 templates, realize that they are an interconnected ecosystem. The Business Case relies on Assumptions. The Assumptions feed the Risks. The Risks impact the Schedule. The Schedule delivers the Objectives. And the Objectives realize the Benefits.

By maintaining this Assumptions Log, you keep the ecosystem healthy. You ensure that when the winds of reality blow (and they always do), your project bends but does not break, because you knew exactly where your weak points were, and you reinforced them before the storm arrived.

Meta Description

A template for the Assumptions and Constraints Log. Tracks the lifecycle of planning assumptions, validation strategies, and the impact of invalid assumptions on project success.

Discover free project management templates at www.pmresourcehub.com