What is the difference between a blocker and a dependency?

A dependency is a relationship between tasks that sets the order in which work happens. A blocker is any obstacle that stops progress, and a dependency becomes one when it holds up the work. [Motion's explainer](https://www.usemotion.com/blog/project-blockers) uses a chain of baking steps to show how a delay early in the chain affects every later task.

Should I give my client access to our Jira or Asana board?

Give a client board access only if they will use it and your plan's guest rules allow it. If a client rarely opens the board, a short email request with one clear question and a link to the evidence is easier to act on. Either way, keep the decision recorded next to the ticket it unblocks.

What is implicit approval and when should I use it?

Implicit approval means a stakeholder is told that something will go ahead and it does unless they object. [Unito describes it](https://unito.io/blog/removing-project-blockers/) as a way to speed up routine approvals. Agree it in writing with your sponsor at kickoff, and use it only for low-risk, reversible decisions.

Is a blocker log the same as a RAID log?

A RAID log tracks risks, assumptions, issues, and dependencies across the whole project. A blocker log is narrower: it tracks work that is stuck right now, the person who must act, and the date they need to act by. You can keep blockers as a filtered view of your RAID or issue log so there is one place to update.

Who should own a blocker when the stakeholder side has several reviewers?

Name one person on the stakeholder side as the owner, and ask them to collect and return the reviewers' feedback as a single answer. [Project-Management.com recommends](https://project-management.com/how-to-avoid-blockers-on-a-project/) holding feedback meetings and combining comments from multiple reviewers. Put that owner's name in the blocker log so reminders and escalation go to one person.

Tools for Managing Project Blockers with Stakeholders

Compare spreadsheets, task tools like Jira or Asana, and sponsor-facing tools for stakeholder blockers, with criteria, a blocker log and message templates.

The right tool for blockers that involve stakeholders lets the person who has to clear the blocker see the request and answer it without a seat in your team's tool. Each request needs an owner and a due date, follow-ups need to go out on time, and the decision needs to be recorded next to the work it unblocks. A spreadsheet or your existing task tool can do this on a small project. A sponsor-facing tool helps most when the blockers sit with clients or executives who never log in.

Why do project tools struggle with stakeholder blockers?

Project tools struggle with stakeholder blockers because in many team tools a blocker is a status on a ticket, and the client, sponsor, or executive who can clear it may not have a seat or open the board. A tool for this job has to reach the person who holds the decision, not just label the work as blocked.

Nimble's handbook defines a blocker as "something that prevents progress within the agreed-upon parameters", which covers missing information, missing credentials, unclear requirements, and scope changes. Several of those can sit with the client. Go through Atlassian's list of the most common project blockers and mark which ones on your project wait on someone outside the team. Those are the blockers your tool choice has to handle.

What criteria should I use to pick a blocker tool?

Pick a blocker tool by whether a stakeholder can see and answer a request without a paid seat, whether reminders and escalation happen without you sending them by hand, whether the decision is recorded with who and when, and whether each blocker links to the delivery ticket it holds up. Score every candidate against the same list:

Stakeholder access without a seat. Can a client or executive view and answer a request without a paid licence or a login?
Owner on the stakeholder side. Can each blocker name the one person who must act, not just a team or a company?
Due dates and reminders. Does the tool follow up before and at the due date, or do you have to remember?
Escalation path. Can an overdue request go to a named next person?
Audit trail. Is the answer recorded with who decided, what they decided, and when?
Link to delivery tickets. Does the blocker point to the task or deliverable it holds up?
Waiting-on-whom view. Can you see at a glance everything waiting on each stakeholder?
Cost and setup effort. What does it cost for your team and your stakeholders, and how much setup comes before the first request goes out?

How do the main tool types compare?

Blocker tool types compare most clearly on stakeholder access without a seat, reminders, audit trail, and links to delivery tickets. A spreadsheet is easy to share but manual, a task tool links natively to tickets, a chat channel is quick but scattered, a form suits repeat sign-offs, and a dedicated sponsor-facing tool is built for people outside the team.

Confirm the details against your own plan and settings before you commit.

Tool type	Stakeholder access without a seat	Reminders and due dates	Audit trail	Link to delivery tickets	Best fit
Spreadsheet or shared doc	Usually yes, by sharing	Manual	Only if you keep it	Manual links	Small projects with few stakeholders
Task tool such as Jira, Asana, Monday or Linear, with a blocked status or field	Depends on the guest and viewer rules on your plan	Due dates yes; ask whether reminders reach people outside the workspace	Ticket history	Native	Blockers inside the team
Chat channel	Only if the stakeholder is in the workspace	Manual	Scattered in threads	Manual	Quick questions with internal sponsors
Form or approval workflow	Depends on whether the form can be answered without a login	Depends on whether the form tool sends reminders to people outside the team	Should keep each response with name and time; check the response history	Depends on whether a response can link to or create a task in your task tool	Repeat sign-offs with a fixed format
Dedicated sponsor-facing tool	Should let the sponsor answer without an account; confirm in a trial	Should send reminders and escalate without you; confirm in a trial	Should record who decided what and when; confirm in a trial	Ask which task-tool connectors are live and which are in early availability	Client and executive blockers on time-bound projects

Unblockd sends asks to the sponsor by email with one-tap answers (no account), or answered by replying to the email.

If your shortlist includes Jira, Asana, Monday or Linear, ask each one the same questions before you decide:

What do the guest or viewer rules on your plan allow, and does a stakeholder need a paid seat to answer?
Do people outside the workspace get notifications when a blocker is assigned to them or becomes due?
Can a blocker name an owner who is outside the workspace, or only a teammate?
Can you filter or report on everything waiting on one named stakeholder?

Some task tools now market blocker features. ClickUp, for example, has a product page about detecting blockers in real time. Check whether a feature like that reaches people outside your workspace.

When is a spreadsheet or my task tool enough?

A spreadsheet or your existing task tool is enough when you have few blockers, stakeholders answer email or chat reliably, and you are willing to send follow-ups yourself. Move to a more specialised tool when requests go unanswered, when you can't see what is waiting on whom, or when a sponsor hears about a blocker late.

Use this decision rule:

If every blocker can be cleared by someone with a seat in your task tool, add a blocked status and a "waiting on" field. Stop there.
If outside stakeholders hold some blockers but answer quickly, keep a shared blocker log and link each row to its ticket.
If outside stakeholders hold blockers and you spend real effort chasing them, shortlist tools that offer seat-free access, automatic reminders, and escalation.

How do I set up a blocker log my stakeholders will act on?

A blocker log stakeholders will act on says what is blocked, which deliverable it holds up, the named person who must act, the date they need to act by, and what happens if nobody does. Keep one line per blocker, one question per request, and an escalation name on every row so follow-up never depends on memory.

Nimble's tracker uses fields for Application, Raised On Date, Expected Resolution Date, and Status (Open or Closed), plus a template with Background, Effects On Project, Actions Needed, and Resolution. Build on that and add the fields that matter for stakeholders:

Blocker: [short description]
Deliverable or ticket: [link to task or deliverable]
What we need: [decision / review / help / information]
Owner (stakeholder side): [named person]
Raised on: [date]
Needed by: [date]
Days open: [number]
Impact if late: [what slips, and the effect on schedule or budget]
Escalate to: [named person] if no answer by [date]
Status: [Open / Waiting / Escalated / Closed]
Decision and date: [what was decided, by whom, when]

Keep the "what we need" line to a single question. The stakeholder should be able to answer it without opening anything else. Update the "days open" line each time you review the log, so you can see which blockers have waited longest.

What should the message to the stakeholder say?

A message asking a stakeholder to clear a blocker should name the decision, review, or help you need, the date you need it by, and what happens to the work if the answer is late. Keep the message to one clear question with a link to the evidence, short enough to answer from a phone.

Nimble's project managers email the main stakeholder on the client side about the impact on schedule and budget. Use this template:

Subject: Decision needed by [date]: [deliverable]

Hi [name],

To keep [deliverable] on track for [milestone], we need your [decision / review / help] on:
[one clear question, with options A and B if there are options]

If we have your answer by [date], we stay on plan. After that, [specific effect on schedule or budget].

The evidence is here: [link to draft, ticket, or file].

Thanks,
[your name]

For follow-ups, change only the first line: "A reminder that [deliverable] needs your [decision] by [date]."

What do I do when the stakeholder doesn't respond?

When a stakeholder doesn't respond, follow an escalation path agreed at kickoff, before any blocker existed, so escalating feels like following the plan rather than a complaint. Write down who answers each type of request, how quickly, and who decides if they can't, then use the same ladder every time.

Send the request with a clear due date.
Send a reminder before the due date.
On the due date, ask whether someone else can decide. Unito suggests appointing alternates for approvals.
After the due date, raise the blocker with the sponsor, citing the impact line from your log.
Record the outcome in the log, even if the outcome is "proceeding on option A as agreed".

For slow reviews, Project-Management.com recommends holding feedback meetings that combine comments from several reviewers, and asking regulated reviewers such as legal teams for their review calendars early.

How should blockers appear in my status report?

Stakeholder blockers belong near the top of your status report: what is waiting, on whom, since when, and what slips if it stays open. Below that, list the blockers you cleared and the decisions recorded, so the sponsor sees both what needs them and what has already moved forward.

Over time, note which blockers keep coming back and which stakeholders they cluster around, and raise that pattern with your sponsor as a question about how decisions get made, not as blame.

Waiting on you: [request] since [date], needed by [date]. Days open: [number]. Impact: [effect].
Cleared this period: [blocker], decided by [name] on [date].
Pattern to discuss: [type of request] is often waiting on [role].

Will a new tool fix slow stakeholders?

A new tool will not fix slow stakeholders on its own. A blocker tool makes requests easier to see and answer, but it can't create urgency or authority that the project doesn't have. Agree who decides, how fast, and which approvals can be dropped first, then pick the tool that carries those rules out.

If a stakeholder shows no sense of urgency or communicates poorly, Wrike's advice is to map stakeholders on a power/interest grid, meet them one to one, and work out what motivates them. Reducing the number of requests helps too. Unito describes removing stakeholders from routine approvals and using implicit approval, where a release goes ahead unless someone objects.

How do I build a shortlist of blocker tools?

Build a shortlist by listing the stakeholders who held your recent blockers, scoring each candidate on seat-free access, reminders, escalation, audit trail, and ticket links, and running one live blocker through each finalist from request to recorded decision. Keep the tool where the stakeholder answered most easily and you could see the outcome next to the work.

Copy one line per candidate and fill it in as you test:

[Tool] | seat-free access: [yes/no] | reminders: [yes/no] | escalation: [yes/no] | audit trail: [yes/no] | ticket link: [yes/no] | test blocker result: [notes]

Bring the filled-in lines to your next sponsor meeting so the choice rests on what each tool did with a real blocker.