Practical guide
How to plan a project with AI
A credible project plan connects a defined outcome to owned work, feasible dependencies, available capacity, and decision-ready milestones. AI can organize inputs, expose missing links, and calculate candidate schedules. It cannot decide whether an estimate is realistic or whether an owner has actually committed. Build the plan from evidence, then test the critical path with the people who must.
A credible project plan connects a defined outcome to owned work, feasible dependencies, available capacity, and decision-ready milestones. AI can organize inputs, expose missing links, and calculate candidate schedules. It cannot decide whether an estimate is realistic or whether an owner has actually committed. Build the plan from evidence, then test the critical path with the people who must deliver it.
Turn scope into testable completion conditions
Begin with the intended outcome, what is inside and outside scope, the final acceptance conditions, and the authority that can approve a change. Break the work into deliverables before activities. Each deliverable needs a clear completion test, an owner, and a source for the estimate.
Ask AI to normalize inconsistent task descriptions and propose missing questions. Do not allow it to insert work that no source or owner supports. Maintain a planning ledger:
| Field | Question | Evidence | |---|---|---| | Deliverable | What observable result must exist? | Scope or acceptance record | | Owner | Who can commit the work? | Named acceptance | | Duration | How was the estimate formed? | Comparable work or expert estimate | | Dependency | What must be true first? | Technical or operating constraint | | Capacity | Which scarce role or system is required? | Availability record | | Risk | What could invalidate the plan? | Risk and trigger log |
The UK government Project Routemap and Project Set Up Toolkit emphasize early attention to outcomes, governance, capability, risk, and delivery arrangements in their intended contexts. They support asking these setup questions, not a claim that one planning format fits every project.
Build and challenge the dependency network
Represent dependencies explicitly as finish-to-start, start-to-start, external date, or resource constraint. Then calculate the longest connected path and available float. A calendar view built before dependency logic often hides impossible overlap.
Consider this synthetic plan for introducing a new evidence-review workflow:
| Work package | Duration | Depends on | Owner | Completion evidence | |---|---:|---|---|---| | Approve evidence standard | 5 days | None | Research lead | Signed criteria and examples | | Configure review workspace | 4 days | Evidence standard | Product lead | Tested configuration | | Prepare reviewer practice | 3 days | Evidence standard | Operations lead | Practice pack and answer key | | Run pilot | 5 days | Workspace and practice | Pilot owner | Completed records and issue log | | Decide on rollout | 2 days | Pilot | Sponsor | Decision note |
The critical path runs through standard approval, workspace configuration, pilot, and decision. Reviewer practice can proceed in parallel only if the same scarce people are not also configuring the workspace. Ask AI to calculate alternatives, but have owners confirm sequence and availability.
Replace estimates with ranges and commitments
Use three-point estimates when uncertainty is material: plausible low, working estimate, and plausible high. Record the assumptions that would produce each value. Distinguish effort from elapsed time and individual availability from nominal team size.
A failure example is a plan that assigns the research lead to standards, reviewer materials, and pilot support during the same five days. Each task looks reasonable alone, while the combined load is not. Repair the plan by resolving the constraint, changing scope, or moving the milestone. Do not simply add hidden overtime.
Convert major milestones into decisions. “Pilot complete” is an activity marker. “Sponsor reviews defect rate, reviewer feedback, and unresolved risks and chooses revise, proceed, or stop” is a decision milestone.
Verify the project plan
Walk the network forward and backward. Confirm every predecessor is necessary, every external dependency has a named contact, and every owner accepts the work and estimate. Stress-test the loss of the scarcest resource and the slippage of the longest task.
Before approval, check that:
The final artifact is the project plan plus dependency network, capacity view, estimate basis, risk log, and owner commitments. Preserve revisions so later status reporting can compare the current forecast with the approved baseline.
- scope exclusions and change authority are visible;
- each task produces a defined artifact;
- dependency types and external dates are supported;
- capacity is checked across concurrent work;
- estimate ranges expose important uncertainty;
- risks have triggers and response owners;
- milestones require evidence and a decision; and
- the schedule can be reconstructed from the planning ledger.
Sources and claim map
The project, durations, roles, and milestones are synthetic. This method does not establish that any plan will meet its time, cost, scope, or quality objectives.
- UK Government, Project Set Up Toolkit: supports explicit outcomes, governance, delivery arrangements, readiness, and risk review during setup.
- Infrastructure and Projects Authority, Project Routemap: supports early assessment of capability, governance, and delivery gaps for major projects.
Sources: [1] [2]
Sources
- 1.Project Set Up Toolkit · UK Government
- 2.Project Routemap · UK Government