Use four different labels
Teams lose time when every concern is called a blocker. Use four categories instead.
An unknown is a question without an answer yet. A risk is a possible event with a known impact. A dependency is an input or action outside the current task. A blocker is a condition that prevents useful progress now.
The same issue can move between categories. Missing content may be a dependency while developers build the template, then become a blocker when final integration begins.
Missing access
Repository, hosting, analytics, design or third-party access is a blocker when the first planned work requires it and no safe substitute exists.
Record the exact account, permission level, owner and needed date. “Access pending” hides the action required to resolve it.
No decision owner
Development can continue through many missing details, but not through a business decision nobody is authorised to make.
Examples include choosing which workflow is correct, approving a legal constraint or deciding which system is the source of truth. Name the decision, the person with authority and the deadline.
Unclear acceptance criteria
Requirements do not need to predict every edge case. They do need to make the first outcome testable.
If the team cannot tell whether the work will be accepted, clarify the critical behaviour before building it. Smaller details can remain assumptions if they are documented and inexpensive to change.
Unresolved integrations or technical dependencies
An integration is a blocker when its contract, credentials or feasibility determines the architecture of the first work. It is a risk when a known fallback lets delivery continue.
Do a bounded technical check, identify the fallback and decide how much work can proceed safely. Do not turn every dependency into an open-ended discovery project.
Missing content, data or approvals
Content and data become blockers when they determine structure, migration or acceptance. External approval becomes a blocker when work cannot be released or validated without it.
Ask what can be built with representative data, what must be final and by when. This converts a vague wait into an owned delivery condition.
Conflicting requirements
Two individually clear requirements can still conflict. If satisfying one breaks the other, the team needs a prioritised decision before implementation.
Do not ask developers to choose silently. Escalate the trade-off with its user, cost and timeline impact.
No usable environment
An absent development or test environment blocks work when there is nowhere safe to build, integrate or verify it. Confirm who prepares the environment, the configuration it needs and the minimum date for access.
Manage blockers as decisions
Keep a short blocker log with:
- the blocked outcome,
- the condition causing it,
- one owner,
- the next action and date,
- the fallback, if one exists,
- the decision if the date is missed.
Use the project readiness checklist to see blockers in context. Then apply the start, caution or stop decision instead of waiting for every unknown to disappear.
When the blockers are cleared, carry the remaining risks and assumptions into the project kickoff checklist.