Delivery readiness means having enough confirmed information, access, capacity, and decision authority to start the next stage of client work responsibly. An accepted proposal and a kickoff date do not, by themselves, establish that the work is ready.
Before execution starts, check the agreed scope, required inputs, approvals, schedule dependencies, delivery capacity, and starting conditions. Then make an explicit decision: start, start a bounded part of the work, or wait for a blocker to be resolved.
You do not need every detail of the whole project settled. You do need to know whether an unresolved detail could materially change the work you are about to perform.
Readiness is a decision, not a completed form
A client can fill in an onboarding questionnaire while leaving an important question unanswered. A team can complete twenty setup tasks while still lacking permission to access the system it must change.
Use the checklist to inspect evidence, not to count ticks. “Access requested” is different from “access granted and tested.” “Feedback contact identified” is different from “the person authorized to approve this deliverable has been confirmed.”
Asana's kickoff guide covers aligning people around goals, scope, roles, and next steps. The readiness check below addresses the operational question that remains: can the next work actually proceed under the conditions you have agreed?
Read the decision map as text
- Define the next stage: Name the work and the conditions needed to begin.
- Check actual evidence: Verify scope, inputs, access, approvals, and capacity.
- Assess the open items: Identify blockers, owners, and required-by dates.
- Record the starting decision: Start, make a bounded start, or wait and revise.
Check the conditions needed for the next stage. One critical blocker is not canceled by several completed minor checks.
For the earlier commercial stage, use the guide to scope a project before pricing; readiness checks the conditions after the work is agreed.
Check six things before you release work
Adapt these checks to the service. A small editing engagement needs less documentation than a system implementation, but either can be blocked by one essential missing input.
| Area | What to confirm | Evidence that makes it usable |
|---|---|---|
| Scope and completion | The deliverables, exclusions, review boundaries, and acceptance checks are understood | The current agreed scope, with ambiguities resolved |
| Client inputs and access | Materials and permissions required for the next stage are available and usable | A reviewed content sample, working access, or another relevant check |
| Decision authority | The right person can approve the upcoming work and consolidate feedback | A named approver and an agreed feedback route |
| Schedule and dependencies | The sequence accounts for client reviews, outside inputs, and availability | A schedule tied to dependencies, not just a launch date |
| Delivery capacity | People, expertise, and required tools are available for the commitment | Confirmed assignments and realistic capacity |
| Starting conditions | Conditions agreed before work begins have been addressed | The applicable agreement and confirmed status, including payment where required |
For each missing item, record what it affects, who owns the next action, and when it must be resolved. A list of missing inputs without those details is difficult to act on.
Ask for usable inputs, not “everything”
Tell the client what is needed, where to provide it, and what qualifies as ready. “Please send your content” leaves room for an unapproved draft or a folder of unrelated files.
A more useful request is:
Copy-and-customize template: Replace the text in square brackets with your project details before using it.
Please upload the approved service descriptions for the three pages in the first phase to [agreed location]. We need the current version, with product details confirmed by [responsible contact]. If any description is still being revised, tell us which one and when approval is expected.
Check a representative input before relying on the whole set. For a data project, an export that opens is not necessarily suitable for migration. For a design project, a low-resolution logo is not necessarily suitable for the agreed output.
For access, use an appropriate account invitation or secure method agreed for the project. Check the permission needed for the specific work; do not collect broad credentials merely because they might be useful later.
If the client cannot provide an input you assumed they would supply, discuss the alternative. You may need to add research or content preparation, change the sequence, or revise the engagement. Do not silently absorb substantial new work or proceed as though the input exists.
When authority or feedback is unclear, establish a client approval process that can support the upcoming work.
Separate a blocker from an ordinary open question
Not every unknown needs to stop delivery. Assess it against the next stage, the potential rework, and any material consequence of proceeding.
| Open item | Likely treatment | Why |
|---|---|---|
| Missing approval of the page structure you are about to draft | Resolve before drafting that structure | A different decision could invalidate the next work |
| Access needed only for a later implementation stage | Track with an owner and required-by date | Earlier independent work may still be feasible |
| A minor wording preference within an agreed revision process | Handle through that process | The agreed work already provides a route to resolve it |
| Unconfirmed claims needed for public-facing copy | Obtain confirmation before publishing those claims | Plausible wording is not evidence of accuracy |
| An unknown requirement that may change the solution | Clarify or scope an investigation | Implementation may be premature |
This is an assessment, not a universal set of rules. A seemingly minor issue can be material in a particular service. If specialist review or authorization is required, a checklist does not replace it.
Choose one of three starting decisions
Start the agreed stage when its necessary inputs and conditions are confirmed, and remaining open items have a workable route.
Start a bounded part when that work is useful on its own, does not depend on the blocker, and will not create misleading expectations about the rest of the project. Confirm the boundary, any schedule implications, and the decision point for proceeding further.
Wait or revise the plan when proceeding would require material guesses, unauthorized work, or a commitment you cannot responsibly support. Name the blocker and next decision instead of declaring the whole client “not ready.”
Do not invent an 80% readiness threshold. Five minor checks passed cannot cancel one critical missing approval. The relevant question is whether the necessary conditions for this stage are met.
Worked example: a project that is only partly ready
This is a hypothetical scenario, not a reported client result.
A copywriter has agreed to rewrite five service pages. The first draft is planned for the following week, after receiving approved product information and confirmation of the page structure.
At the readiness check, the client has supplied current information for three services. Two descriptions are still being revised. The nominated contact can gather feedback but cannot approve the page structure.
The copywriter records two issues: the authority question affects the structure of all five pages, while the missing product information affects two specific pages.
Writing three pages immediately is not automatically a safe partial start, because those pages still depend on the unapproved structure. The next action is to confirm the approver and structure. After that approval, drafting the three supported pages may be a useful bounded stage if the client agrees.
The copywriter explains that the original five-page draft date needs review. The remaining pages receive dates only when their inputs and review requirements can support a realistic commitment. No one treats the partial start as proof that the original schedule remains intact.
Use a small readiness record
Copy this for the next stage of your engagement:
Copy-and-customize template: Replace the text in square brackets with your project details before using it.
Engagement and stage: [Client, project, and work being considered.]
Current scope: [Link or version reference.]
Necessary conditions: [Inputs, access, approvals, capacity, and other agreed requirements.]
Confirmed evidence: [What has been received, checked, or approved, and where it is recorded.]
Open item / critical blocker: [What is missing; which next work cannot responsibly proceed and why.]
Independent work: [Useful work that does not depend on the blocker, or none.]
Authority: [Who can authorize this starting decision and where the decision is recorded.]
Effect of proceeding: [What could be wrong, wasted, delayed, or unauthorized.]
Owner and required-by date: [Who must act and when.]
Starting decision: [Start, bounded start, or wait/revise.]
Next review: [Date or event that triggers reconsideration.]
Keep the record where the delivery owner can find it. Do not duplicate the whole agreement into several documents; link to the authoritative version.
Send a confirmation the client can answer
Choose the message that matches the evidence. These three alternatives continue the fictional five-page copy project at different readiness states; they are not three messages to send together.
Start: the agreed stage is ready
Subject: Five-page copy project — drafting confirmed
We have the approved structure, confirmed product facts for all five pages, the named approver and the starting conditions recorded against the current scope. We can begin drafting on November 2, 2026. Please use the agreed document for consolidated comments. I will provide the first progress checkpoint November 4 at 3:00 p.m., America/New_York. If a material input changes, I will review its effect before using it.
Bounded start: independent work is ready
Subject: Five-page copy project — three-page drafting boundary
The authorized approver has now confirmed the structure, and product facts for pages A–C are approved. We can draft only those three pages from November 2, 2026, as recorded in your approved partial-start decision. Pages D–E wait for the product owner’s confirmed facts. Please supply them by November 4 at 3:00 p.m., America/New_York, or confirm a realistic date. I will review the remaining schedule then; this partial start does not preserve the original five-page draft date automatically.
Wait or revise: a critical blocker remains
Subject: Five-page copy project — structure approval needed
The three available service descriptions have been checked, but the structure affecting all five pages is still unapproved. Drafting those pages would risk producing the wrong work, so we will wait on drafting. Please confirm the authorized approver and their structure decision by November 2, 2026, 3:00 p.m., America/New_York. I will review readiness and propose any revised production dates after that decision. No independent drafting has been authorized.
A different service uses the same logic: an editing project may start on an approved chapter while another chapter waits, only if changes to the missing chapter cannot invalidate the agreed independent work. A task count or readiness percentage does not make that dependency disappear.
Adapt the message to the actual starting decision. Do not announce a delay as a punishment, imply automatic extra fees, or convert silence into approval. Handle changes to timing or charges through the applicable agreement and a clear conversation.
After the starting decision, keep the position visible with a clear client project update.
Recheck when a material condition changes
Readiness is tied to a stage and a set of conditions. Revisit it when a required input changes, an approver becomes unavailable, the scope changes, or the delivery assignment is no longer feasible.
You do not need a new ceremony for every minor edit. Recheck the items affected by the change and update the next action. Once execution begins, use normal project updates, approval records, and risk controls to keep the position visible.
For your next engagement, identify the first stage that consumes meaningful delivery effort. Check its necessary conditions before releasing it, and record the starting decision where both sides can understand it.
Frequently asked questions
Does every project need a kickoff meeting?
No single meeting format fits every service. A small engagement may be ready after a clear written confirmation. Use a meeting when discussion is needed to resolve responsibilities, dependencies, or conflicting interpretations; keep a record of the decisions either way.
Can work start before every client input arrives?
Sometimes. Start only the work that can proceed responsibly without those inputs, confirm its boundaries, and make the effect on remaining work visible. Do not describe a partial start as full-project readiness.
Is readiness a guarantee that delivery will go smoothly?
No. It checks known conditions and exposes important unknowns before a commitment. New problems, estimating errors, and changing circumstances can still arise during delivery.