Organize information

Draft an executable project plan

Turn an approved need into scoped outcomes, workstreams, ownership, gates, and controls

8 min setupTested with:ChatGPTReviewed: 2026-08-28
1

Add your context

Your text stays in this browser. AILesson Prompts does not send it to a model or server.

2

Your prompt

Unfilled fields remain visible as placeholders, so you can still copy and edit the prompt

Draft an executable project plan from the approved requirement.

Approved need, users, outcome, measures, and approval source:
[requirement]

Scope, exclusions, dates, budget, resources, compliance, and quality constraints:
[constraints]

Sponsor, decision rights, roles, dependencies, assumptions, and unknowns:
[context]

Do not turn an unapproved assumption into scope, commitment, owner, budget, or date. First state whether the inputs are sufficient to baseline the plan. Return: objective and measurable success; in/out of scope; deliverables with acceptance evidence; workstreams; milestones and decision gates; dependency map; RACI using only supplied roles and Unassigned elsewhere; resource and budget assumptions; risk register; communication and change control; quality checks; launch/closure criteria; and open decisions. Show sequencing and date logic, distinguish target dates from committed dates, and identify the smallest executable next step while gaps remain.
Private by defaultPrompt assembly happens locally in your browser. Avoid placing confidential information into any AI service unless your organization allows it.

From input to outcome

A worked example

See how concrete context turns this recipe into a usable result

Actual input

Approved need and outcome
Operations director approved replacing the shared email inbox used for facilities requests with an internal request form and tracked queue for 120 employees. Outcomes: every request has an ID and status; requesters receive confirmation; weekly reporting shows volume and age. Baseline is about 90 requests/month, measured manually. Pilot success: at least 80% of eligible requests use the form and no confirmed urgent request is lost during four weeks.
Scope and constraints
Pilot target 7 October; £4,000 software budget ceiling; use existing identity provider; English only for pilot; no vendor API integration or mobile app. Security and accessibility reviews required before pilot. Two operations coordinators are available half a day per week; IT capacity is not confirmed.
People, dependencies, and unknowns
Sponsor and final go/no-go: Operations director. Service owner: Facilities manager. Security and accessibility teams approve their reviews. Procurement handles any purchase. Vendor shortlist, IT owner, support owner, retention period, urgent-request definition, and committed dates are unresolved.

Example output

Baseline readiness: outcome and scope are approved, but the 7 October date is a target—not a commitment—until IT capacity, procurement lead time, retention, and review timing are confirmed.

Objective: pilot an authenticated form and queue for 120 employees, with unique ID/status, confirmation, and weekly volume/age reporting. In scope: English web form, queue, identity-provider sign-in, reporting, four-week pilot. Out: API integration and mobile app. Deliverables: approved workflow including urgent path; configured form/queue; security and accessibility approvals; support guide; baseline and pilot dashboard; launch and rollback checklist. Each requires signed review or named test evidence.

Sequence: Gate 1—define eligible/urgent requests, retention, and data fields; owner Facilities manager, approvals not fully specified. Gate 2—select/procure within £4,000; Procurement. Gate 3—configure and test; IT owner Unassigned. Gate 4—security/accessibility approval. Gate 5—Operations director go/no-go. Gate 6—four-week evaluation against ≥80% adoption and zero confirmed lost urgent requests.

Immediate next step: sponsor assigns IT/support owners and decision dates; Facilities drafts workflow definitions. Key risks: target-date slip from unconfirmed IT/procurement; urgent requests misclassified; manual baseline inconsistency. Change control: sponsor approves scope/budget/date baseline changes and records rationale.

Why this works

  1. 1

    A baseline-readiness check prevents a detailed-looking plan from concealing missing authority or resources.

  2. 2

    Deliverables tied to acceptance evidence make progress and completion reviewable.

Check the result

  • Can every deliverable be traced to an approved outcome or constraint?

  • Are target dates, commitments, assumptions, and unresolved decisions visibly distinct?

  • Do milestones have acceptance evidence, dependencies, and decision authority?

More ways to explore

Where this recipe fits

Text promptsProject managementChatGPT prompts

Keep the work moving

Organize information 7 min setup

Build a project risk register

Convert uncertain events into owned, evidence-based risks with triggers, responses, and review dates

A prioritized risk register with scoring rationale, response actions, contingencies, and gaps
Open recipe
Think & decide 7 min setup

Run a project pre-mortem

Imagine a failed outcome to surface plausible causes, weak signals, tests, and preventive actions

A prioritized failure scenario map with evidence, indicators, owners, and immediate experiments
Open recipe