When this matters
“Waiting for the client” conceals who must answer, what they must decide and when the answer affects work. A readiness score can show that a project should pause; it cannot make the missing decision for the team.
A practical approach
- Write the blocker as a decision or deliverable: “Approve the payment provider and contract”, not “payment unclear”.
- Name one accountable owner, even if several people contribute. The owner coordinates the answer; they need not do all the work.
- Set an evidence-based closure condition, such as an approved API contract or confirmed access to the test environment.
- Record the latest useful decision date and the work affected. If it slips, make the impact on scope or start date explicit.
Example
A project kickoff is planned for Monday, but production API credentials are missing. “Developer to investigate” is too vague if only the client administrator can grant access. Assign that administrator as decision owner, specify test access as the evidence, and set Thursday as the deadline for a Monday start. If access is late, move the integration work rather than pretending the project is ready.
Make the next decision
Not every open item is a blocker. A small copy change may be resolved while other work proceeds; missing legal approval for processing personal data may stop the affected work. Keep the blocker list short and review it at each readiness check. The tool helps identify which gaps need an owner before the start decision.