Assumption log

A living register that records assumptions and constraints, along with their sources, validation plans, ownership, and status. It supports decisions and risk management by making uncertainties visible and testable.

Key Points

  • A dynamic artifact started early and maintained throughout the project lifecycle.
  • Captures both assumptions and constraints, each with an owner and a target validation date.
  • Links to the risk register because unvalidated assumptions can become risks.
  • Improves estimating and planning by making underlying beliefs explicit and testable.
  • Includes a clear validation approach (analysis, prototype, pilot, supplier confirmation, etc.).
  • Prioritizes entries based on potential impact if the assumption proves false.

Purpose

The assumption log ensures that key beliefs and limitations influencing scope, schedule, cost, and quality are explicitly recorded, validated, and managed. It reduces surprises by turning uncertainty into planned validation work and by linking outcomes to risk responses and decisions.

Field Definitions

  • ID: Unique identifier for tracking the entry.
  • Type: Assumption or constraint indicator.
  • Category: Planning area affected (scope, schedule, cost, quality, resource, procurement, stakeholder, etc.).
  • Description: Clear statement of the assumption or constraint.
  • Source: Person, document, or event that provided the assumption or constraint.
  • Date Logged: When the entry was created.
  • Owner: Person responsible for validation and updates.
  • Validation Approach: How it will be tested or confirmed (analysis, test, pilot, contract clause, expert confirmation).
  • Target Validation Date: When validation should be completed.
  • Confidence/Probability: Current confidence rating or likelihood that the assumption holds.
  • Impact if False: Effect on objectives if the assumption fails (qualitative note or severity rating).
  • Priority: Ranking based on impact and urgency.
  • Status: Open, validated-true, invalidated-false, superseded, or closed.
  • Related Items: Linked risks, requirements, WBS elements, decisions, or change requests.
  • Response/Mitigation: Planned actions if it proves false or cannot be met.
  • Triggers/Indicators: Early warning signs that the assumption may not hold.
  • Notes/History: Key updates and decisions over time.

How to Create

  1. Set up the structure: define fields, rating scales, and statuses for consistency.
  2. Elicit entries during chartering, stakeholder interviews, and early estimation workshops.
  3. Separate assumptions from constraints, and tag by category to aid analysis.
  4. Assign an owner and target validation date to each entry.
  5. Define a validation approach for each assumption (e.g., supplier confirmation, prototype, analysis).
  6. Rate confidence and impact, and set initial priority for follow-up.
  7. Link entries to related risks, requirements, and decisions to maintain traceability.
  8. Publish the log in the team workspace and agree on review cadence.

How to Use

  • Review before major estimates or commitments to ensure assumptions are still valid.
  • Run planned validations; update status and confidence based on results.
  • When an assumption fails, create or update risk responses and raise change requests as needed.
  • Use constraints to shape scope, schedule, and procurement strategies.
  • Surface critical assumptions in governance and stakeholder communications.
  • Feed learning back into forecasts, backlog ordering, and release plans.

Ownership & Update Cadence

Primary owner: the project manager or product owner; day-to-day maintenance may be delegated to a business analyst or coordinator. Contributors include team leads, SMEs, procurement, and key stakeholders.

  • Initialize during project initiation and refine during planning.
  • Review at each reporting cycle and before stage gates or release decisions.
  • Update whenever experiments complete, supplier terms change, or new data emerges.
  • Synchronize with risk reviews to add, escalate, or close related risks.
  • Archive closed or superseded entries with decision history for traceability.

Example Rows

  • ID: A-07; Type: Assumption; Category: Procurement; Description: Supplier will hold quoted price for 90 days; Source: Sales email; Owner: Buyer; Validation: Written confirmation; Target Date: 15-May; Confidence: Medium; Impact if False: +8% cost; Priority: High; Status: Open; Related: R-12; Response: Add 10% contingency if not confirmed.
  • ID: C-03; Type: Constraint; Category: Schedule; Description: Regulatory audit must occur before go-live; Source: Compliance; Owner: PM; Validation: Regulation review; Target Date: 01-Jun; Confidence: High; Impact if False: Delay launch; Priority: High; Status: Validated-true; Related: Milestone M4; Response: Build audit lead time into plan.
  • ID: A-15; Type: Assumption; Category: Resource; Description: Two senior developers available 50% time; Source: Resource manager; Owner: Dev Lead; Validation: Capacity plan sign-off; Target Date: 22-Apr; Confidence: Low; Impact if False: Slip by 3 weeks; Priority: High; Status: Open; Related: Schedule baseline; Response: Adjust scope or onboard contractor.
  • ID: A-21; Type: Assumption; Category: Quality; Description: Pilot results generalize to full rollout; Source: Prior project; Owner: QA Lead; Validation: Extended pilot; Target Date: 30-May; Confidence: Medium; Impact if False: Rework and extra testing; Priority: Medium; Status: Open; Related: Test plan; Response: Expand test coverage and add rollback plan.

PMP Example Question

During planning, the team bases cost estimates on the belief that a supplier will maintain current pricing for the next six months. What should the project manager do first?

  1. Add the belief to the issue log and escalate to the sponsor.
  2. Ignore it until a procurement contract is signed.
  3. Record it in the assumption log with an owner and validation plan.
  4. Enter it as a closed risk since the supplier verbally agreed.

Correct Answer: C - Record it in the assumption log with an owner and validation plan.

Explanation: This is an assumption influencing estimates and should be logged with a plan to validate; it may also link to a risk if uncertain.

ICS/OT Cybersecurity Fundamentals — Security Built for Industrial Systems

Industrial control systems cannot be secured like ordinary IT. A forced reboot, aggressive scan, or incompatible patch can interrupt production and create real safety consequences. Effective OT security begins with understanding the systems, constraints, and risks unique to industrial environments.

This course gives IT professionals, engineers, operators, and security practitioners a practical foundation in ICS threats, zone and conduit design, risk assessment, passive asset visibility, and vendor evaluation. You will learn how IEC 62443, NIST CSF, and MITRE ATT&CK for ICS apply where availability and safety come first.

Eight reconstructed incidents—including Stuxnet, Triton, Ukraine 2015, Colonial Pipeline, and PIPEDREAM—show how attackers move through OT environments, what they target, and which defenses could have changed the outcome.

Watch the course preview, then build the vocabulary, frameworks, and judgment needed to take credible first steps in ICS/OT cybersecurity.

Explore the Course


ICS/OT Cybersecurity Fundamentals course preview

Launch your Agile career!

HK School of Management helps you learn Agile and Scrum with practical playbooks, AI-powered prompts, and real-world workflows for planning and delivery. Practical skills, tools, and guidance you can apply right away. Covered by Udemy's 30-day refund policy.

Learn More