Project Risk vs Blocker: What to Track and When

Download the blank risk vs blocker tracker spreadsheet. No account is required. Save a copy before adding your project details.

A risk describes uncertainty: a possible event that could affect scope, cost, quality, or time. A blocker describes an existing obstacle that stops a task from making the planned progress. Both deserve visibility, but they require different responses.

For a fictional website project, “The client may not deliver licensed photography before design review” is a risk. “The hero section cannot be completed because the approved photography did not arrive” is a blocker. The moment the dependency fails, the team needs an unblock plan rather than merely a higher risk score.

A project can contain a risk and a blocker at the same time. Avoid forcing the entire project into one vague red or yellow status.

A small risk record needs the possible event, likelihood, impact, warning trigger, planned response, and owner. The trigger is the most actionable field because it tells the team when to stop watching and start acting.

For example: “If licensed images are not approved by Wednesday, ask the client to choose the preapproved fallback by Thursday.” This is much stronger than “Photo risk: medium.”

Risk ratings need consistent definitions but should not pretend to be statistically precise. A written explanation can be more useful than multiplying two subjective scores.

A blocker record identifies the specific task that cannot continue, the missing prerequisite, the party responsible for it, the next action, and the delivery effect. For example:

Blocked task: Finalize homepage hero.

Missing input: Approval of licensed campaign image.

Needed from: Client marketing lead.

Next action: Send two-image decision request today.

Milestone effect: Thursday review may move if no answer arrives.

The Atlassian dependency guide explains why prerequisites affect sequencing. A dependency becomes a live blocker when the missing output prevents planned work.

Escalate a risk when its warning trigger indicates that a meaningful commitment may be threatened and a decision is required. Escalate a blocker when the owner cannot resolve it within the time available or when the consequence extends beyond one task.

Do not escalate every inconvenience to the client. First check whether an authorized workaround or independent task can keep progress moving. But do not hide a material delay merely because it is uncomfortable to discuss.

The Noddis client project tracker explains how current project state can be compared across engagements. The project drift guide discusses early signals of trouble; distinguishing risk from blocker helps determine what those signals require next.

Use a small combined view with separate columns for Type, Trigger or missing input, Owner, Next action, and Review date. A risk may become a blocker, at which point update its type and preserve the history. Do not create multiple disconnected copies of the same issue unless your system requires an explicit linked task.

Noddis is a project management app that connects tasks, project details, and follow-up commitments. Keep risks in project notes or a linked register, and use task records for work currently blocked. Follow-Up can track responses needed from clients or collaborators. The app does not automatically decide which business risks are acceptable. Explore the live demo.

Review your current “at risk” and “blocked” labels. For each, write what might happen or what is already stopping progress. The correct next action usually becomes much clearer.