ChatGPT, Claude & Gemini Prompts for Project Managers

Charters, Scope & Kickoff

Most project trouble starts before the plan exists, with a vague request, an unsigned scope or two people who both think they're accountable. These prompts turn a sponsor's brief into a charter, pin scope down with explicit exclusions and testable acceptance criteria, and question a vague request before you commit to anything. They also map stakeholders, settle ownership with a RACI and plan a kickoff that ends with named owners. None of them invents dates, budgets or targets; gaps come back marked in brackets.

You are a senior project manager drafting a project charter for sponsor sign-off. Work only from the material below.

Sponsor's brief or request: {{SPONSOR_BRIEF}}
Business reason and the problem it solves: {{BUSINESS_CASE}}
Known constraints (deadline, budget ceiling, people, technology, regulation): {{CONSTRAINTS}}
Delivery approach (Waterfall, Agile, hybrid or undecided): {{DELIVERY_APPROACH}}

Write the charter under these headings: Purpose; Objectives (specific and measurable, using only targets I gave; where a target is missing write [TARGET NEEDED: what to measure]); High-level scope, in and out; Key deliverables; Milestones (dates only if I supplied them); Budget (my figure or [NOT PROVIDED]); Assumptions; Constraints; Top 5 initial risks; Roles (sponsor, project manager, key stakeholders, who holds decision authority); Approval block.

Rules:
- Never invent dates, costs, headcount or targets. Mark every gap in square brackets.
- Keep it to two pages, in plain language a sponsor can read in five minutes.
- If the approach is Agile, express scope as outcomes and a product goal rather than a fixed feature list, and say how scope decisions will be made.

After the charter, list the five questions I most need the sponsor to answer before signing.

Act as a project manager who has been burned by vague scope before. Turn the notes below into a scope statement a client or sponsor can sign.

Project summary: {{PROJECT_SUMMARY}}
What the requester says they want: {{REQUESTED_FEATURES}}
What I already know is excluded or deferred: {{KNOWN_EXCLUSIONS}}
Who signs off the deliverables: {{APPROVER}}

Produce:
1. Scope description (one paragraph).
2. Deliverables table: deliverable | description | acceptance criteria (testable, yes/no) | approver.
3. Out of scope: an explicit list. Add items people commonly assume are included in this kind of project (for example training, data migration, content creation, support after go-live) and mark each "Confirm excluded?".
4. Assumptions the scope depends on, each with what happens if it proves false.
5. Ambiguity list: every word in the request that two reasonable people could read differently ("integrate", "mobile-friendly", "reports"), each with a question that pins it down.

Rules: don't add features I didn't mention to the in-scope list. Don't estimate effort or cost. Write acceptance criteria someone could check without asking me what I meant.

Act as a senior business analyst at intake. Someone has asked for a project and I don't yet know enough to plan it.

The request, exactly as I received it: {{RAW_REQUEST}}
Who is asking, and their role: {{REQUESTER}}
What I already know about context, systems or deadlines: {{KNOWN_CONTEXT}}

Don't plan the project and don't propose a solution yet. Instead:
1. Restate the request in one sentence as a problem to solve, not a solution to build.
2. List what is unknown, grouped as: outcome and success measures, users, scope boundaries, constraints (time, budget, people), dependencies, risks, and who decides.
3. Write the 10 clarifying questions that would most change the plan, ranked. For each, say in one line why it matters.
4. Flag any part of the request that sounds like a fixed solution ("we need an app") and give a neutral question that explores the underlying need.
5. Say whether this looks like a small piece of work, a project or a program, and what the answer depends on.

Keep the tone curious and respectful. These questions will go to a busy person, so make each one answerable in a sentence.

You are a program manager planning stakeholder engagement. Use only the people and facts I provide.

Project: {{PROJECT_SUMMARY}}
Stakeholders (name or role, what they care about, how they feel about the project if known): {{STAKEHOLDER_LIST}}
Decisions coming up in the next three months: {{UPCOMING_DECISIONS}}

Produce:
1. A power/interest table: stakeholder | influence (high/low) | interest (high/low) | current stance (supporter, neutral, skeptic, blocker or unknown) | desired stance | evidence for the rating (from my notes, or "assumed").
2. For each stakeholder: what they need to hear, the risk if they're ignored, the best channel, how often, and which team member owns the relationship.
3. The three stakeholders whose stance matters most to the upcoming decisions, with a specific next action for each this week.
4. Gaps: groups often forgotten on projects like this (end users, operations, legal, procurement, security, finance) that are missing from my list, framed as questions.

Rules: never state someone's motives as fact; label any inference "assumption". Keep the language neutral, because stakeholder maps get forwarded. No personality labels.

Act as a PMO lead who builds RACI charts that settle arguments instead of starting them.

Deliverables or activities: {{ACTIVITIES}}
People or roles on the project: {{ROLES}}
Known decision rights or organizational rules (who must approve what): {{DECISION_RULES}}

Build a RACI matrix with activities as rows and roles as columns, using R (does the work), A (accountable; exactly one per row), C (consulted before), I (informed after).

Rules:
- Exactly one A per row. If my inputs suggest two people are accountable, put [CONFLICT] in that row and explain it below the table.
- Don't assign anyone to work I haven't connected them to. Where a role is unclear, mark it "?" rather than guessing.
- Flag overload: any role with R on more than half of the rows, and any row with more than three Cs, because that slows decisions.
- Flag gaps: rows with no R, and roles with no letters at all.

After the table, give:
1. A list of conflicts and gaps, each with the question I should ask to resolve it.
2. A three-sentence explanation of how to read the RACI, which I can paste into the kickoff deck.

You are an experienced delivery lead preparing a project kickoff. The goal is shared understanding and named owners, not a slideshow.

Project charter or summary: {{CHARTER_SUMMARY}}
Attendees and their roles: {{ATTENDEES}}
Meeting length and format (in person, remote, hybrid): {{MEETING_FORMAT}}
The thing most likely to go wrong in this meeting (a skeptical stakeholder, unclear scope, a team that was told late): {{KICKOFF_CONCERN}}

Produce:
1. A timed agenda that fits the meeting length exactly, with an owner and an outcome for each item. Cover: why the project exists, scope in and out, how we'll work (cadence, tools, approach), roles, top risks and agreed next steps.
2. Talking points for each agenda item, as bullets rather than a script.
3. Five questions to put to the room that surface hidden disagreement early.
4. A plan for handling the concern I named, including what to say if it comes up.
5. A short pre-read email to send 48 hours ahead.

Rules: use only facts from my summary. If the timings don't fit, cut items and tell me which to move to a follow-up rather than squeezing them in.

WBS, Estimates & Schedule Control

Chat models are good at structure and arithmetic and bad at knowing how long your work takes, so these prompts split the job accordingly. The WBS prompt decomposes scope without guessing durations. The PERT, critical path, capacity and earned value prompts take your team's numbers, apply the standard formulas and show every step so you can check them. There is also a stage-gate milestone plan for Waterfall projects and a recovery prompt for when the schedule has already slipped.

You are a project scheduler building a work breakdown structure (WBS). Decompose only what I have described.

Project scope statement or deliverables list: {{SCOPE_STATEMENT}}
Delivery approach and phases, if any: {{PHASES}}
Team roles available: {{TEAM_ROLES}}

Produce:
1. A deliverable-oriented WBS to three levels, numbered 1.0, 1.1, 1.1.1. Level 1 is major deliverables or phases; level 3 is work packages. Include project management as its own branch.
2. A WBS dictionary table for each work package: ID | name | description | definition of done | suggested owner role | predecessors (IDs, only if obvious from my inputs).
3. A check against the 100% rule: anything in my scope that no work package covers, and any work package that falls outside my scope.

Rules:
- No durations, effort or costs. Estimates come later, from the people doing the work.
- Name work packages as outcomes or nouns ("Test plan approved"), not vague verbs ("Do testing").
- If a work package looks too big to estimate with confidence, mark it "SPLIT?" and suggest how.
- List any assumptions you had to make to decompose a deliverable.

Finish with three questions for the team to answer before estimating starts.

Act as a project estimator. Combine my team's estimates; never replace them with your own numbers.

Tasks with optimistic (O), most likely (M) and pessimistic (P) estimates, in the units given: {{TASK_ESTIMATES}}
Which tasks run in sequence and which in parallel: {{TASK_SEQUENCE}}
Working days per week and any known non-working days: {{CALENDAR_NOTES}}

For each task, calculate the PERT expected duration E = (O + 4M + P) / 6 and the standard deviation SD = (P − O) / 6. For the longest sequential chain, sum E and combine the SDs as the square root of the sum of the squared SDs.

Output:
1. A table: task | O | M | P | E | SD.
2. The chain total, its combined SD, and the ranges total ± 1 SD and total + 2 SD, labeled as rough planning ranges rather than probabilities to rely on.
3. The three tasks contributing the most uncertainty, with a question to ask each estimator.
4. Inconsistent estimates (O above M, P below M, or a very wide range), flagged, not corrected.

Rules: use only my numbers. If a task is missing a value, mark it and exclude it from the totals. If you can run code, use it for the calculations; either way, show each step so I can check it.

You are a scheduler checking a plan's critical path. Use only the tasks, durations and dependencies I give you.

Task list with durations and predecessors (finish-to-start unless I say otherwise): {{TASK_NETWORK}}
Project start date and working calendar: {{START_AND_CALENDAR}}
Fixed deadlines or milestone dates: {{DEADLINES}}

Do this:
1. Run a forward pass (earliest start and finish) and a backward pass (latest start and finish). Show the working as a table: task | duration | ES | EF | LS | LF | total float.
2. Identify the critical path (zero float) and its total duration. If there are several, list each.
3. Compare the finish with my deadlines and state the gap in working days, positive or negative.
4. Name near-critical tasks (float of two days or less) that could easily become critical.
5. Flag network problems: tasks with no predecessor or no successor other than the start and end, circular dependencies, and missing durations.

Rules: never add tasks or change durations. Convert working days to calendar dates only with the calendar I gave you. If you can run code, use it for the calculations; either way, show each step so I can check it.

Finish with one sentence I can tell the sponsor about where the schedule risk sits.

Act as a project manager in an organization that uses stage gates. Build a milestone plan the steering group can approve.

Project phases and their main deliverables: {{PHASE_DELIVERABLES}}
Dates already fixed (contractual, regulatory, launch events): {{FIXED_DATES}}
Our governance: who approves each gate and how often they meet: {{GOVERNANCE}}

Produce:
1. A milestone table: milestone | phase | definition of done (the evidence that proves it) | gate approver | target date (only dates I gave you; otherwise [DATE TBD]).
2. Gate criteria for each stage: four to six questions the approver should be able to answer yes to before work moves on.
3. Where the governance calendar could delay a gate (for example, a board that meets monthly), with a suggested workaround such as a pre-booked slot or delegated approval.
4. A one-paragraph summary to put at the top of the plan.

Rules: milestones are zero-duration events, not activities. Write them as completed states ("Design signed off"), not tasks ("Design work"). Don't invent dates or durations. If a gate has no clear approver in my inputs, say so. Where a phase has no deliverable that proves it is finished, flag the phase and suggest what evidence would.

You are a resource manager checking whether a plan is realistic for the people available. Use only my numbers.

Team members, roles and availability (hours per week on this project, holidays, other commitments): {{TEAM_AVAILABILITY}}
Planned work by person or role, with effort estimates and dates: {{PLANNED_WORK}}
Period to check: {{CHECK_PERIOD}}

Do this:
1. Calculate available hours per person per week for the period, after holidays and other commitments.
2. Calculate planned hours per person per week from the plan.
3. Show a table: person | week | available | planned | load (planned divided by available). Mark loads over 1.0 as OVERLOADED and under 0.5 as UNDERUSED.
4. List the overloaded weeks and give options for each: move the work, reassign it to a named person with spare capacity and the right skills, split the task, or move the date. Say what each option costs.
5. Note any single-person dependency, where only one person can do a type of work.

Rules: don't assume every hour is productive. If I haven't said how much time goes to meetings and support, say that you used my availability figures as given. If you can run code, use it for the calculations; either way, show each step so I can check it.

Act as a recovery project manager. The schedule has slipped and I need options, not optimism.

Current plan status (tasks remaining, durations, dependencies, owners): {{REMAINING_PLAN}}
The deadline at risk and how much time we need to recover: {{DEADLINE_GAP}}
What I can change (budget, extra people, overtime, scope, quality steps) and what is off-limits: {{LEVERS_AVAILABLE}}

Produce four options:
A. Fast-tracking: which sequential tasks could overlap, and the rework risk that creates.
B. Crashing: where extra people or money would shorten the critical path. Note tasks where adding people late would slow things down.
C. Scope: which deliverables could be cut, deferred to a later release or simplified, and the effect on the objectives.
D. Re-baseline: what a credible new date looks like if nothing else changes, based only on my remaining durations.

For each option give: time recovered (only from my numbers; otherwise "needs estimate"), cost, risk, and who must approve it.

End with a recommended combination and a five-line message to the sponsor presenting the choice.

Rules: never present an option that depends on people simply working faster. Don't hide quality cuts, such as less testing, inside another option; list them separately and name the risk.

You are a project controls analyst. Calculate earned value metrics from my figures and explain what they mean in plain English.

Budget at completion (BAC): {{BUDGET_AT_COMPLETION}}
Planned value to date (PV): {{PLANNED_VALUE}}
Earned value to date (EV, the budgeted cost of work actually completed) and how it was measured: {{EARNED_VALUE}}
Actual cost to date (AC): {{ACTUAL_COST}}

Calculate, and show the working for: schedule variance SV = EV − PV; cost variance CV = EV − AC; SPI = EV / PV; CPI = EV / AC; estimate at completion EAC = BAC / CPI; estimate to complete ETC = EAC − AC; variance at completion VAC = BAC − EAC; and TCPI = (BAC − EV) / (BAC − AC).

Then:
1. A four-sentence readout for a sponsor: ahead or behind, over or under budget, and what happens if current performance continues.
2. Two caveats about these numbers, based on how EV was measured. Guessed "percent complete" figures, for example, tend to inflate EV.
3. Three questions to investigate before reporting the result.

Rules: use only my numbers and currency. If a figure is missing, skip that calculation and say what's needed. If you can run code, use it for the calculations; either way, show each step so I can check it.

Risks, RAID Logs, Dependencies & Suppliers

A risk register is only useful if it's current and specific. These prompts surface risks with a pre-mortem, write register rows in cause-event-effect form on your own scoring scale, and build a RAID log from the notes you already have. They also stress-test the assumptions your plan rests on, track dependencies on other teams, review a supplier against its contract, and write an escalation note that asks for a decision, not sympathy. Scores the AI suggests are marked as proposals for the team to confirm.

Act as a facilitator running a pre-mortem. Imagine it is the day after this project's deadline and it has failed badly. Work backwards from that failure.

Project summary, objectives and deadline: {{PROJECT_SUMMARY}}
Plan highlights, team and key dependencies: {{PLAN_HIGHLIGHTS}}
Things that already worry me: {{CURRENT_WORRIES}}

Produce:
1. Twelve distinct failure stories, two sentences each, spread across: requirements and scope, people and skills, suppliers and dependencies, technology, stakeholders and politics, schedule and estimates, and adoption after go-live. Each must connect to something in my inputs and be specific to this project, not generic advice.
2. For each story, the early warning sign we would see first, and roughly when in the project.
3. The four stories that look most plausible given my inputs, each with one preventive action that is cheap to take now.
4. Questions to ask the team in a 45-minute pre-mortem session to surface failures I haven't thought of.

Rules: don't reassure me. Don't assign probabilities or scores; this step is for discovery, and scoring happens later in the risk register. Avoid vague risks like "poor communication" unless you say exactly what communication fails, and between whom.

You are a risk manager writing entries for a project risk register. Turn my rough risk notes into well-formed entries.

Rough risk notes: {{RISK_NOTES}}
Our probability and impact scale, with definitions: {{SCORING_SCALE}}
Escalation threshold or risk appetite: {{ESCALATION_THRESHOLD}}
Possible owners on the team: {{RISK_OWNERS}}

For each risk, write a register row: ID | risk statement in the form "Because of [cause], [event] may occur, which would lead to [effect on objectives]" | category | probability | impact | score (as my scale defines it) | proximity (when it could happen) | response type (avoid, mitigate, transfer or accept; exploit or enhance for opportunities) | response actions | trigger | owner | status.

Rules:
- Separate risks (uncertain future events) from issues (already happening). Move issues to a separate list.
- Score only with my scale. Where my notes don't support a rating, suggest one and mark it "PROPOSED: confirm with team".
- Assign owners only from my list; otherwise write [OWNER?].
- Put any risk above my escalation threshold at the top, flagged.
- Merge duplicates and tell me which ones you merged.

End with the three risks whose response actions should start this week.

Act as a PMO analyst cleaning up a RAID log. I'll paste notes from meetings, emails and chats. Sort every relevant item into Risks, Assumptions, Issues and Dependencies.

Pasted notes: {{RAW_NOTES}}
Project name and current phase: {{PROJECT_PHASE}}
Existing RAID log, if any, so you update it instead of duplicating: {{EXISTING_RAID}}

Output four tables:
- Risks: ID | description | owner | next review date | status
- Assumptions: ID | assumption | how and by when we'll validate it | what happens if it's wrong
- Issues: ID | description | impact now | owner | action | due date
- Dependencies: ID | what we depend on, or what depends on us | other team or supplier | needed by | status

Rules:
- Use only what's in the notes. Owners and dates come from the notes; where they're missing write [OWNER?] or [DATE?].
- Quote the source line briefly for each item so I can trace it.
- If an item could fit two categories, put it in the more likely one and note the alternative, e.g. "(could be an issue)".
- Mark items that update the existing log UPDATED, with what changed. Mark new items NEW.

End with a list of items that need a decision from me this week.

You are a project manager escalating an issue that's beyond your authority to resolve. The note must get a decision, not sympathy.

The issue and what's happened so far: {{ISSUE_DETAILS}}
Impact on scope, schedule, cost or quality (my figures only): {{ISSUE_IMPACT}}
Options I can see, including doing nothing: {{OPTIONS_CONSIDERED}}
Who I'm escalating to, and when I need an answer: {{DECISION_MAKER_AND_DEADLINE}}

Write an escalation note of no more than 300 words with:
1. A subject line that states the decision needed and the date.
2. Decision required: one sentence.
3. Background: three sentences, facts only.
4. Impact if we don't decide by the date.
5. Options table: option | cost | what it fixes | risk.
6. My recommendation and why.
7. What I've already tried within my own authority.

Rules: neutral tone, with no blame and no names of people at fault. Don't soften the impact. Don't introduce numbers I didn't give you; write [FIGURE NEEDED] instead.

After the note, list anything the recipient is likely to ask that the note doesn't yet answer, so I can add it before sending.

Act as a skeptical reviewer on a project assurance team. Find the assumptions this plan relies on and test them.

Plan summary or excerpt: {{PLAN_EXCERPT}}
Estimates, dates or budget figures the plan relies on: {{KEY_FIGURES}}
Context about the organization and past similar projects: {{ORG_CONTEXT}}

Do this:
1. List every assumption the plan makes, stated or unstated: people will be available, a supplier will deliver, users will adopt, the data is clean, approvals take a week. Mark each one stated or unstated.
2. For each, rate how much the plan depends on it (high, medium, low) and how much evidence supports it, using only my inputs: evidence given, partial, or none.
3. Pick the five riskiest (high dependence, little evidence). For each, describe what breaks if it's false and a cheap way to test it in the next two weeks.
4. Write those five as entries ready for the assumptions log: assumption | owner role | validation test | validate by.

Rules: don't recalculate or replace my figures; question them. Don't use outside benchmarks or industry statistics. If the plan is too thin to assess, list the extra information you need instead of guessing.

Act as a delivery manager on a project that depends on other teams who don't report to me. Map the dependencies and help me chase them without burning goodwill.

Dependencies as I understand them (what we need, from whom, by when, and what they need from us): {{DEPENDENCY_LIST}}
Our milestones and which work each dependency feeds: {{MILESTONE_LINKS}}
What I know about each team's priorities and current workload: {{OTHER_TEAM_CONTEXT}}

Produce:
1. A dependency table: ID | direction (we need / they need) | item | providing team and contact role | needed-by date | milestone it feeds | slack before it hurts (only if my dates show it) | status | confidence (confirmed in writing, verbal, or assumed).
2. The dependencies that threaten a milestone, ranked by how soon they bite.
3. For each at-risk one, a short chase message written from the other team's point of view: why it matters to them, the exact ask, the date, and an offer of help.
4. Dependencies that have no named contact or no agreed date, as questions to resolve this week.
5. What to escalate, to whom, and the point at which to do it.

Rules: use only my dates; write [DATE?] where none was agreed. Treat "assumed" dependencies as the riskiest. Never imply the other team is at fault.

You are a project manager preparing for a supplier review meeting. Assess the supplier against what the contract actually says, not against general impressions.

Contracted deliverables, milestones, service levels and acceptance terms (paste the relevant schedule): {{CONTRACT_TERMS}}
What the supplier has actually delivered, with dates and evidence: {{SUPPLIER_DELIVERY}}
Open issues, disputes or concerns from the team: {{SUPPLIER_ISSUES}}

Produce:
1. A performance table: obligation | contract reference | due | delivered (date and evidence) | status (met, late, partial, not met, or not yet due) | impact on the project.
2. Patterns: whether problems point to capacity, quality, communication or unclear requirements on our side. Be honest where our late inputs or changing requests contributed.
3. An agenda for the review meeting, with the outcome wanted for each item.
4. Asks of the supplier, each specific and dated, and what we commit to in return.
5. Points to refer to the contract or commercial manager, such as service credits, remedies or change notes. Don't give a legal interpretation; just flag them.

Rules: rely only on the contract text and evidence I pasted. Where evidence is missing, mark it "unverified". Keep the tone factual, because this may be shared with the supplier.

Status Reports & Stakeholder Updates

Status reporting is where projects lose credibility, usually by reporting Green until the week everything turns Red. The status prompt applies RAG rules strictly, so a slipping forecast can't hide. Other prompts write a one-page steering update, deliver news of a slipped milestone, adapt one update for three audiences, set up a communication plan, prepare you for a difficult stakeholder conversation and build a decision paper that's fair to every option.

You are a project manager writing the weekly status report. It must be honest enough that nobody is surprised later.

This week's raw updates (from the team, the tracker or my notes): {{WEEKLY_UPDATES}}
Baseline: key milestones with dates, and budget if tracked: {{BASELINE}}
Our RAG definitions (if blank, use: Green = on track for baseline; Amber = at risk but recoverable within the team's authority; Red = will miss baseline or needs a decision above the project): {{RAG_RULES}}
Audience: {{REPORT_AUDIENCE}}

Write the report:
1. Overall status (RAG) with a one-sentence reason. Then a RAG for scope, schedule, budget and resourcing, each with a reason.
2. Done this week: up to five bullets, written as outcomes, not activity.
3. Next week: up to five bullets.
4. Milestones table: milestone | baseline date | forecast date | variance | RAG.
5. Top risks and issues (up to three), each with owner and action.
6. Decisions or help needed, with a date.

Rules: apply the RAG rules strictly. If the updates show a forecast later than baseline, that line can't be Green, however optimistic the team is. If something is missing, write [UPDATE NEEDED]. No filler like "great progress". Keep it under 350 words.

Act as a program director preparing a one-page update for a steering committee that has ten minutes for this project.

Latest status report or notes: {{STATUS_DETAILS}}
Decisions or endorsements we need from the committee: {{DECISIONS_NEEDED}}
What this committee cares about most (benefits, cost, risk, reputation, regulation): {{COMMITTEE_PRIORITIES}}

Produce a one-page paper with:
1. Headline: one sentence a member could repeat accurately in a corridor.
2. Decisions requested, numbered, each with the recommended option and a deadline.
3. Status at a glance: overall RAG, then schedule, cost, scope and benefits, each with a reason of ten words or fewer.
4. What changed since the last meeting (up to four bullets).
5. Top three risks to the benefits, not just the schedule, with what the committee could do about each.
6. Appendix pointer: what detail is available on request.

Rules: lead with decisions, not activity. Leave out anything that appears in my notes only as speculation. Use only figures I gave you. Write for people who weren't in the project meetings: spell out acronyms and avoid team jargon.

Finish with three questions the committee is likely to ask, with short answers drawn from my notes.

You are a project manager who has to tell stakeholders that a milestone will be late. Write the message so it keeps their trust.

The milestone, original date and new forecast date: {{SLIPPED_MILESTONE}}
Why it slipped (the honest cause, including our own part): {{ROOT_CAUSE}}
What we're doing about it and what has changed in the plan: {{RECOVERY_ACTIONS}}
Who is receiving it and their relationship to the project: {{RECIPIENTS}}

Write:
1. An email of 150–250 words that states the new date in the first two sentences. Then give the cause in plain words, without blaming individuals or vendors by name; the impact on these recipients specifically; the recovery actions; how confident we are in the new date; and what could still move it.
2. A version under 60 words for a chat message or the top of a status report.
3. Three likely pushback questions, with suggested answers.

Rules: don't hide responsibility in the passive voice ("mistakes were made"). Don't over-apologize. Never sound more certain about a date than my recovery actions support. If my inputs don't support a firm date, call it a "target" and state the condition it depends on. Use only facts I've given.

Act as a communications-minded project manager. I have one set of facts and three audiences who each need something different.

This week's facts: {{UPDATE_FACTS}}
The audiences (for example executive sponsor, delivery team, client or end users) and what each cares about: {{AUDIENCES}}
Information some audiences must not see (commercial, HR or confidential): {{RESTRICTED_INFO}}

Write three versions:
1. Executive: up to 80 words. Outcome, status, any decision needed. No task detail.
2. Delivery team: up to 200 words. What changed, priorities for the week, blockers and who to go to, plus a thank-you that names specific work rather than generic praise.
3. Client or end users: up to 150 words. What it means for them, what they need to do, and when they'll hear next. Leave out internal problems unless they affect the client.

Rules:
- All three must agree: same dates, same status, and no version contradicting another.
- Never put restricted information in a version for an audience that shouldn't see it. After the three versions, list what you left out of each and why.
- Use only my facts. If an audience needs something I haven't provided, write [NEEDED: what].

You are a project manager setting up the communication plan at the start of a project.

Project summary and duration: {{PROJECT_SUMMARY}}
Stakeholders or groups, and what they need from the project: {{STAKEHOLDER_NEEDS}}
Tools and channels available (email, chat, intranet, meetings, dashboards): {{CHANNELS}}
Existing governance meetings this project must report into: {{GOVERNANCE_MEETINGS}}

Produce:
1. A communication matrix: communication | purpose | audience | content | channel | frequency | owner | format or template. Cover at least kickoff, status reporting, steering papers, team stand-ups or check-ins, change notices, risk escalation, release or go-live notices, and closure.
2. An escalation path: who hears about a Red issue, in what order and how fast.
3. A noise check: any audience receiving more than three regular communications a week, with a suggestion to merge or cut.
4. Two feedback mechanisms to find out whether the communications are working.

Rules: use only the stakeholders and channels I listed. If something important seems missing, add it as a question at the end. Keep owners as roles, not names, unless I gave names. Prefer existing meetings and channels over creating new ones.

Act as a coach for project managers preparing for a tough conversation with a stakeholder.

The stakeholder's role and our working relationship: {{STAKEHOLDER_ROLE}}
The situation, and what they've said or done: {{SITUATION}}
What I need from the conversation: {{MY_OUTCOME}}
What I can and can't offer: {{NEGOTIABLES}}

Prepare me:
1. Their likely interests: what they might need underneath their position, labeled as hypotheses to test, not facts.
2. An opening of two or three sentences that names the issue without blame.
3. Questions to understand their view before I make my case.
4. My key message in one sentence, and the evidence for it from my notes.
5. Three likely objections, with a response to each that holds my position without sounding defensive.
6. What I'll offer, in what order, and where my limit is.
7. How to close: the specific agreement, the next step and the follow-up note.

Rules: no manipulation tactics or pressure scripts. Write the lines the way a person would actually say them. If my outcome looks unrealistic given what I can offer, tell me that before preparing the rest.

You are a program manager writing a decision paper. The committee must choose between options and needs a fair comparison, not a sales pitch for my favorite.

The decision to be made, and the deadline: {{DECISION_QUESTION}}
Options, including doing nothing, with what I know about each (cost, time, benefits, risks): {{OPTIONS_DATA}}
Criteria the committee uses or should use, with weightings if any: {{DECISION_CRITERIA}}

Produce:
1. Purpose: the decision in one sentence.
2. Background: no more than 100 words.
3. Options table: option | description | cost | time impact | benefits | risks | dependencies. Use my figures only; where one is missing write [ESTIMATE NEEDED].
4. Assessment against each criterion, with a short reason per cell and a note where the evidence is weak.
5. Recommendation and its key reason, plus what would have to be true for a different option to be better.
6. The consequences of delaying the decision.
7. Decision wording for the minutes, ready to approve.

Rules: describe every option fairly, including the strongest case for the ones I don't prefer. Don't invent scores or weightings. If I gave weightings, apply them and show the arithmetic.

Meetings, Minutes & Action Items

Meetings are where decisions get made and then forgotten. These prompts plan agendas around outcomes and turn raw notes or transcripts into minutes with real owners and dates. They build a decision log from scattered threads, write the follow-up email and summarize async stand-ups. One audits your recurring meetings and calculates the person-hours they cost. When the notes don't name an owner or a date, the output says so instead of making one up.

Act as a facilitator who runs short, useful project meetings.

Meeting purpose and the decisions or outputs it must produce: {{MEETING_PURPOSE}}
Attendees and what each brings: {{ATTENDEES}}
Length and format: {{MEETING_LENGTH}}
Pre-reads, or open items from the last meeting: {{OPEN_ITEMS}}

Produce:
1. A one-line objective in the form "By the end we will have…".
2. An agenda table: time | item | outcome type (decide, agree, inform or input) | lead | pre-work. The timings must add up to the meeting length, with five minutes kept for actions and close.
3. For every "decide" item, the question to be decided, worded so the answer is yes/no or a choice between named options.
4. Items that don't need a meeting and could go in a written update instead.
5. An invite message: purpose, agenda summary and what to prepare.

Rules: if the purpose doesn't need a meeting at all, say so and suggest an alternative. Use only my items and don't pad the agenda. If there's more content than time, prioritize and list what moves to the next meeting. Keep "inform" items to a minimum; information can be read beforehand.

You are a project coordinator turning raw meeting notes or a transcript into clean minutes.

Raw notes or transcript: {{MEETING_NOTES}}
Meeting name, date and attendees: {{MEETING_DETAILS}}
Style (brief, standard, or formal for governance): {{MINUTES_STYLE}}

Produce:
1. Summary: three sentences on what this meeting achieved.
2. Decisions: numbered, each a complete sentence saying what was decided and by whom. Include only things that were actually decided, not things that were just discussed.
3. Action items table: # | action (starting with a verb) | owner | due date | source (a short quote or timestamp from the notes).
4. Open questions and parked items.
5. Risks or issues raised, for the RAID log.

Rules:
- Use only what's in the notes. Never invent an owner or a due date; write [OWNER?] or [DATE?] when one wasn't agreed.
- Where the notes are vague ("we should probably look at that"), list it under open questions, not as an action or decision.
- Attribute statements to people only when it matters for a decision or action.
- Leave out side chat and anything personal.

End with the three actions most likely to slip, and why.

Act as a PMO analyst building a decision log. Decisions on this project are scattered across minutes, emails and chats, and people keep reopening them.

Pasted minutes, emails and messages, with dates where available: {{DECISION_SOURCES}}
Who holds decision authority for what: {{DECISION_AUTHORITY}}

Produce a decision log table: ID | date | decision (one clear sentence) | made by | authority (did they have it, per my notes: yes, no or unclear) | rationale given | alternatives considered | source quote | status (current, superseded or disputed).

Then:
1. Decisions that conflict with each other, with dates, and which one appears to be current.
2. Things people treated as decided where no decision-maker clearly agreed. List these as "assumed decisions" that need confirming.
3. Decisions made without the right authority, based only on my authority notes.
4. A short message I can send to confirm the disputed and assumed decisions.

Rules: log only what the sources show. Don't fill in a rationale that wasn't stated; write "not recorded". Keep the exact meaning, and don't tidy a decision into something stronger than what was said.

You are a project manager sending the follow-up after a meeting. People should be able to act on it without having attended.

Meeting summary, decisions and actions (from my notes or minutes): {{MEETING_OUTCOMES}}
Recipients, including anyone who missed the meeting: {{RECIPIENTS}}
Anything sensitive that shouldn't go in writing to this group: {{SENSITIVE_POINTS}}

Write the email:
1. Subject line: meeting name, date and the single most important outcome.
2. Opening: one sentence of context.
3. Decisions, as bullets.
4. Actions: a short list with owner and due date, with each owner's name in bold so people can find their own.
5. What happens next (the next meeting or milestone).
6. A line asking for corrections by a specific date, after which the notes stand.

Rules: keep the body under 200 words, not counting the action list. Use only what's in my notes. Where an owner or date is missing, write [TBC] and add it to a short "please confirm" line. Leave out the sensitive points, and after the email tell me what you removed. Neutral, friendly tone; no passive-aggressive phrasing like "as previously mentioned".

Act as a scrum master for a distributed team that posts written stand-up updates instead of meeting every day.

Today's raw updates from team members (pasted from chat): {{STANDUP_POSTS}}
Current sprint goal and key board items: {{SPRINT_GOAL}}
Blockers or dependencies carried over from earlier days: {{KNOWN_BLOCKERS}}

Produce a digest of up to 200 words:
1. Sprint goal status: on track, at risk or off track, with one line of evidence from the updates.
2. Blockers: who is blocked, who can unblock it, and since when. Mark blockers older than one day as AGING.
3. Hand-offs and collaboration needed between people today.
4. Work in progress that doesn't connect to the sprint goal, raised as a neutral question, not an accusation.
5. People who didn't post an update, listed without comment.

Rules: summarize only what people wrote. Don't judge individual productivity or compare team members. If an update is vague ("working on stuff"), list it under "needs detail" rather than guessing. The digest should be readable in under a minute.

You are an operations-minded project manager auditing the team's recurring meetings, because the calendar has eaten the work.

Recurring meetings, with purpose, frequency, length, number of attendees and what each produces: {{MEETING_INVENTORY}}
Pain points the team has raised about meetings: {{TEAM_FEEDBACK}}
Meetings required by governance or a client contract: {{MANDATORY_MEETINGS}}

Do this:
1. Calculate person-hours per month for each meeting (length × attendees × occurrences per month) and in total. Show the working.
2. For each meeting, judge from my descriptions whether its main value is decisions, coordination, information sharing or relationship-building.
3. Recommend keep, shorten, reduce frequency, make async, merge or cancel, each with a one-line reason. Don't cut mandatory meetings; suggest how to make them shorter or sharper instead.
4. Show total person-hours per month before and after the recommendations.
5. Write a short message to the team announcing a four-week trial of the changes and how we'll review it.

Rules: use only my numbers. Keep at least one regular slot where the team talks together. If you can run code, use it for the calculations; either way, show each step so I can check it.

Sprint Planning, Backlog & Retrospectives

For Scrum and other Agile teams: user stories with Given/When/Then acceptance criteria, story splitting by vertical slices, and a Definition of Ready and Done the team can actually check. There's capacity-adjusted sprint planning from your own velocity, plus backlog ordering with MoSCoW or WSJF. You also get retros matched to how the sprint went, a prompt that turns retro notes into two real experiments, and a release forecast given as a date range. Velocity is treated as a planning aid, never a target.

Act as an experienced product owner writing user stories that a team can estimate and test.

Feature or epic description: {{FEATURE_BRIEF}}
User types, and what each is trying to do: {{USER_TYPES}}
Business rules, constraints and non-functional needs (security, performance, accessibility): {{BUSINESS_RULES}}

Produce:
1. User stories in the form "As a [user type], I want [capability], so that [benefit]", each small enough to finish in one sprint.
2. For each story, three to six acceptance criteria in Given/When/Then form, including at least one edge case or error path.
3. A short INVEST check for each story (independent, negotiable, valuable, estimable, small, testable), noting any criterion it fails.
4. Questions for stakeholders wherever the brief is ambiguous.
5. Non-functional requirements written as constraints that apply across stories, not as separate stories.

Rules: don't add capabilities my brief doesn't imply; put extra ideas under "possible later stories". Don't estimate story points; the team does that. Use the user types I gave, never a generic "user". Keep each story's benefit about the user's goal, not the system's.

You are an agile coach helping a team split stories that are too big to finish in a sprint.

The oversized stories, with their acceptance criteria: {{LARGE_STORIES}}
Team context (sprint length, rough capacity, tech stack): {{TEAM_CONTEXT}}
What the team said makes these stories big or uncertain: {{SIZE_CONCERNS}}

For each story:
1. Name why it's big: several workflows, many business rules, data variations, interface variations, complexity, performance work, or unknowns that need a spike.
2. Propose a split into vertical slices, each delivering something a user could see and test. Don't split into horizontal layers like "front end" and "back end". Use whichever pattern fits: workflow steps, business-rule variations, happy path first, data types, create/read/update/delete operations, or deferring performance.
3. Write each new story with two to four acceptance criteria.
4. Pick the slice to build first, because it delivers value or reduces risk fastest.
5. If there's a big unknown, propose a time-boxed spike with the question it must answer.

Rules: every slice must be valuable and testable on its own. Don't estimate points. Don't drop any of the original acceptance criteria; show where each one went.

Act as an agile coach helping a team agree a Definition of Ready (DoR) and a Definition of Done (DoD) that match how they actually work.

Team type and what it delivers: {{TEAM_DELIVERABLES}}
Current problems (stories arriving unclear, work "done" but not deployed, bugs found late): {{CURRENT_PROBLEMS}}
Organizational standards that must be included (security review, accessibility, documentation, release approval): {{ORG_STANDARDS}}

Produce:
1. A draft DoR: five to eight checkable statements a backlog item must meet before the team pulls it into a sprint.
2. A draft DoD: six to ten checkable statements, grouped into work quality, testing, documentation and release, including my organizational standards.
3. For each problem I listed, the statement that addresses it.
4. Statements the team probably can't meet yet, marked "aspirational", with a suggestion for phasing them in.
5. A 20-minute agenda for the team to review, edit and agree the drafts together.

Rules: every statement must be verifiable as yes or no, so avoid words like "good", "adequate" or "properly". Keep the DoR light, so it doesn't become a gate that stalls work. Don't add standards I didn't mention to the mandatory list; suggest them separately.

Act as a scrum master preparing for sprint planning. Use only the numbers I give you.

Completed points or items in each of the last three to six sprints: {{VELOCITY_HISTORY}}
Team availability this sprint (days off, part-time, new joiners) and sprint length: {{SPRINT_CAPACITY}}
Ordered backlog items, with estimates and dependencies: {{READY_BACKLOG}}
The product owner's proposed sprint goal: {{PROPOSED_GOAL}}

Do this:
1. Calculate the average and range of past velocity. Adjust for this sprint's availability by the ratio of available person-days to a normal sprint's person-days.
2. Propose a forecast range (low to high), not a single commitment.
3. Select backlog items in order up to the low end of the range, then list stretch items up to the high end. Respect dependencies.
4. Check whether the selected items actually achieve the sprint goal. If not, suggest a sharper goal or a different selection.
5. Flag items that aren't ready: no acceptance criteria, no estimate, or blocked.

Rules: velocity is a planning aid for this team only. Don't compare it with other teams or treat it as a target. If you can run code, use it for the calculations; either way, show each step so I can check it.

You are a product manager helping me prioritize a backlog transparently, so the order can be defended to stakeholders.

Backlog items, each with a short description: {{BACKLOG_ITEMS}}
Method to use (MoSCoW, WSJF or both): {{PRIORITIZATION_METHOD}}
Scores from the team and stakeholders (for WSJF: business value, time criticality, risk reduction and job size): {{TEAM_SCORES}}
Fixed constraints (deadlines, regulatory items, dependencies, capacity): {{FIXED_CONSTRAINTS}}

For MoSCoW: sort items into Must, Should, Could and Won't (this time), with a one-line reason each. Flag it if the Musts look like more than the team can deliver, using any capacity I gave.
For WSJF: calculate cost of delay = business value + time criticality + risk reduction, then WSJF = cost of delay ÷ job size. Rank the items and show a table with the arithmetic.

Then:
1. Items whose position looks wrong given the constraints (a regulatory item ranked low, say), and why.
2. Items whose scores seem inconsistent with their description, raised as questions.
3. A short note explaining the order to stakeholders.

Rules: never invent scores; list unscored items as "unscored". If you can run code, use it for the calculations; either way, show each step so I can check it.

Act as an agile coach designing the next retrospective. Pick a format that fits this team now instead of reusing the same three columns.

How the last sprint went (outcomes, incidents, mood): {{SPRINT_SUMMARY}}
Team size, remote or in person, and time available: {{RETRO_SETUP}}
Actions from the last retro, and whether they happened: {{PREVIOUS_ACTIONS}}
Anything sensitive I should know about (conflict, someone leaving, a failed release): {{SENSITIVITIES}}

Produce:
1. A recommended format (for example Start/Stop/Continue, 4Ls, Sailboat, Timeline, Mad/Sad/Glad, or a retro focused on one theme) and why it fits.
2. A timed plan through the five stages: set the stage, gather data, generate insights, decide what to do, close. It must fit my time exactly.
3. The opening check-in question and the exact prompts to put on the board.
4. How to review last retro's actions without it turning into blame.
5. Facilitation tips for the sensitivity I mentioned, including what to do if the conversation turns personal.
6. How the team will choose no more than two actions, each with an owner.

Rules: keep it safe to speak. No exercises that single out individuals.

You are a scrum master turning raw retrospective notes into a few actions the team will actually do.

Raw retro notes or sticky-note text: {{RETRO_NOTES}}
Votes or dot counts, if any: {{VOTE_COUNTS}}
Recurring themes from previous retros: {{PAST_THEMES}}

Produce:
1. Themes: group the notes into three to six themes, each with a neutral name, the notes that belong to it, and the vote total if given.
2. Repeat offenders: themes that also appeared in past retros, flagged RECURRING, with a question about why earlier actions didn't fix them.
3. Up to two experiments for the next sprint, each written as: "We believe [change] will result in [outcome]. We'll know it worked when [observable signal] by [date]." Include an owner role and the first step.
4. Problems outside the team's control, written as an escalation note for me to raise.
5. A three-line summary for the team channel.

Rules: use only the notes. Keep individuals' names out of the themes and the summary. Don't turn every note into an action; two experiments that happen beat ten that don't. If there are no votes, don't invent a ranking; say the team should vote.

Act as a delivery lead forecasting when a release could ship. The forecast must be an honest range built from the team's own data.

Remaining backlog for the release, in points or item counts: {{REMAINING_SCOPE}}
Completed points or items per sprint for the last several sprints: {{THROUGHPUT_HISTORY}}
Sprint length, next sprint start date and known holidays: {{SPRINT_CALENDAR}}
Scope typically added per sprint, if known: {{SCOPE_GROWTH}}

Do this:
1. From my history, take the lowest, median and highest sprint totals.
2. Calculate the number of sprints to finish at each rate, rounding up, and the matching end dates. If I gave scope growth, subtract it from each rate first and say so.
3. Present the forecast as "between [date] and [date], most likely around [date]", with the assumptions listed.
4. Describe what would move the forecast earlier or later, and what should trigger a re-forecast.
5. Write a short message to stakeholders explaining the range and why we don't give a single date.

Rules: use only my numbers, with no industry benchmarks. If a rate after scope growth is zero or negative, say the release won't converge at that rate and what must change. If you can run code, use it for the calculations; either way, show each step so I can check it.

Change Requests & Scope Creep

Scope rarely explodes. It creeps, one small request at a time. These prompts assess a change request's impact from your team's estimates and audit recent requests against the baseline to find unapproved work. They also write the reply that says no, or not yet, without damaging the relationship. For governance, there's a change board summary that totals the cumulative hit on contingency, and a re-baseline proposal for when the plan no longer reflects reality.

You are a project manager assessing a change request before it goes to the change control board. Assess the impact; don't approve or reject it.

The change request as submitted (what, why, who asked): {{CHANGE_REQUEST}}
Current baseline: the relevant scope, milestones, budget, contingency and resources: {{CURRENT_BASELINE}}
Effort or cost estimates from the people who would do the work: {{TEAM_ESTIMATES}}

Produce:
1. Summary: the change in one sentence and the reason given for it.
2. Impact table covering scope, schedule, cost, resources, quality, risk and benefits. For schedule and cost, use only my team's estimates and show how you get from them to the impact. Where there's no estimate, write [ESTIMATE NEEDED FROM: role].
3. Knock-on effects on other deliverables, dependencies, contracts or teams.
4. Options: implement now, implement later (a future phase or release), implement a reduced version, or decline, each with its trade-off.
5. Questions the board is likely to ask, with answers from my inputs.
6. A draft change log entry: ID, date, requester, description, impact summary, status "Pending decision".

Rules: never invent effort, cost or durations. Say whether the change affects the critical path only if my baseline shows it. If you can run code, use it for the calculations; either way, show each step so I can check it.

Act as a project manager checking whether scope has been creeping without anyone noticing.

Approved scope statement or requirements baseline: {{SCOPE_BASELINE}}
Requests, tickets, emails and "small asks" from the last few weeks: {{RECENT_REQUESTS}}
Change requests approved so far: {{APPROVED_CHANGES}}

Do this:
1. Compare each request with the baseline and the approved changes. Classify it as in scope, a clarification of existing scope, out of scope (new work), or gold-plating (extras the team added that nobody asked for).
2. Show a table: request | who asked | date | classification | baseline reference or "none" | status (done, in progress or not started).
3. Highlight out-of-scope work already done or in progress without an approved change, because that is the real exposure.
4. Group the out-of-scope items into themes that reveal a pattern, such as one stakeholder or one area of the product.
5. Recommend how to handle each: raise a change request, bundle it into the next phase, decline politely, or accept it as a clarification.

Rules: base every classification on the baseline text and quote the line you relied on. If the baseline is too vague to judge, say "baseline unclear" and suggest tighter wording. Don't estimate effort; mark the items that need sizing.

You are a project manager replying to a stakeholder who has asked for something outside the agreed scope. The aim is to protect the project and the relationship.

The request, and who made it: {{OUT_OF_SCOPE_REQUEST}}
Why it's out of scope (the baseline reference) and what it would affect: {{SCOPE_REFERENCE}}
Options I can offer (a change request, a later phase, a swap for something of similar size, a smaller version): {{OFFERABLE_OPTIONS}}
My relationship with this person, and their seniority: {{RELATIONSHIP}}

Write:
1. A reply of 120–200 words. Acknowledge the value of the idea, say clearly that it isn't in the current scope, explain the impact of adding it in concrete terms from my inputs, offer the options, and ask them to choose by a date.
2. A spoken version for a call, in five or six sentences.
3. A calm response for if they push back by pointing to their seniority, which routes the decision to the right authority, such as the sponsor or the change board.

Rules: no contract jargon unless I say this person uses it. Don't promise anything outside my options. Don't apologize for having a scope. Keep it warm and direct.

Act as the change manager preparing the summary for this week's change control board.

Change requests awaiting a decision, with their impact assessments: {{PENDING_CHANGES}}
Remaining contingency (budget and schedule), and who controls it: {{CONTINGENCY}}
Board members and their decision limits: {{BOARD_AUTHORITY}}

Produce:
1. A summary table: CR ID | title | requester | impact on cost, schedule and scope | recommendation (approve, approve with conditions, defer, reject, or more information needed) | reason.
2. Cumulative impact: what happens to contingency and the baseline if every recommended approval goes through, with the arithmetic shown. Flag it if contingency would go negative.
3. Changes that exceed the board's authority and must go to the sponsor or steering group.
4. Dependencies between change requests, where approving one forces or rules out another.
5. Decision wording for each request, ready for the minutes.

Rules: use only the figures in my inputs. If an impact assessment is incomplete, recommend "more information needed" and say exactly what's missing. Don't recommend approval just because a change is small; check the cumulative effect. If you can run code, use it for the calculations; either way, show each step so I can check it.

You are a project manager proposing a formal re-baseline, because the current plan no longer reflects reality.

Original baseline (scope, key dates, budget): {{ORIGINAL_BASELINE}}
What has changed and why (approved changes, external events, revised estimates): {{CHANGE_HISTORY}}
Proposed new scope, dates and budget from the team's re-planning: {{PROPOSED_BASELINE}}

Write a re-baseline proposal of no more than 600 words with:
1. Why we need to re-baseline rather than keep reporting variance, in plain language.
2. A comparison table: item | original baseline | proposed | difference | cause.
3. What we learned about our estimates or assumptions that should change how we plan from here.
4. Confidence in the new baseline, and the main risks to it.
5. The effect on benefits and the business case: does it still stand? If my inputs don't show this, name the figure that needs checking.
6. The decision requested, and from whom.

Rules: use only my figures, and show how each difference is calculated. Don't present a delay as a scope change, or a scope change as a delay. If the proposed baseline doesn't look supported by the change history, point that out rather than smoothing it over.

Lessons Learned, Closure & Handover

Closing well is what makes the next project easier. These prompts plan a blameless lessons-learned workshop and turn its output into a register of 'When X, do Y' rules tied to a template or process change. They also write a closure report that says 'not measured' when something wasn't, and hand over to operations with a checklist, acceptance criteria and hypercare exit criteria.

Act as an independent facilitator planning a lessons-learned session at the end of a project or phase.

Project summary, and the outcome compared with the original objectives: {{PROJECT_OUTCOME}}
Key events and turning points, good and bad: {{KEY_EVENTS}}
Attendees and time available: {{WORKSHOP_SETUP}}

Produce:
1. A timed agenda that fits my time, built around a timeline exercise: participants place events on a timeline, then discuss what helped and what hindered.
2. Ground rules that keep it blameless: focus on systems, decisions and the information available at the time, not on individuals.
3. Questions for each area (planning, estimating, requirements, stakeholders, suppliers, team, governance and handover) that draw out specific examples rather than opinions.
4. A five-question pre-survey so quieter people can contribute in advance.
5. A plan for turning insights into lessons someone will use: who receives each lesson and where it is stored.

Rules: use only the events I gave you to prime the timeline; don't invent incidents. Avoid questions that start with "who" when asking about problems. Make sure what went well gets as much time as what went wrong.

You are a PMO lead turning raw lessons-learned notes into a register that future projects will use. Most lessons logs are never read, so make every entry actionable.

Raw notes from the lessons session, retros and surveys: {{LESSONS_NOTES}}
Project type and organizational context: {{PROJECT_CONTEXT}}
Where lessons are stored and who reviews them: {{LESSONS_PROCESS}}

For each lesson, write an entry: ID | category (planning, estimating, scope, stakeholders, suppliers, team, governance, technical, handover) | what happened (fact) | effect on the project | root cause | lesson, written as a rule others can follow ("When X, do Y") | recommended change to a template, checklist or process | owner of that change | which future projects it applies to.

Then:
1. Mark the top five lessons by likely value to future projects, with a reason for each.
2. Separate "did well, repeat" from "change next time". Both matter.
3. List notes that are complaints without a lesson, and either turn each one into a lesson or drop it, saying which.
4. Draft a 100-word summary for the PMO newsletter or portfolio review.

Rules: use only the notes. Keep individuals' names out. Don't turn one incident into a universal rule; mark single-instance lessons "single case".

Act as a project manager writing the closure report for the sponsor and the PMO.

Original objectives, scope and baseline: {{ORIGINAL_PLAN}}
Final results: what was delivered, with dates, cost and quality: {{FINAL_RESULTS}}
Benefits measured so far, and those still to be measured: {{BENEFITS_STATUS}}
Items still open at closure (defects, actions, risks, contracts): {{OPEN_ITEMS}}

Write the report with these sections:
1. Executive summary of no more than 120 words.
2. Objectives against results: objective | target | actual | met, partly met or not met | comment.
3. Scope delivered, deferred and descoped, with the reason for each change.
4. Schedule and cost: baseline against actual, with variances calculated and shown.
5. Benefits: realized so far, expected later, and who owns measuring them and when.
6. Handover status and open items, each with an owner.
7. Top lessons (up to five), each pointing to the lessons register.
8. Formal closure request: what the sponsor is asked to sign off.

Rules: use only my figures and don't round them in our favor. If a result wasn't measured, say "not measured", never "achieved". If a benefit target wasn't met, say so plainly in the summary.

You are a service transition lead making sure the project hands over cleanly to the team that will run what we built.

What the project delivered (system, process, product or service): {{DELIVERABLE}}
The receiving operations or business-as-usual team, and their current capacity: {{RECEIVING_TEAM}}
Support arrangements agreed so far (warranty period, hypercare, supplier support): {{SUPPORT_AGREEMENTS}}

Produce:
1. A handover checklist grouped as: documentation, knowledge transfer and training, access and accounts, support model and escalation, monitoring and service levels, open defects and known issues, contracts and licenses, budget transfer, and benefits tracking. Each item has: item | evidence needed to tick it off | project owner | receiving owner | status [OPEN].
2. Acceptance criteria the receiving team signs: what must be true for them to accept the handover.
3. A hypercare plan: duration (from my inputs, or [DURATION TBD]), who's on call, and exit criteria.
4. The top five handover risks for this kind of deliverable, with a check for each.

Rules: don't assume the receiving team has capacity or skills I haven't mentioned; list gaps as questions. Don't mark anything complete. Keep items specific to my deliverable rather than a generic IT list, unless the deliverable is an IT system.

Frequently asked questions