Use this worksheet when blocked work has stopped being a small delay and has become an operating decision.

This is a support asset, not a workflow guide. Its job is to help you define when a blocked item should stay active, when it should pause, when it should escalate, when it should be re-scoped, and when the cleanest answer is to close it out instead of letting it drift.

Use this after the dependency or review path is already clear enough to name. If one formal operating decision still is not enough because the original plan itself has broken down, continue next to Scope Reset and Recovery Worksheet for Solo Operators.

When to use this worksheet

Use it when:

  • proposal review has stalled beyond an ordinary review window,
  • required client inputs have not arrived and the work cannot keep pretending it is on track,
  • delivery is blocked on approval, assets, or a client-side decision,
  • billing or offboarding cannot close because one unresolved dependency is still hanging over the project.

If the bigger problem is still defining the dependency itself, start first with Client Input Dependency Worksheet for Solo Operators.

If the dependency and delay have already damaged the original plan so badly that ordinary escalation is no longer enough, continue next with Scope Reset and Recovery Worksheet for Solo Operators.

What this worksheet does not decide

This worksheet should not decide:

  • the whole delivery or proposal workflow,
  • whether the original scope was correct,
  • the full client communication strategy across the relationship,
  • your pricing model or legal policy.

Those belong on the workflow, FAQ, and agreement pages. This asset only defines the operating decision once blocked work can no longer stay in limbo.

How to use it

  1. Document one blocked item or stage at a time.
  2. Name the dependency that is actually blocking progress.
  3. Set a threshold for when waiting stops being acceptable.
  4. Decide the allowed next states before frustration starts driving the decision.

Practical rule: if everyone knows work is stalled but no one can say what happens next, the project is already in unmanaged limbo.

Escalation and pause-state worksheet

Blocked item or stageBlocking dependencyDuration / severity thresholdOwner of escalationAllowed next statesCommunication requiredBilling / scope implicationRestart condition
Proposal reviewfinal client decision missingreview open beyond agreed windowoperator or proposal ownerwait, escalate, re-scope, close outrestate decision needed and impact on kickoffproposal may expire or require revised timingone approved response path returns
Delivery milestonecontent, asset, or approval missingblocked long enough to affect due dateoperator or delivery ownerpause, proceed with assumptions, split milestone, re-scopevisible blocked update with named dependencybilling trigger may move or milestone may splitrequired input arrives or revised milestone is approved
Billing / offboarding closefinal signoff or finance action missingcloseout cannot complete by planned end dateoperator or account ownerwait, escalate, separate financial close, close out operationallydirect closeout status update naming unresolved itemtestimonial ask or archive timing may shiftsignoff or payment state becomes explicit

Blocked item or stage

Write the blocked work as one specific item:

  • proposal review round 2,
  • milestone 3 approval,
  • final invoice close,
  • offboarding signoff.

Avoid broad labels like “the project” unless the whole project is truly paused.

Blocking dependency

Define the exact thing causing the block:

  • client approval,
  • missing assets,
  • procurement step,
  • unresolved conflicting feedback,
  • unanswered scope question.

If the dependency is still vague, go back to Client Input Dependency Worksheet for Solo Operators first.

Duration / severity threshold

Write the point where ordinary waiting turns into a formal decision.

Examples:

  • 3 business days past the review deadline,
  • once the due date is at risk,
  • once work cannot continue without assumptions,
  • once closeout timing and billing are no longer aligned.

This threshold should be explicit enough that your future self does not have to renegotiate it emotionally every time.

Owner of escalation

Document who is responsible for:

  • deciding when the threshold is crossed,
  • sending the escalation message,
  • updating the system status,
  • pushing the work into the next state.

If the escalation owner is unclear, the blocked work usually stays visible but unmanaged.

Allowed next states

Define which options are actually allowed for this kind of block:

  • Pause
  • Re-scope
  • Proceed with assumptions
  • Wait
  • Close out

Not every blocked state should allow every option. For example, proceeding with assumptions may be acceptable in one content draft stage and unacceptable in a billing or approval stage.

Communication required

Write what must be communicated when the threshold is crossed:

  • what is blocked,
  • what dependency caused it,
  • which state is being chosen next,
  • what that means for timing, scope, or closure.

If communication only says “just checking in,” the operating decision stays hidden.

Billing / scope implications

Document whether the blocked state changes:

  • invoice timing,
  • milestone closure,
  • budgeted scope,
  • retainer or project-end timing,
  • whether a change request or separate closeout state is needed.

This matters because blocked work often creates hidden commercial consequences long before anyone names them.

Restart conditions

Write what must happen before active work resumes:

  • named client input arrives,
  • approval is explicit,
  • re-scoped milestone is accepted,
  • updated due date is confirmed,
  • payment or signoff state is visible again.

Do not restart from vague optimism. Restart from a visible condition.

Suggested use cases

Proposal review stalls too long

Best when the proposal is still open, feedback is incomplete, and kickoff timing is now affected.

Use with:

Required client input does not arrive

Best when the missing dependency is already identified but waiting indefinitely is no longer acceptable.

Use with:

Delivery cannot continue without approval or assets

Best when a live milestone has become blocked enough that you need to choose between pause, split, or re-scope.

Use with:

Billing or offboarding cannot close

Best when one final unresolved dependency is keeping the project in awkward half-finished status.

Use with:

Warning signs of indefinite limbo

  • blocked work still appears active because nobody wants to pause it,
  • the same dependency is being mentioned repeatedly without a state change,
  • timing slips but no one updates scope, billing, or next-step expectations,
  • the team keeps rewriting follow-up messages without deciding anything,
  • everyone knows the work is stalled but the operating record still looks normal.

What to do after completing the worksheet

Completion standard

This worksheet is complete when:

  • one blocked item is named clearly,
  • the blocking dependency is specific,
  • the escalation threshold is explicit,
  • the allowed next states are defined,
  • restart conditions are visible enough to prevent indefinite limbo.