Turning Unvalidated Assumptions into Risks: The Forgotten Side of RAID

## The short answer

The Assumptions section of a RAID log is the one most teams neglect, and it's where many project failures begin. The discipline is simple: treat every assumption as a statement you've *chosen to believe without proof*, try to validate it, and if you can't validate it, convert it into a tracked risk. An unvalidated assumption is a risk wearing a disguise. Surfacing assumptions early and challenging them is one of the cheapest ways to protect a project.

## What an assumption really is

An assumption is something you're treating as true in order to plan, but which hasn't been confirmed. "The third-party API will support the volumes we need." "Business users will be available for testing in summer." "The legacy data is clean enough to migrate as-is." Each of these *might* be true, but if you've never checked, you're building your plan on hope. The danger is that assumptions are invisible by nature, they feel like facts until they fail.

## Why assumptions get neglected

Risks and issues feel urgent and concrete, so they get attention. Assumptions feel like background, so they get logged once at kick-off and never revisited. But assumptions are uniquely dangerous because:

- They're often **made implicitly** and never written down at all.

- They **feel certain**, so nobody thinks to challenge them.

- When they **fail, they fail late**, usually at the worst possible moment.

## The lifecycle of an assumption

A healthy assumption moves through a clear lifecycle:

1. **Captured** — written down explicitly, with the reasoning behind it.

2. **Owned** — assigned to someone who can find out whether it holds.

3. **Validated or invalidated** — actively checked against reality.

4. **Resolved** — if validated, it's confirmed and can be closed or noted as a fact; if invalidated, it becomes a risk or an issue and is managed accordingly.

The critical step most teams skip is step three. An assumption that is never tested simply lingers until reality tests it for you.

## How to surface hidden assumptions

Many of the most damaging assumptions are never written down because nobody realises they're assuming them. To bring them to the surface:

- Ask, for each key part of the plan, **"what has to be true for this to work?"**

- Challenge confident statements with **"how do we know that?"**

- Review the plan with **people outside the core team**, who are more likely to notice unexamined beliefs.

- Pay special attention to assumptions about **third parties, other teams and future availability of people**, these are the ones most often wrong.

## Validating assumptions

Validation means turning a belief into evidence. Depending on the assumption, that might be a quick technical spike, a written confirmation from a stakeholder, a sample of the real data, or a contractual check. The effort should be proportionate to the consequence: spend most of your validation energy on the assumptions that would cause the most damage if they proved false.

Prioritise by asking two questions for each assumption: **how confident are we that it's true**, and **how bad is it if we're wrong**? Low-confidence, high-impact assumptions are your validation priority.

## When an assumption can't be validated

Sometimes you genuinely can't confirm an assumption in time, you have to proceed on it. That's acceptable, *provided* you do it consciously. The move is to **promote the assumption into the Risk section**: "Risk: business users may not be available for summer testing (assumed, unconfirmed)." Now it carries a likelihood, an impact and a mitigation, and it gets reviewed like any other risk rather than sitting silently as a fact you never questioned.

## When an assumption fails

If an assumption you were relying on turns out to be false *while the project is live*, it has become an **issue**, a present problem. Reflect that in the log, assess the knock-on effects, and replan. This R-A-I flow, assumption to risk to issue, is exactly why RAID keeps the categories together: it lets you watch an item degrade from "believed" to "uncertain" to "actively hurting us" and intervene as early as the situation allows.

At neart.ai we build enterprise-grade delivery and PMO products, and a recurring theme in delivery health is that teams who actively challenge and validate their assumptions encounter far fewer late surprises than those who only manage risks and issues.

## Practical takeaway

Write your assumptions down explicitly, give each an owner, and prioritise validating the low-confidence, high-impact ones. Where you can't validate, consciously promote the assumption to a tracked risk rather than leaving it disguised as a fact. The assumptions you never examine are the ones most likely to sink you.