How to Track Blocked Project Tasks and Unblock Them

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

A task is blocked when a missing prerequisite prevents the next planned step. That prerequisite might be an approval, missing content, a design decision, account access, or unfinished upstream work. A task that is merely low priority or not yet started should not be marked blocked.

Imagine a fictional Juniper homepage build. The developer cannot finish the hero because the client has not approved the product photography. “Blocked by client” is too vague. “Cannot finalize hero until marketing lead approves one of two licensed image options” tells the project owner what decision is needed.

The Atlassian guide to project dependencies describes how tasks rely on other outputs and why identifying those relationships helps project planning. In small client work, you can apply that idea without a complicated dependency graph.

The register below separates the work item from the event that can unblock it. Use one active row per material blocker.

Fictional example. The last row shows why impact matters. A task can be blocked without blocking the entire launch if work can be resequenced safely.

Start with a short triage process. Ask what exactly is missing, who can provide it, whether a safe workaround exists, and what happens if it does not arrive by the decision date.

1. Specify the dependency. Replace “waiting on client” with the exact answer, file, or approval required.
2. Assign the unblock owner. The task owner may not be the person who owes the missing input.
3. Choose a next action. Send an approval request, test access, split the task, or select an authorized workaround.
4. Escalate based on impact. If the missing input now threatens a milestone, communicate the consequence and propose a schedule choice.

Do not repeatedly move the task's due date without explaining why. The date change is a result of the blocker, not a fix for it.

A workaround is acceptable when it is authorized, reversible where necessary, and does not compromise quality or the agreement. For example, you might continue building another approved page while an image decision is pending. You should not invent approved copy or use unlicensed photography simply to make the progress bar move.

If the blocker affects a critical dependency, identify the dependent tasks and decision date. Keep the client informed before the delay becomes a missed commitment. The client project tracker shows how blockers can appear alongside deadlines in a portfolio overview.

A useful escalation provides a choice, not a vague warning:

We are ready to finish [deliverable], but we need [specific decision] before [dependent work] can begin. If we receive it by [date], we can assess the original milestone. Otherwise, we can either move [milestone] or continue with [safe approved alternative]. Which would you prefer?

The decision-maker can now weigh the options. If there is no safe alternative, say so rather than pretending one exists.

Noddis is a project management app with connected project tasks, a Portfolio overview, and Follow-Up commitments. Use the task to describe the blocked work and record a linked Follow-Up when a specific response is owed by a client or collaborator. Ordinary tasks do not automatically become Follow-Ups. See the follow-up system guide and try the demo.

Open your current blocked items and rewrite each one as “Cannot do X until Y; Z owns the next action by date.” If that sentence is impossible to complete, the blocker needs clarification.