What project readiness means
Project readiness answers one operational question: can delivery safely start now?
That is different from qualifying the opportunity, which asks whether the work is worth pursuing. It is also different from producing a first estimate. A promising lead can still be unready, and an accepted estimate can still depend on decisions nobody has made.
A project does not need every detail to be known before it starts. It does need the important unknowns to be visible, owned and small enough for the team to work around.
1. Scope has a usable boundary
The team should understand the outcome, the work included in the first delivery and what is explicitly outside it.
Check:
- Is the project objective stated in practical terms?
- Is the first release or milestone defined?
- Are important exclusions recorded?
- Is there a process for accepting scope changes?
- Do the estimate and the current scope still describe the same work?
If the estimate was created before the scope stabilised, revisit the software task estimation approach instead of treating the old number as a commitment.
2. Requirements support the first decisions
Readiness does not require a complete specification. It requires enough clarity to start the first meaningful work without guessing at business-critical behaviour.
Look for a clear user or business outcome, acceptance criteria for the first items, known edge cases and a way to clarify the rest. If several stakeholders describe different outcomes, that is a decision gap rather than a documentation gap.
3. Decision ownership is explicit
Someone must be able to answer questions, approve trade-offs and accept completed work. A stakeholder list is not enough if nobody has final authority.
Confirm:
- who owns product decisions,
- who accepts completed work,
- who can approve scope, budget or timeline changes,
- how quickly the team can expect an answer.
A missing detail is not always a blocker. A missing decision owner often is.
4. Access and dependencies are actionable
List every external input the first delivery step depends on: repositories, hosting, design files, analytics, content, credentials, APIs, vendors and approvals.
For each one, record an owner and an expected date. “The client will provide access” is not a plan until the account, permission level and responsible person are known.
Use the project blockers guide to separate a dependency that can be scheduled from one that makes useful work impossible.
5. The delivery setup exists
Before kickoff, the team should know where work is tracked, how changes are reviewed, which environments are available and what “done” means for the first milestone.
The minimum setup usually includes:
- named delivery and client owners,
- a shared source of truth for scope and decisions,
- a communication channel and response expectations,
- access to the first working environment,
- a review and acceptance path,
- a visible list of risks, assumptions and dependencies.
These are small controls, but they prevent the first week from becoming an expensive discovery of who owns what.
Decide: start, start with caution or stop
Start when the first outcome is clear, key decisions have owners, required access is available and remaining unknowns can be resolved during delivery.
Start with caution when work can begin, but a named risk or dependency may change the plan. Make the condition visible and set a review point.
Do not start yet when the team cannot perform useful work, nobody can make a necessary decision or a critical dependency has no owner or date.
Once the readiness decision is positive, use the project kickoff checklist to turn that decision into a concrete first week.