30 ChatGPT Prompts for Project Managers (Status Updates, Risk Logs & More)
Project managers spend enormous amounts of time producing documentation no one asked them to love — status reports, risk registers, meeting agendas, and post-mortems. These 30 copy-paste ChatGPT prompts handle the recurring writing so you can focus on what actually moves projects forward.
The best project managers aren't the ones who write the cleanest status reports — they're the ones who anticipate problems early, align teams before conflict erupts, and make decisions when information is incomplete. Yet the modern PM role is buried under documentation: weekly reports, risk logs, meeting notes, escalation emails, retro summaries, change requests, and closure reports. Hours disappear into templates every week.
The writing isn't optional — stakeholders need updates, teams need direction, and organizations need records. But producing it from scratch every time is a tax on your actual judgment work. ChatGPT can draft a weekly status report from bullet points in 30 seconds. It can build a risk register from your project context, turn meeting notes into assigned action items, and write a delay notification that's transparent without being alarming.
These 30 prompts are organized around how project managers actually work — from kickoff through retrospective. Every prompt uses [BRACKETS] for the variables you fill in. Copy it, customize the brackets, paste it into ChatGPT. First draft in seconds; you spend your time on the judgment calls.
Section 1: Project Kickoff & Scoping (Prompts 1–6)
The kickoff phase generates more documentation per hour than any other — charters, scope statements, RACI matrices, assumptions logs. Get the foundations right and everything downstream is easier. These prompts handle the written deliverables so your kickoff conversations can focus on alignment, not word count.
1. Write a Project Charter from a Brief
Transform a rough project brief into a complete, stakeholder-ready project charter in minutes.
You are a senior project manager. I have the following project brief: [PASTE YOUR BRIEF HERE]. Transform this into a formal project charter with the following sections: (1) Project Overview — what this project is and why it exists (3–4 sentences), (2) Objectives — 3–5 specific, measurable goals, (3) Scope — what is in scope and explicitly what is out of scope, (4) Key Stakeholders — list with names/roles and their interest in the project, (5) High-Level Timeline — major phases with estimated durations, (6) Budget Summary — overall budget and any major cost categories if known, (7) Risks and Assumptions — 3–5 initial risks and key assumptions the project is built on, (8) Success Criteria — how we'll know the project succeeded. Format as a clean document. Keep each section tight and action-oriented — this is a working document, not a formality.2. Create a Project Scope Statement
Define the project boundaries clearly so scope creep has nowhere to hide.
Write a project scope statement for [PROJECT NAME]. The project goal: [WHAT WE'RE BUILDING OR DELIVERING]. Key deliverables: [LIST THE MAIN OUTPUTS — e.g. "redesigned checkout flow, updated API documentation, QA test results"]. Primary stakeholders: [WHO OWNS THIS PROJECT AND WHO IS AFFECTED]. Known constraints: [TIME, BUDGET, RESOURCES — e.g. "must launch by Q3, team of 4 engineers, $50K budget"]. Write a scope statement that includes: (1) In-Scope Items — a clear list of what this project will deliver, (2) Out-of-Scope Items — an explicit list of what is NOT included (at least 5–7 items — this is the most important section for preventing scope creep), (3) Deliverables — tangible outputs with brief descriptions, (4) Acceptance Criteria — how each deliverable will be evaluated and approved, (5) Assumptions — what we're taking as given that could affect scope if wrong. Format as a reference document the team can use to push back on out-of-scope requests.3. Write a Kickoff Meeting Agenda
Build a structured kickoff agenda that covers the essentials without letting the meeting run long.
Write a project kickoff meeting agenda for [PROJECT NAME]. Meeting duration: [E.G. 60 minutes / 90 minutes]. Attendees: [LIST ROLES — e.g. project sponsor, PM, development lead, design lead, marketing stakeholder]. Project type: [E.G. software launch, process improvement, marketing campaign, infrastructure upgrade]. Key things I need to accomplish in this meeting: [LIST — e.g. align on goals, confirm roles, surface risks early, get buy-in on timeline]. Create a timed agenda that includes: (1) Welcome and introductions (if needed), (2) Project overview and why it matters, (3) Scope and objectives review, (4) Roles and responsibilities — who owns what, (5) Timeline and key milestones, (6) Communication cadence — how we'll stay in sync, (7) Open risks and assumptions, (8) Q&A and next steps. For each agenda item: include the time allocation, the facilitator, and a brief note on the desired outcome. Flag which sections are discussion vs. information-sharing.Section 1 (continued): Project Kickoff & Scoping
4. Build a RACI Matrix from a Project Description
Generate a draft RACI matrix that clarifies ownership before confusion sets in.
Create a RACI matrix for [PROJECT NAME]. Project description: [BRIEF DESCRIPTION OF WHAT THE PROJECT INVOLVES]. Team members and roles: [LIST EVERYONE — e.g. Project Manager, Product Owner, Lead Developer, QA Lead, Marketing Manager, Executive Sponsor]. Key activities/decisions this project involves: [LIST 10–15 ACTIVITIES — e.g. requirements gathering, design approval, development sprints, UAT, launch sign-off, post-launch review]. Build a RACI matrix table where: R = Responsible (does the work), A = Accountable (final decision authority — only one person per row), C = Consulted (input needed before decision), I = Informed (kept in the loop). After the table, note: (1) any activities where accountability is unclear or shared (a problem), (2) any team members who are overloaded (R or A on too many items), (3) any gaps where no one is responsible. Flag these for discussion at kickoff.5. Write a Requirements Gathering Email
Send a structured requirements request that gets the specific inputs you need — not vague aspirations.
Write a requirements gathering email to [STAKEHOLDER ROLE — e.g. the business owner, the product director, the client]. The project: [BRIEF PROJECT DESCRIPTION]. What I need from them: [LIST THE KEY DECISIONS OR INPUTS — e.g. "priority ranking of features," "approval of proposed timeline," "confirmation of budget," "list of must-have integrations"]. Deadline I need responses by: [DATE]. Write an email that: opens with brief context on where we are in the project and why their input is needed now, asks each question or requests each input clearly and separately (numbered list), sets a specific deadline for their response, explains what happens if we don't have this information (e.g. "we'll need to make an assumption and proceed"), and offers 15 minutes to discuss if the questions need context. Under 300 words. Tone: professional and direct — this is a working request, not a courtesy check-in.6. Create a Project Assumptions Log
Document the assumptions baked into your project plan before they become expensive surprises later.
Create a project assumptions log for [PROJECT NAME]. Project context: [BRIEF DESCRIPTION — the type of project, its goals, key constraints]. Key areas where we're working with assumptions: [LIST AREAS — e.g. budget, resources, technical dependencies, third-party availability, regulatory approval, market conditions]. For each assumption area, generate 3–5 specific assumptions and format them as a log table with: (1) Assumption ID, (2) Assumption Statement — the specific assumption being made, (3) Category — e.g. resource, technical, business, timeline, (4) Confidence Level — High / Medium / Low, (5) Impact if Wrong — what happens to the project if this assumption proves incorrect, (6) Owner — who is responsible for monitoring this assumption, (7) Validation Method — how and when we'll confirm or challenge this assumption. Flag the 3–5 highest-risk assumptions (low confidence + high impact) for immediate stakeholder discussion.Section 2: Status Updates & Stakeholder Reports (Prompts 7–12)
Status reporting is the PM's most repeated writing task. These prompts turn your bullet-point notes into polished weekly reports, executive summaries, milestone announcements, and delay notifications — formatted for the audience that receives them.
7. Write a Weekly Status Report
Produce a professional weekly status report from rough notes in seconds — no more blank-page paralysis on Friday afternoons.
You are a project manager. Write a weekly project status report based on the following notes: Project: [PROJECT NAME]. Reporting period: [DATE RANGE]. Overall status: [RED / AMBER / GREEN]. What we accomplished this week: [BULLET POINT NOTES]. What's planned for next week: [BULLET POINT NOTES]. Current blockers or risks: [DESCRIBE ANY ISSUES]. Key decisions needed: [LIST ANY OUTSTANDING DECISIONS]. Budget status: [ON TRACK / OVER / UNDER — brief note]. Format the report as: (1) Executive Summary (3 sentences — the most important thing a senior stakeholder needs to know), (2) Accomplishments This Week (bulleted list), (3) Planned for Next Week (bulleted list), (4) Risks & Issues (table: Issue | Impact | Owner | Mitigation), (5) Decisions Needed (with deadline and decision owner), (6) Budget Snapshot (one line). Make it scannable — a busy executive should understand project health in under 60 seconds.8. Write an Executive Status Update Email
Send a crisp executive update that gives leadership exactly what they need — no fluff, no buried leads.
Write an executive status update email for [PROJECT NAME] to be sent to [AUDIENCE — e.g. the C-suite, the project steering committee, the board]. The project is: [BRIEF DESCRIPTION]. Current status: [GREEN / AMBER / RED]. This reporting period, the key facts are: [BULLET YOUR NOTES — accomplishments, issues, decisions, timeline position, budget]. Key risk or issue that executives need to know: [DESCRIBE THE MAIN CONCERN IF ANY]. What I need from them (if anything): [DECISION OR ACTION NEEDED — or "no action required"]. Write a concise executive email that: leads with status color and one headline sentence, covers the essentials in 4–6 bullet points, surfaces any decision needed with a clear recommendation, and stays under 200 words. No project management jargon. Write for an audience who has 90 seconds and wants to know: are we on track, is there a problem, do they need to do anything.9. Turn Raw Meeting Notes into Action Items
Convert a wall of meeting notes into a clean, assigned action item list ready to send to the team.
You are a project manager. I have the following raw notes from a project meeting: [PASTE YOUR MEETING NOTES]. Transform these notes into: (1) Meeting Summary (3–5 bullet points — key discussion points and decisions made), (2) Action Items Table — columns: Action | Owner | Due Date | Priority (High/Medium/Low) | Dependencies, (3) Decisions Made — a numbered list of formal decisions that came out of this meeting, (4) Open Items / Parking Lot — things that were raised but not resolved, needing follow-up. For the action items: extract every concrete task mentioned, assign an owner (use [TBD] if the notes don't specify), and set a realistic due date based on any deadlines mentioned (use [DATE TBD] if none mentioned). Flag any action items where the owner or deadline is unclear — those are risks. Format ready to paste into an email or project tool.10. Write a Milestone Completion Announcement
Celebrate a key milestone with a stakeholder announcement that reinforces momentum and team contribution.
Write a milestone completion announcement for [PROJECT NAME]. The milestone reached: [DESCRIBE WHAT WAS ACHIEVED — e.g. "Phase 1 development complete," "UAT sign-off received," "product launched to beta users"]. Date completed: [DATE — and whether it was on schedule / ahead / behind]. What this milestone means for the project: [THE SIGNIFICANCE — what does this unlock or enable]. Key contributors to acknowledge: [LIST NAMES AND ROLES — or "the full project team"]. What comes next: [THE NEXT MAJOR MILESTONE OR PHASE]. Audience: [WHO THIS IS GOING TO — team, stakeholders, or both]. Write an announcement that: opens with the achievement clearly stated, explains why it matters in non-technical terms, acknowledges the team's contribution genuinely (not generically), sets clear expectations for what happens next, and ends with a forward-looking statement. Under 250 words. Tone: energizing and credible — not corporate cheerleading, but genuine recognition of real progress.11. Write a Project Status Dashboard Summary
Draft the written narrative that accompanies a project dashboard so numbers tell the full story.
Write a project status dashboard narrative for [PROJECT NAME]. Reporting date: [DATE]. Dashboard data I'll be summarizing: Schedule: [ON TRACK / X DAYS BEHIND / X DAYS AHEAD]. Budget: [% SPENT vs. % COMPLETE]. Scope: [ANY CHANGES FROM ORIGINAL]. Quality: [DEFECT RATE, TESTING STATUS, OR OTHER RELEVANT METRIC]. Team: [CAPACITY ISSUES, RISKS, OR NOTES]. Top 3 highlights this period: [BRIEF NOTES]. Top 3 concerns this period: [BRIEF NOTES]. Write a 200–300 word narrative that: frames the overall project health honestly in the first paragraph, walks through each dashboard category with brief contextual commentary, highlights the most important positive development and the most important concern, and ends with a clear statement of what the team is focused on in the coming period. This narrative will appear alongside charts — it should add interpretation, not just restate the numbers.12. Write a Delay Notification to Stakeholders
Communicate a project delay professionally — transparent about the cause, clear about the path forward.
Write a project delay notification email for [PROJECT NAME]. The delay: [WHAT IS BEING DELAYED — a specific milestone, the overall launch, a deliverable]. Original date: [DATE]. New projected date: [DATE]. Root cause of the delay: [HONEST EXPLANATION — e.g. "a critical third-party integration took longer than estimated," "we identified a significant quality issue during UAT that required rework," "resource availability shifted due to [reason]"]. Impact on the overall project: [DOWNSTREAM EFFECTS — what else does this affect]. What we're doing to mitigate further delays: [CORRECTIVE ACTIONS ALREADY TAKEN OR PLANNED]. What we need from stakeholders (if anything): [DECISION, APPROVAL, RESOURCE — or "no action required"]. Write an email that: states the delay clearly in the first sentence (no burying the lead), explains the root cause without making excuses, outlines the revised timeline with confidence, describes mitigation actions already underway, and ends with a clear offer to discuss. Under 300 words. Tone: transparent and solution-focused — stakeholders should leave this email informed, not blindsided.Section 3: Risk Assessment & Issue Logs (Prompts 13–18)
Risk management is proactive by definition, but the documentation often lags. These prompts help you build risk registers, write escalation emails, assess change requests, and document post-incident learnings — without the blank-page delay that makes risk work feel like admin work.
13. Build a Risk Register from Project Notes
Turn a loose list of project concerns into a structured risk register ready for stakeholder review.
You are a project manager. Build a risk register for [PROJECT NAME] based on the following project context and concerns: Project type: [E.G. software development, process change, product launch, infrastructure migration]. Project timeline: [DURATION AND KEY DATES]. Key concerns I already know about: [LIST ANY RISKS YOU'VE IDENTIFIED]. Areas of uncertainty: [ANY AREAS WHERE YOU LACK VISIBILITY — e.g. third-party dependencies, regulatory approval, resource availability]. Create a risk register table with: (1) Risk ID, (2) Risk Description — specific and outcome-oriented (not vague), (3) Category — Technical / Resource / External / Schedule / Budget / Quality, (4) Probability — High / Medium / Low, (5) Impact — High / Medium / Low, (6) Risk Score — P x I (H-H=9, H-M=6, M-M=4, H-L=3, M-L=2, L-L=1), (7) Risk Owner, (8) Mitigation Strategy — what we'll do to reduce probability or impact, (9) Contingency Plan — what we'll do if the risk materializes. Generate at least 10 risks. Sort by risk score descending. Flag the top 3 as priority items for immediate attention.14. Write an Issue Escalation Email
Escalate a project issue to senior leadership in a way that's clear, professional, and solution-oriented.
Write an issue escalation email for [PROJECT NAME] to [RECIPIENT ROLE — e.g. the project sponsor, the VP of Engineering, the steering committee]. The issue: [DESCRIBE THE PROBLEM CLEARLY — what is happening, when it started, what impact it's having]. Attempts to resolve at the team level: [WHAT HAS ALREADY BEEN TRIED AND WHY IT DIDN'T WORK]. Why this needs escalation: [WHAT ONLY THIS PERSON CAN AUTHORIZE OR UNBLOCK]. Specific ask: [WHAT DECISION OR ACTION YOU NEED FROM THEM]. Deadline for a decision: [DATE — if we don't hear by X, what happens?]. Write an escalation email that: states the issue and impact in the first two sentences, provides enough background to be understood without requiring pre-existing knowledge, explains concisely why it can't be resolved at the current level, makes a specific, actionable ask (not "please advise"), and proposes a brief call if needed. Under 250 words. Tone: urgent but professional — this is a request for help, not a complaint or accusation.15. Write a Risk Mitigation Plan
Document a structured response plan for a specific project risk that shows you've thought through the scenarios.
Write a risk mitigation plan for the following project risk: Risk description: [DESCRIBE THE RISK IN SPECIFIC TERMS — e.g. "key backend engineer may leave during critical development phase," "the regulatory approval we're dependent on may be delayed by 4–8 weeks," "scope expansion requests from the client could push timeline by 30%"]. Project: [PROJECT NAME]. Current risk level: [HIGH / MEDIUM / LOW]. Write a mitigation plan that includes: (1) Risk Summary — what the risk is and why it matters to this project, (2) Probability Assessment — why you've assessed it at this level, with supporting evidence, (3) Impact Assessment — what happens to schedule, budget, scope, and quality if it materializes, (4) Prevention Actions — 3–5 specific things we can do now to reduce the probability of this risk occurring, (5) Early Warning Indicators — specific signals that the risk is materializing (what would we see first?), (6) Contingency Plan — the step-by-step response if the risk occurs, with owner for each step, (7) Residual Risk — what risk remains after mitigation. Format as a standalone document for the project risk log.16. Write a Post-Incident Issue Summary
Document what went wrong, why, and what changes will prevent it from recurring — without assigning blame.
Write a post-incident issue summary for [PROJECT NAME]. The incident: [DESCRIBE WHAT HAPPENED — the problem, when it occurred, who was affected, what the impact was]. Root cause: [WHAT ANALYSIS REVEALED AS THE UNDERLYING CAUSE — not symptoms, the actual root cause]. Contributing factors: [WHAT CONDITIONS MADE THIS POSSIBLE — process gaps, communication failures, tool limitations, etc.]. Immediate actions taken: [WHAT WAS DONE TO RESOLVE THE INCIDENT]. Write a post-incident summary that includes: (1) Incident Overview — what happened, timeline, impact, (2) Root Cause Analysis — the actual cause(s) using plain language (not technical jargon), (3) Contributing Factors — the conditions that allowed this to happen, (4) Immediate Remediation — what was done to fix it, (5) Process Improvement Recommendations — 3–5 specific changes to prevent recurrence, with owners and timelines, (6) Lessons Learned — what the team now knows that it didn't before. Tone: objective and constructive — this document is about learning, not blame. No passive-aggressive language.17. Create a Dependency Mapping Summary
Map project dependencies clearly so risks from upstream delays are visible and managed proactively.
Create a project dependency mapping summary for [PROJECT NAME]. The project involves: [BRIEF DESCRIPTION OF WHAT'S BEING BUILT OR DELIVERED]. Known dependencies: [LIST EVERYTHING YOU KNOW — internal teams, external vendors, regulatory approvals, data feeds, other projects, technology platforms, third-party contracts]. Create a dependency summary that includes: (1) Dependency Register — table with: Dependency | Type (Internal/External) | Owner | Required By Date | Current Status | Risk Level, (2) Critical Path Dependencies — the dependencies where delay would directly push the project end date (highlight in the table), (3) External Dependencies — specific attention to any dependencies outside the team's control, (4) Dependency Risk Analysis — the top 3 highest-risk dependencies with mitigation for each, (5) Monitoring Plan — how and how often each dependency status will be checked. Flag any dependencies where a contract, SLA, or confirmed commitment doesn't yet exist — those are immediate risks.18. Write a Change Request Assessment
Evaluate a scope change request with a structured impact analysis before it hits the project plan.
Write a change request assessment for [PROJECT NAME]. The requested change: [DESCRIBE WHAT'S BEING ASKED FOR — be specific]. Who requested it and why: [REQUESTER AND THEIR STATED RATIONALE]. Current project status (schedule, budget): [BRIEF CURRENT STATE — e.g. "we're 3 weeks into a 12-week project, currently on schedule and budget"]. Write a formal change request assessment that includes: (1) Change Description — clear statement of exactly what is being requested, (2) Business Justification — the requester's rationale, stated objectively, (3) Schedule Impact — how many days/weeks this adds to the timeline, which milestones are affected, (4) Budget Impact — estimated additional cost, broken down by labor/materials/tools, (5) Scope Impact — what this adds to scope, and what (if anything) needs to be removed or deprioritized to absorb it, (6) Risk Impact — new risks this change introduces, (7) Recommendation — Approve / Approve with Conditions / Decline, with a 2–3 sentence rationale, (8) Conditions (if applicable) — what must be agreed before approval. Format as a document for change control board review.Section 4: Team Communication & Meeting Agendas (Prompts 19–24)
PMs live in meetings and inboxes. These prompts cover the written layer of team communication — agendas that keep meetings on track, workload rebalancing messages, cross-team alignment emails, and even preparation for difficult conversations with team members.
19. Write a Team Meeting Agenda
Build a focused meeting agenda that keeps the team on track and ends on time.
Write a team meeting agenda for [PROJECT NAME]. Meeting type: [E.G. weekly standup, sprint planning, design review, retrospective, working session]. Duration: [E.G. 30 minutes / 60 minutes]. Attendees: [LIST ROLES]. Key topics I need to cover this week: [BULLET YOUR TOPICS]. Decisions needed from this meeting: [LIST ANY DECISIONS]. Known tensions or issues to address: [ANY CONFLICTS OR BLOCKERS TO WORK THROUGH]. Create a timed agenda that: allocates time to each item proportional to importance, distinguishes between discussion items (need input from the room) and information items (PM is sharing updates), assigns a facilitator to each section, includes a concrete "next steps" slot at the end to close the loop, and protects the last 5 minutes for any issues that didn't make the agenda. Also include 3 suggested ground rules to set at the top of the meeting. Format clearly so I can send it to attendees in advance.20. Write a Team Workload Rebalancing Message
Communicate a workload redistribution to your team in a way that's clear, fair, and doesn't create resentment.
Write a team communication message about a workload rebalancing. Context: [DESCRIBE THE SITUATION — e.g. "a team member is leaving," "a new priority was added mid-project," "we're behind schedule and need to shift assignments," "one team member is overloaded and we need to redistribute"]. What's changing: [SPECIFIC ASSIGNMENTS BEING MOVED — who loses what, who gains what]. Rationale: [WHY THIS MAKES SENSE — skills alignment, capacity, project priority]. Timeline for the change: [WHEN THIS TAKES EFFECT]. Write a message to the team (or to specific individuals) that: explains the change clearly without sugarcoating, provides the honest rationale (people can handle the truth), acknowledges the impact on those taking on more work, confirms support available (check-ins, resources, adjusted deadlines if applicable), and opens the door for questions. Tone: direct and respectful — no corporate euphemisms. If someone is overloaded, say it. If there's a business reason for the change, share it.21. Write a Vendor or Contractor Onboarding Email
Set up a new vendor or contractor for success with a structured first-day email that answers every practical question.
Write an onboarding email to a new vendor or contractor joining [PROJECT NAME]. Their role: [WHAT THEY'LL BE DOING]. Project context: [BRIEF DESCRIPTION OF THE PROJECT AND WHERE WE ARE]. Key people they'll work with: [LIST NAMES AND ROLES]. Tools and systems they'll need access to: [LIST TOOLS — e.g. Jira, Confluence, Slack, Google Workspace, specific code repositories]. Communication expectations: [HOW WE COMMUNICATE — e.g. "daily standup at 9am EST," "async-first, respond within 24 hours," "weekly status update every Friday"]. First week priorities: [WHAT THEY SHOULD FOCUS ON IN WEEK 1]. Write an onboarding email that: welcomes them warmly without being excessive, covers the practical logistics they need in week 1, sets clear expectations about communication norms and deliverable formats, lists tool access requests already in progress or asks them to complete setup, and provides a clear first task or milestone. Under 350 words. Attach any relevant documents referenced (use [DOCUMENT NAME] as placeholders). Tone: professional and organized — this email should make them feel set up for success, not left to figure it out.22. Write a Cross-Team Alignment Email
Align multiple teams on shared dependencies and handoffs without another meeting that could have been an email.
Write a cross-team alignment email for [PROJECT NAME] to be sent to [TEAMS INVOLVED — e.g. Engineering, Design, Marketing, Legal, Operations]. The purpose: [WHAT NEEDS TO BE ALIGNED — e.g. "confirming the handoff sequence for the Q3 launch," "aligning on who owns the API integration testing phase," "communicating a timeline change that affects all teams"]. Key information each team needs: [BULLET WHAT EACH TEAM NEEDS TO KNOW OR CONFIRM]. Decisions that need to be confirmed in replies: [LIST SPECIFIC YES/NO OR CHOICE DECISIONS]. Deadline for responses: [DATE]. Write an email that: states the purpose in the first sentence, provides a brief project context paragraph for those who aren't deeply embedded, breaks down the specific ask for each team clearly (consider using headers per team), lists the decisions needed with explicit owners and a response deadline, and offers a brief alignment call as a fallback if email isn't enough. Under 350 words. Tone: efficient and collaborative — this should feel like coordination, not escalation.23. Write a Difficult Conversation Script for a Team Issue
Prepare for a hard conversation with a team member about performance, attitude, or a recurring issue.
Help me prepare for a difficult conversation with a team member on [PROJECT NAME]. The issue: [DESCRIBE THE BEHAVIOR OR PERFORMANCE PROBLEM — be specific about what happened, when, and the impact on the project or team]. Previous attempts to address this: [WHAT HAS BEEN SAID OR DONE BEFORE — or "this is the first direct conversation"]. What I need to achieve in this conversation: [THE OUTCOME — e.g. "clear agreement on changed behavior," "understanding of the consequences if it continues," "a plan with specific actions and a timeline"]. Write a conversation script or preparation guide that includes: (1) How to open the conversation (specific words — not "I wanted to check in"), (2) How to describe the issue using observable facts, not character judgments, (3) How to invite their perspective without losing the thread, (4) How to state clearly what needs to change and by when, (5) How to close with a concrete agreement and follow-up plan. Also note: what to do if they get defensive, what to do if they disagree with your characterization of the issue, and what the escalation path is if the conversation doesn't result in change.24. Write a Sprint Planning Email
Kick off a sprint with a pre-planning email that helps the team arrive prepared and ready to commit.
Write a sprint planning preparation email for [PROJECT NAME]. Sprint number: [NUMBER]. Sprint dates: [START DATE] to [END DATE]. Sprint goal (draft): [WHAT WE'RE AIMING TO ACHIEVE THIS SPRINT]. Backlog items likely to come into scope: [LIST THE TOP 5–10 CANDIDATES — descriptions or ticket IDs]. Known constraints for this sprint: [E.G. reduced capacity due to holiday, key dependency on design approval, technical debt item that must be addressed]. Write a pre-sprint email to the development team that: states the sprint goal in one clear sentence, lists the backlog candidates with brief descriptions so the team can review before planning, flags the constraints and asks team members to check their availability, outlines the planning session agenda and what the team should prepare (estimates, technical questions, clarifications needed), and ends with a clear ask — what do they need from me before we plan? Under 300 words. Tone: focused and prepared — this email sets the tone for an efficient planning session, not a discovery meeting.Section 5: Retrospectives & Process Improvement (Prompts 25–30)
The retrospective phase is where projects generate institutional knowledge — and where documentation most often gets skipped. These prompts help you capture retro outputs, write closure reports, document lessons learned, and recognize teams in ways that actually land.
25. Write a Sprint Retrospective Summary
Document retrospective outputs in a shareable summary that turns discussion into accountable action.
Write a sprint retrospective summary for [PROJECT NAME], Sprint [NUMBER]. Retrospective format used: [E.G. Start/Stop/Continue, 4Ls, Mad/Sad/Glad, What Went Well/What Didn't/Actions]. Raw outputs from the retrospective: [PASTE YOUR RETROSPECTIVE NOTES — sticky notes, discussion points, votes, whatever you captured]. Transform these into a structured summary that includes: (1) Sprint Context — sprint goal and whether it was achieved, (2) What Went Well — top 3–5 themes with supporting observations, (3) What Needs Improvement — top 3–5 themes, honest and specific, (4) Action Items — table with: Action | Owner | Due Date | How We'll Know It's Done, (5) One Key Takeaway — the single most important learning from this sprint in one sentence. Format ready to share with the team and archive in project documentation. Keep each section brief — the action items are the most important output. If the retrospective notes don't include owners or deadlines for actions, flag them as [TBD] and note they need to be confirmed.26. Write a Process Improvement Proposal
Turn a recurring pain point into a structured improvement proposal that's easy for leadership to approve.
Write a process improvement proposal for [PROJECT NAME / ORGANIZATION]. The problem: [DESCRIBE THE RECURRING ISSUE — be specific about what's happening, how often, and the impact on time, quality, or team morale]. Current process (what we do now): [DESCRIBE THE EXISTING WORKFLOW — step by step if possible]. Why the current process is failing: [ROOT CAUSES — not symptoms]. The proposed improvement: [WHAT YOU WANT TO CHANGE — the new process, tool, or approach]. Write a proposal that includes: (1) Problem Statement — the issue, frequency, and measurable impact (time lost, errors, team frustration), (2) Root Cause Analysis — why this keeps happening under the current process, (3) Proposed Solution — the new approach described step by step, (4) Expected Benefits — what improves, with estimated time saved or error reduction if possible, (5) Implementation Plan — phases, timeline, and who needs to be involved, (6) Resource Requirements — what this costs in time, money, or tools, (7) Success Metrics — how we'll know the improvement worked after 30/60/90 days. Format as a 1-page proposal. Keep it decision-ready — a busy manager should be able to approve or reject it without a meeting.27. Write a Lessons Learned Document
Capture institutional knowledge from a completed project before it walks out the door with the team.
Write a lessons learned document for [PROJECT NAME]. Project type: [E.G. software launch, process implementation, marketing campaign, infrastructure migration]. Project duration: [START DATE to END DATE]. Overall outcome: [DID IT HIT GOALS? ON TIME? ON BUDGET?]. Areas to cover in the lessons learned: What worked well: [NOTES — processes, decisions, team dynamics, tools]. What should be done differently: [NOTES — delays, mistakes, missed risks, communication failures]. Surprises (positive and negative): [UNEXPECTED THINGS — good or bad — that the team encountered]. Process improvements for future projects: [WHAT WOULD YOU RECOMMEND TO THE NEXT TEAM]. Write a lessons learned document with: (1) Project Summary — brief overview for anyone reading this document cold, (2) What We Got Right — top 5 practices worth repeating, with brief explanations, (3) What We'd Change — top 5 things to do differently, written as actionable recommendations (not complaints), (4) Key Risks That Materialized — what was unexpected and how it was handled, (5) Recommendations for Future Projects — a numbered checklist the next PM can actually use. Format for the project archive — this document should be useful to a future PM who never met anyone on this team.28. Write a Project Closure Report
Close a project formally with a structured report that documents outcomes, financials, and next steps.
Write a project closure report for [PROJECT NAME]. Project overview: [WHAT THE PROJECT WAS AND ITS GOALS]. Project duration: [START DATE to END DATE]. Final outcomes: Objectives achieved: [LIST WHICH GOALS WERE MET]. Objectives not met (if any): [LIST AND EXPLAIN WHY]. Schedule performance: [DELIVERED ON TIME / X DAYS EARLY / X DAYS LATE — brief reason]. Budget performance: [ON BUDGET / OVER BY X% / UNDER BY X% — brief reason]. Quality summary: [KEY QUALITY METRICS — defects, customer satisfaction, acceptance criteria met]. Write a closure report that includes: (1) Executive Summary (5–6 sentences — what was built, whether goals were met, budget and schedule summary), (2) Deliverables Summary — list all deliverables with status (Delivered / Partially Delivered / Not Delivered), (3) Performance Against Objectives — table comparing original goals to actual outcomes, (4) Financial Summary — budget vs. actual with brief variance explanation, (5) Lessons Learned Summary — top 3 takeaways for future projects, (6) Outstanding Items — any open issues, post-launch support requirements, or handoffs still in progress, (7) Formal Sign-Off — signature blocks for project sponsor and PM. Tone: objective and factual.29. Write a Team Recognition Message After a Hard Sprint
Acknowledge exceptional effort with a specific, genuine message that actually means something to the team.
Write a team recognition message for [PROJECT NAME] after a challenging sprint or project phase. The situation: [DESCRIBE WHAT THE TEAM WENT THROUGH — e.g. "a two-week crunch to hit the launch deadline," "navigating a major scope change with no additional resources," "recovering from a critical production incident while maintaining delivery pace"]. Specific contributions to call out: [LIST INDIVIDUALS OR SUBTEAMS AND WHAT THEY DID — be specific, not generic]. Outcome achieved: [WHAT WAS DELIVERED OR RESOLVED AS A RESULT OF THEIR EFFORT]. Write a recognition message to be sent to the team (all-hands message, Slack channel, or email) that: names specific contributions rather than giving generic praise, acknowledges that the effort required was significant and isn't taken for granted, connects their work to the project outcome and why it mattered, does not promise anything (no "you'll be rewarded" vagueness), and closes with a forward-looking statement that signals the next challenge. Under 200 words. Tone: genuine and specific — this should sound like it was written by someone who was in the room, not a corporate comms template.30. Write a Post-Launch Review Report
Document what happened in the first 30–90 days after launch — capturing real data before the team moves on.
Write a post-launch review report for [PROJECT NAME / PRODUCT / INITIATIVE]. Launch date: [DATE]. Review period: [E.G. "30 days post-launch," "first 90 days"]. Key metrics to report on: [LIST WHAT YOU'RE MEASURING — e.g. user adoption rate, error rate, support ticket volume, customer satisfaction score, revenue impact, SLA compliance]. Actual performance vs. target: [FILL IN YOUR DATA — or use [METRIC] and [ACTUAL vs. TARGET] as placeholders]. Issues encountered post-launch: [LIST ANY PROBLEMS THAT EMERGED AFTER GO-LIVE]. Write a post-launch review that includes: (1) Launch Summary — what was delivered and when, (2) Performance Against Success Criteria — table comparing targets to actuals for each KPI, (3) Issues Log — post-launch problems, severity, resolution status, and root cause, (4) User Feedback Summary — key themes from support tickets, user research, or direct feedback, (5) Team Performance — what the team handled well and what was harder than expected, (6) Recommendations — 3–5 specific changes for the next phase (features, processes, or monitoring), (7) Go/No-Go for Next Phase (if applicable). Format as a formal review document for stakeholder distribution.Get all 30 prompts
Unlock the full list — plus automation templates and 100+ prompts for every workflow — for just $29
Unlock Now — $29Instant download · Digital product — no shipping or physical delivery.
Get the ChatGPT Automation Templates →
The ChatGPT Automation Templates pack includes 100+ copy-paste prompts and ready-to-run automation templates for project managers, operations teams, and business professionals — status reports, risk frameworks, communication templates, and more. One payment, instant download.
Get ChatGPT Automation Templates — $29 →The project managers who consistently deliver aren't the ones who write the most documentation — they're the ones who spend their energy on decisions, alignment, and risk. Every hour you reclaim from status reports and meeting prep is an hour you can put toward the judgment work that actually moves your projects forward. If you manage teams across multiple disciplines, our guide to ChatGPT prompts for coaches and consultants covers client communication and session documentation with the same copy-paste format. And if you want a broader view of automating your workflow, how small businesses use ChatGPT to save 5+ hours a week walks through end-to-end automation systems beyond individual prompts.