Use this worksheet when the real problem is not just that work is blocked, but that the client-side dependency was never defined clearly enough in the first place.

This is a support asset, not a workflow guide. Its job is to help you write down what input is required, who owns it, when it is due, what acceptable quality looks like, and what should happen if it does not arrive.

Use this when the missing client-side item itself is still vague. If the dependency is already documented and the real problem is deciding what happens next because the work is still blocked, move to Escalation and Pause-State Worksheet for Solo Operators.

When to use this worksheet

Use it when:

  • kickoff depends on assets, access, or stakeholder answers that are still vague,
  • milestone work cannot continue until the client provides content, files, or approvals,
  • review or billing keeps stalling on missing input,
  • updates still say “waiting on client” without enough detail to act on.

If the bigger problem is still the stage boundary itself, use Project Start Readiness and Handoff Boundary Worksheet for Solo Operators first.

What this worksheet does not decide

This worksheet should not decide:

  • the whole onboarding or delivery workflow,
  • whether the project should continue despite the delay,
  • how the full escalation policy should work across all clients,
  • what tool stack should hold the dependency record.

Those belong on the workflow, FAQ, and system-design pages. This asset only helps you define one client dependency clearly enough to track and communicate it.

How to use it

  1. Document one input dependency at a time.
  2. Name both a client-side owner and your-side owner.
  3. Define the due stage or date before the work depends on it.
  4. Write one fallback or escalation path before the delay happens.

Practical rule: if a missing item could block work but you have not defined its owner, due point, and acceptable format, it is still unmanaged.

Client input dependency worksheet

Required input / itemClient-side ownerYour-side ownerDue stage / dateFormat / quality expectationWhat blocks if missingFallback or escalation path
Brand files and accessclient marketing leadoperatoronboarding before kickoffcorrect file set, active login, current brand assetskickoff and first milestone setuppause kickoff and name exact missing files
Proposal answers or stakeholder clarificationsapproval owner or client leadoperatorproposal review round 1written answer in agreed review pathrevision close and approval decisionsend bounded follow-up and hold review state
Content or source material for milestone deliverydesignated client contributoroperator or delivery ownerbefore milestone execution startscomplete draft, approved source, usable file formatactive work and delivery due datesplit milestone or move to visible blocked state
Final signoff item or handoff approvalfinal approveroperatorbefore invoice close or offboardingexplicit written acceptance or decisionbilling closeout and archiveseparate open closeout item and delay testimonial ask

Required input / item

Write the dependency as one specific item, not as a vague category.

Better:

  • homepage copy draft,
  • brand asset folder,
  • legal approver answer,
  • final signoff reply.

Worse:

  • materials,
  • feedback,
  • client stuff,
  • approval.

If the item is broad, break it into smaller records before it becomes impossible to track.

Owner on client side

Document:

  • who at the client side is actually responsible,
  • whether that person owns the answer or only coordinates it,
  • what happens if several stakeholders are involved.

If no client-side owner can be named, the dependency is already weak.

Owner on your side

Document who on your side:

  • requested the input,
  • is tracking its arrival,
  • must update the system when it comes in,
  • communicates the impact if it is late or incomplete.

This avoids the common failure mode where the dependency is “known” but no one is actually watching it.

Due stage / date

Write the dependency against a visible stage or date:

  • before kickoff,
  • before milestone 1 begins,
  • before client review closes,
  • before invoice can trigger,
  • before offboarding can start.

The due point should be earlier than the moment total blockage becomes painful.

Format / quality expectations

Define:

  • where the input should be delivered,
  • what format is acceptable,
  • what counts as complete enough to use,
  • what would still count as incomplete.

Examples:

  • editable doc, not screenshots,
  • current source files, not outdated exports,
  • one written decision from the approval owner, not several conflicting comments,
  • complete login with required permissions, not a pending invite.

What blocks if the input is missing

Write the consequence directly.

Examples:

  • kickoff cannot start,
  • milestone cannot move from blocked to active,
  • review cannot close,
  • invoice cannot trigger cleanly,
  • offboarding cannot reach final signoff.

This is what turns the missing item from annoyance into an explicit operational dependency.

Fallback or escalation path

Define one practical response:

  • follow up with a named due date,
  • move the stage into blocked status,
  • split the milestone,
  • proceed with a smaller safe subset,
  • escalate to the approval owner or client lead,
  • pause the transition until the item arrives.

Do not improvise the fallback every time. The point is to reduce ambiguity before the delay occurs.

If the fallback is no longer enough and the blocked work needs a formal pause, re-scope, proceed, or close-out decision, move next to Escalation and Pause-State Worksheet for Solo Operators.

If the repeated dependency failure has already made the old plan unreliable, move next to Scope Reset and Recovery Worksheet for Solo Operators instead of trying to patch the same plan again.

Suggested use cases

Onboarding inputs that block project start

Best when kickoff depends on access, files, stakeholder details, or approved setup information.

Use with:

Proposal review dependencies

Best when approval or revision work cannot proceed because key answers or decision-maker responses are missing.

Use with:

Delivery assets needed before work continues

Best when active execution depends on content, files, access, or review materials from the client.

Use with:

Approvals or answers needed before billing or offboarding

Best when the work is almost done but one client-side dependency still blocks closure.

Use with:

Warning signs of unmanaged client dependency

  • the same missing item is discussed repeatedly without a recorded owner,
  • client inputs arrive in unusable formats and nobody said what “usable” meant,
  • blocked work still appears active in the system,
  • timeline promises stay unchanged even though required input is missing,
  • the dependency is only described as “waiting on client.”

What to do after completing the worksheet

Completion standard

This worksheet is complete when:

  • the required input is specific enough to verify,
  • both owners are named,
  • the due stage or date is explicit,
  • acceptable format and quality are defined,
  • one fallback or escalation path exists before the item goes missing.