Project readiness before kickoff means the delivery team can explain what was authorized, what outcome is expected, who can decide, what inputs are required, and what remains unresolved. A meeting invitation does not establish those conditions. Use kickoff to confirm a defensible start position and resolve decisions that need the client in the room.
A signed agreement establishes a commitment. Readiness establishes whether the proposed work can responsibly begin.
What to confirm before a client project starts
- The delivery team understands the authorized scope and relevant sales commitments.
- Required inputs, access, dependencies, and decision authority are visible.
- Unresolved items have owners, next actions, and a clear effect on the proposed start.
- The team knows which work may proceed and which work remains restricted.
Translate the agreement into delivery requirements
A proposal, statement of work, or other agreement may contain deliverables, exclusions, assumptions, milestones, acceptance expectations, and client responsibilities. Bring those details together before the delivery team commits to a plan. Include relevant sales discussions so the team can identify a promise that has not made it into the working record.
Ask the team and client to describe the expected result. If their descriptions differ, record the gap and route it to the person with authority to clarify it. A team should not resolve a material contradiction by quietly choosing whichever interpretation makes the schedule easier.
This is an operational review of the work to be delivered. It does not replace the governing agreement or change who has authority to approve commitments.
Use six questions to assess the proposed start
The following questions are a practical discussion guide. The answers need supporting evidence, not simply a completed box on an intake form.
1. What work is authorized?
Identify the deliverables, boundaries, assumptions, and relevant acceptance expectations. Distinguish confirmed work from a request still being discussed. If a client expects implementation but the agreement describes recommendations, make that difference visible before scheduling implementation tasks.
2. What outcome are we working toward?
Describe the change the client wants and the evidence that will help assess it. A deliverable can be clearly named while its purpose remains ambiguous. Confirm the outcome with the appropriate stakeholder rather than substituting the delivery team's preferred interpretation.
3. Who can make and approve decisions?
Record who provides information, who owns delivery actions, and who can approve changes or accept outputs. These roles may belong to different people. Establish a route for a decision that cannot be resolved within the working team.
4. What information, access, and dependencies do we need?
List the inputs needed for the first authorized activities. Record availability, owner, and needed-by point. Use approved access processes and secure invitations; the readiness record should show access status, not store passwords or secret values.
5. What remains unresolved, and what does it affect?
Evaluate each important open item against the work it touches. A known owner is useful, but ownership alone does not establish that the issue is controlled. Record the next action, timing, consequence, and any restriction while it remains open.
6. What may the team begin?
Make the start decision explicit. The Client Start System uses Ready, Conditionally Ready, and Not Ready outcomes and distinguishes normal open items, conditions, and blockers. The practical purpose is to make permitted and restricted work visible before delivery begins.
A conditional start needs stated limits. Avoid using “we will sort it out later” as a substitute for deciding what those limits are. Where unresolved authority or a dependency prevents a responsible start, escalate the affected work to the authorized decision-maker.
Preserve the Client Start Position
The Client Start Position is the evidence-backed account of the project at the boundary between preparation and delivery. In The Client Start System — 2nd Edition, it preserves authorized work, outcome, authority, evidence, readiness, conditions, dependencies, permitted and restricted work, and first-week commitments.
Its value is continuity: delivery receives a usable account of what is true, what is open, and what must happen next. Keep the record accessible to the people doing the work and reconcile it when kickoff changes the shared understanding.
Example: a kickoff date with missing access
Workflow Lift project readiness example
Illustrative example, not a reported client result: A consulting team is preparing to review a client's operating process. Stakeholder interviews are authorized, but the system access needed to validate transaction data has not been approved.
The team should identify which activities depend on that access. The authorized decision-maker might permit interviews while restricting data validation, with a named access owner and a point for reviewing the restriction. If the missing access prevents the first required activity, the team needs a different start decision.
The important distinction is the stated boundary. Neither a kickoff date nor a confident status message resolves the missing dependency.
Use kickoff to confirm decisions and alignment
Build the agenda around the shared delivery position: outcomes, scope boundaries, authority, open conditions, working arrangements, and the first commitments. Give unresolved decisions a place on the agenda and identify who needs to participate.
After the meeting, reconcile any changed interpretation, approval, owner, or dependency. Transfer the updated position into delivery and review the first week so startup conditions remain visible. New scope requests should enter the change-control process instead of becoming informal commitments.
Does every question need an answer before kickoff?
No. The useful distinction is whether uncertainty has been evaluated against the proposed work. Record what remains open, how it is controlled, who owns it, and what the team may do. The start decision should reflect those conditions rather than the desire to keep the date.
Turn readiness checks into repeatable client starts
Explore the working documents in the Client Start System Toolkit, or choose the bundle for the accompanying methodology.
View the Client Start Toolkit →Related guides: Build a client onboarding checklist and compare agency onboarding templates.
Put the method into practice
Explore The Client Start System — 2nd Edition for the full method from agreement review through readiness, kickoff, ownership transfer, and first-week control. If your main problem is already in active delivery, use the Workflow Lift book guide to compare the starting points.