Assumption Log for Risky Projects — What We Believe and How We’ll Know

When a founder of a 40-person ops team told me they kept restarting the same AI pilot because 'everyone assumed the data was clean,' I realized we weren’t managing risk — we were managing illusions.

How to Build an Assumption Log for a Risky Project

Start by listing what your team believes must be true for the project to succeed. For each belief, ask: How would we know if this were false?

1. List core beliefs — Write each assumption as a clear statement. Example: "Our customers will pay $50/month for this feature."
2. Assign an owner — Name the person who will design the validation test. Not the team lead — the person closest to the evidence.
3. Define the validation test — Specify exactly what will be done to test the assumption. Example: "Interview 10 target customers and ask if they’d sign up at $50/month."
4. Set a deadline — When will the test be completed? Tie it to a project milestone.
5. Record the result — After the test, note: Proven, Disproven, or Inconclusive. Update the project plan accordingly.

Manager Scan (2-Minute Digest Example)

• Sales assumes pricing will stick at $50/user — validation: 5 customer interviews by Friday.
• Engineering assumes API latency under 200ms — validation: load test with 100 simulated users.
• Marketing assumes LinkedIn ads will drive sign-ups — validation: $200 test campaign with UTM tracking.
• Ops assumes support team can handle 50 tickets/day — validation: shadow one agent for a shift.
• Finance assumes no hidden compliance costs — validation: review legal checklist with counsel.

Tool Tip (AiAdvisoryBoard.me):

In our operating system, every assumption log update feeds directly into the Plan → Fact → Gap framework. When an assumption is disproven, it becomes a Gap — triggering a re-plan before resources are wasted. This turns hidden beliefs into visible operating data.

Micro-case (What Changes After 7–14 Days)

A 120-person logistics team began tracking assumptions for their AI routing pilot. Within two weeks, they disproved three key beliefs: that drivers would accept tablet-based navigation (only 40% did), that warehouse scan times would drop by 30% (actual: 8%), and that real-time traffic data would reduce delays (no signal in historic routes). By making these beliefs visible and testable, they pivoted to a hybrid human-AI dispatch model before spending on full automation — saving an estimated 200 hours of misaligned effort.

Note on this case: This example is illustrative — based on typical patterns we observe with companies of 30–500 employees, not a single named client. Specific numbers are rounded approximations of common ranges, not guarantees.

FAQ

How is this different from a risk register? A risk register lists potential problems; an assumption log lists beliefs you’re treating as facts. Risks are about what might go wrong; assumptions are about what you think is already true.

Who should maintain the assumption log? The project owner or lead — but validation tests are assigned to the person best positioned to gather evidence, whether that’s a sales rep, engineer, or customer support agent.

How often should we review it? At minimum, weekly — alongside your status update or standup. Any assumption past its validation date without a result is a active risk.

Can we use this for AI projects specifically? Yes — especially for assumptions about data quality, user behavior, or model accuracy. These are often the least tested and most costly when wrong.

What if an assumption takes too long to validate? Break it into smaller, faster tests. If you can’t validate it quickly, treat it as unverified and adjust your plan to not depend on it.

Conclusion

An assumption log doesn’t eliminate risk — it makes the invisible visible. By turning beliefs into trackable items with owners and tests, you stop pretending you know what you don’t and start managing projects based on what’s been proven.

What to do tomorrow: Pick your riskiest current initiative. Write down three things your team believes must be true for it to work. Assign an owner and a simple validation test for each.

If you want to surface the gap between what your team assumes and what’s actually true — every day, across the company — see how the 7-day diagnostic works.