The assumptions hiding in your process diagrams

Quite often on a project, there are assumptions that are invisible but hold true for all the stakeholders. When reality doesn't match them, that's where the problems appear. Assumptions are harder to deal with than deliverables precisely because they're not as visible as other project artefacts.

I'd track them in a separate table, sometimes called an assumption log, next to the process diagram (not inside the swimlane). Three columns: what we assume, what happens when that assumption fails, and what signal tells us it's failing.

When an assumption gets invalidated, it doesn't just disappear. PMBOK routes it into either the Risk Register (if it's a future threat) or the Issue Log (if it's already broken). The pipeline runs: Assumption Log → Risk Register → Issue Log, with assumptions actively migrating as the project matures.

The RAID log (Risks, Assumptions, Issues, Dependencies) is common practice derived from this thinking. Some shops run the full four-quadrant version as a single artefact rather than four separate registers.

Whichever way you do it, you give assumptions their own surface, which means they stop being invisible.

Sorted by modified date,
Zhenia