Project update guide
How to report a project blocker in English.
A blocker update should let the listener decide whether to intervene. Saying only “we are blocked” transfers anxiety, not useful information.
Give five pieces of information
- Blocked outcome: what cannot move forward.
- Impact: which date, customer, cost, or dependency is affected.
- Evidence: what confirms this is a blocker rather than a risk.
- Attempts: what the team has already tried.
- Request: the decision, access, or owner needed next.
Example blocker update
The payment test is blocked because we still do not have access to the partner sandbox. This puts Thursday’s integration sign-off at risk. We requested access on Monday and escalated to their technical contact this morning. We can either move the sign-off to Friday or approve testing with mocked responses. I need that decision by 2 p.m. today.
Separate blockers from risks
A risk might happen; a blocker is already preventing a required action. Use “at risk” when work can continue and “blocked” only when a dependency has stopped progress.
Avoid passive escalation
- Do not end with “just letting you know.”
- Do not name another team as the whole explanation.
- Do not hide the deadline until the end.
- Do not ask for “support” without specifying the action.