Break a large initiative into delivery phases

Make a large outcome manageable

Use project planning when the initiative is too broad to deliver safely in one feature run. Examples include introducing workspace permissions, replacing a legacy integration, or modernizing a product area across several services.

Describe the desired outcome, current system, affected repositories, constraints, dependencies, and what can be delivered incrementally. Ask for phases that each have observable acceptance criteria and a clear boundary.

Shape the project in Plan

1. Open a new session and select Plan.
2. Describe the initiative and attach supporting context.
3. Ask for a project plan with ordered phases, dependencies, acceptance criteria, and risks.
4. Review and refine the plan before starting implementation.

Plan a project to replace our legacy notification integration.
First inspect the current repositories and delivery constraints.
Propose phases that preserve existing behavior during migration.
For each phase, include scope, dependencies, acceptance criteria,
verification, rollout considerations, and what remains out of scope.
Do not start implementation. Ask about unresolved product decisions.

Approve the plan, then deliver phases deliberately

Inspect the resulting project and phase artifacts. Check that early phases create useful foundations and that later phases depend on explicit, verifiable outputs.

• Each phase has a bounded outcome and acceptance criteria.
• Dependencies and sequencing are clear.
• Compatibility and migration steps preserve ongoing usage.
• Verification and rollout needs are included.

Start phases explicitly and in order through Full Lane using the accepted phase context. Review the evidence for one phase before authorizing the next. A phase plan does not itself mean those phases have started or shipped.

Complete project planning guide · Deliver a phase through Full Lane