Blocked tasks should be tracked separately from ordinary “in progress” work because they require intervention, not just more execution time. The goal is to make every blocker visible, assign someone to resolve it, and measure how long it remains unresolved.
Add explicit blocker fields
In your project management tool, spreadsheet, or task board, give each blocked task these fields:
- Status: Blocked
- Blocker description: The precise condition preventing progress
- Blocked since: Date and time the blocker began
- Blocker owner: Person responsible for removing or escalating the blocker
- Dependency: The task, decision, access, resource, or external party involved
- Impact: What will be delayed if the blocker remains
- Priority or severity: Critical, high, medium, or low
- Next action: The concrete step needed to move forward
- Target resolution date: When the blocker should be cleared
- Escalation point: Who becomes involved if it is not resolved on time
Keep the blocker owner distinct from the task owner. The task owner may be unable to act, while the blocker owner could be a manager, approver, vendor contact, or another team member.
Use a clear workflow
A practical status flow is:
Not started → In progress → Blocked → In progress → Complete
When marking a task as blocked, require a reason and next action. Avoid vague notes such as “waiting” or “dependency issue.” A useful blocker statement explains exactly what is missing:
Blocked because: Production access has not been approved.
Owner: [Role or person responsible]
Next action: Approver reviews the access request.
Due: [Date]
Impact: Testing cannot begin, putting the planned release at risk.
If work can continue partially, keep the task “In progress” and flag the affected portion as at risk. Reserve “Blocked” for cases where meaningful progress has stopped.
Maintain a blocker register
For projects with many dependencies, use a central register:
| Task | Blocked since | Reason | Blocker owner | Severity | Next action | Due date | Impact |
|---|---|---|---|---|---|---|---|
| [Task name] | [Date] | [Specific blocker] | [Owner] | High | [Action] | [Date] | [Schedule or scope impact] |
Link each entry to its underlying task if your system supports it. Close the blocker entry when it is resolved, but preserve the history for retrospectives.
Review and escalate consistently
Review blockers during daily stand-ups or regular project check-ins. Focus discussion on three questions:
- What changed since the last review?
- What action will remove the blocker?
- Does it need escalation now?
Set escalation rules in advance. For example:
- Critical: Escalate immediately
- High: Escalate if unresolved within one business day
- Medium: Escalate after two or three business days
- Low: Review at the next scheduled project meeting
This prevents blockers from sitting unnoticed while deadlines approach.
Track useful metrics
A few simple measures can expose recurring project problems:
- Current blocker count
- Average time blocked
- Oldest unresolved blocker
- Blocked time as a percentage of total task cycle time
- Blockers by cause, such as approvals, external dependencies, staffing, technical issues, or unclear requirements
- Milestones affected by blockers
Avoid judging individuals by blocker counts. These metrics are most useful for identifying slow approval processes, fragile dependencies, missing resources, and other systemic issues.
A strong rule is: no blocked task without an owner, a next action, and a resolution target. That turns “we’re waiting” into a manageable project decision.