The Project Assumption Log That Prevents Arguments

The same argument runs three times on most projects, and it's always the same argument: two people remember agreeing to different things, because nobody wrote down what the schedule was actually assuming when the dates got set.

The direct answer: a project assumption log is a record of everything a schedule or budget assumes true but hasn't confirmed, resource availability, vendor timelines, technical compatibility, sponsor decisions, each entry carrying an owner, a date to validate it by, and the impact on the plan if it's wrong. Assumptions that go unvalidated past their date don't disappear; they surface later as a slipped milestone nobody can explain, because the thing the schedule was quietly counting on never actually got checked.

What a Project Assumption Log Actually Records

Every schedule is built on things nobody has confirmed yet. "The API team will have the new endpoint ready by our integration date." "Sarah is still on this project in March." "Procurement approves the vendor without a second review round." None of these are facts; they're bets the plan is making so the dates can exist at all. A project assumption log makes those bets visible instead of letting them sit silently inside a Gantt bar, the same reasoning behind keeping a risk register separate from an issue log: different kinds of uncertainty need different tracking, and an assumption is a third kind neither of those two trackers is built to hold.

An assumption is not a risk. A risk is something that might happen, with a probability and a mitigation plan prepared in advance. An assumption is something the plan has already, quietly, assumed is true; there's no probability attached because nobody has checked yet. That distinction is the whole reason the log needs to exist separately: an assumption that never gets validated doesn't get "mitigated" like a risk would, it just sits there until the date it was supposed to already be settled arrives and the plan discovers it wasn't.

The Four Assumption Types That Cause the Most Damage

Type	What it bets on	Typical example	Who should own it
Resource	A named person or skill stays available	"Sarah stays on this project through March"	Resource manager or functional lead
Technical	Two systems or components work together	"The new endpoint integrates without a schema change"	The engineer who can actually test it
External	A vendor or partner delivers on schedule	"The hardware ships by the date in the SOW"	Whoever owns the vendor relationship
Decision	A sponsor approves something not yet asked	"Legal signs off on the new data-sharing clause"	The person requesting the decision

Resource and external assumptions tend to be the most visible when they break, since a missing person or a late shipment shows up as an obvious blocker. Technical and decision assumptions are more dangerous precisely because they're quieter: a schema mismatch or an unasked approval can sit invisible in the plan for weeks before anyone tests it.

The Minimum Viable Assumption Log Format

An assumption log entry needs exactly four fields to be useful, and adding more than that mostly adds friction nobody keeps up with:

1. The assumption, written as a specific, falsifiable claim, not "resourcing should be fine" but "Sarah is allocated 50% to this project through March 15."
2. An owner, the person closest to the thing being assumed, not automatically the PM. A technical assumption belongs to the engineer who can test it; a resource assumption belongs to the resource manager who can confirm the allocation.
3. A validate-by date, the point by which the assumption has to be confirmed true or flagged false, ideally tied to a real milestone rather than an arbitrary calendar date.
4. Impact if false, one sentence on what happens to the schedule or budget if the bet doesn't pay off, so the team already knows the size of the problem before it becomes one.

The diagram below shows what happens to an assumption after its validate-by date arrives: it either becomes a documented fact, or it converts into whichever tracker actually fits what it turned into.

Weekly Review, Not a Kickoff Artifact

An assumption log built once at kickoff and never opened again is worse than not having one, because it creates the appearance of rigor without the substance. Assumptions need to be reviewed weekly, alongside the normal status update, and always ahead of any milestone that depends on one directly. A schedule that looked clean at baseline can accumulate stale, unvalidated assumptions every time it gets rescheduled under pressure, the same drift pattern that shows up in logic density and the other schedule quality metrics that erode between kickoff and delivery if nobody's watching them.

The review itself is short: for each entry past its validate-by date, the owner confirms it, converts it to a risk if there's still time to respond, or opens it as an issue if the impact has already hit. That three-way fork is what keeps the assumption log from becoming a junk drawer where old uncertainty goes to be forgotten instead of resolved.

Assumption Log vs Risk Register vs Issue Log

The three trackers answer three different questions, and a team that collapses them into one loses the distinction that makes each one useful. An assumption log asks "what is this plan silently betting on." A risk register asks "what might happen that we haven't bet on yet." An issue log asks "what has already happened that needs a resolution." The full breakdown of risk register vs issue log covers that second split in depth; an assumption log sits one step earlier than both, catching the bets a plan makes before anyone has even framed them as a risk.

Building the habit of writing assumptions down alongside the rest of a project's foundational documents starts at kickoff: the project charter template is the natural place to seed the first entries, since a charter already forces the team to state what it's counting on before the schedule gets built around it. A free PMO Maturity Assessment also scores whether assumption tracking and the rest of a PMO's governance habits are actually in place, rather than just assumed.

Run the free PMO Maturity Assessment Get a clear read on where your team's planning discipline, including assumption and risk tracking, actually stands today. About ten minutes, no signup required. → Open the PMO Maturity Assessment