Risk vs. Issue vs. Assumption

One situation, three useful questions

The team plans to use an existing utility survey for the design. Nobody has confirmed whether it covers the full work area. There is something to check, a possible consequence to prepare for, and perhaps a problem to resolve. Calling all three “a risk” can make the next step less clear.

An assumption is something you are treating as true for planning before it is confirmed. A risk is an uncertain event or condition that could affect a project objective. An issue is a current condition that needs attention. Risks can involve opportunities as well as threats; this example follows a possible delay.

The labels help distinguish what you need to verify, what you need to prepare for, and what you need to address now. PMI’s discussion of risks, issues, and assumptions makes the connection: planning around an assumption creates exposure if it proves wrong.

Give the assumption a check date

“Survey is adequate” is difficult to verify. “The survey includes the eastern work area and the utility information needed for this design stage” gives someone a specific check.

Record who will confirm it, what evidence they need, and when the answer matters. For example: the design lead checks coverage with the surveyor by Wednesday, before detailed layout begins. A check scheduled after the team relies on the assumption offers little protection.

Not every assumption needs its own elaborate record. Give attention to the ones that would change the scope, sequence, or estimate if they were wrong.

Describe the risk and the response

A useful risk statement connects the uncertainty to its effect: “If the eastern area is missing from the survey, fieldwork and processing may postpone the detailed layout.” That tells the team why the coverage check matters.

The response might be to confirm coverage early and find out the surveyor’s next available field date. Set a trigger for further action: if coverage is still unconfirmed on Wednesday, the project manager follows up and checks the effect on the design sequence. See risk and uncertainty for turning that exposure into an owned response.

When the gap is confirmed, act on it

Once the missing coverage is confirmed, it is a present issue even if the design team has not reached the affected work yet. Arrange the additional survey, confirm the required information, and update the plan. Do not wait for the missed milestone to make the issue official.

The issue can still create new risks: access might be unavailable, or poor weather might prevent fieldwork. Link those uncertainties to the current problem instead of keeping an outdated “survey might be incomplete” entry open indefinitely.

Keep the records connected

A small project can track these items in one shared list with a type, owner, next action, and date. Link the original assumption to the risk and the confirmed issue so someone joining the project can follow what changed.

At the next review, take one vague entry such as “utilities” and write what is known, what remains uncertain, and what happens next. The useful result is a clear action: “Design lead to confirm missing coverage with the surveyor on Wednesday; project manager to update the layout sequence after the response.”