Prompt Library

35 ChatGPT Prompts That Cut Your Project Admin Time in Half

35 copy-paste prompts

Ready-to-use prompts for project plans, status reports, risk assessments, stakeholder updates, sprint ceremonies, and retrospectives. Less admin, more leadership.

Project Planning & Kickoff

Create a Project Plan from a Brief

I'm kicking off a new project. Here's the brief: Project: [name] Objective: [what we're delivering] Timeline: [start date to deadline] Team: [roles and headcount] Budget: [if applicable] Key stakeholders: [list them] Constraints: [fixed dates, dependencies, resource limits] Create a project plan that includes: project phases with milestones, work breakdown structure (WBS) with task dependencies, resource allocation across phases, a realistic timeline accounting for reviews and feedback cycles, top 5 risks with mitigation strategies, and a RACI matrix for key deliverables. Flag anything in the brief that seems unrealistic or underspecified.

Turns a loose brief into a structured plan with milestones, dependencies, and risk management. The "flag unrealistic" instruction catches problems before they become deadline disasters.

💡

Pro tip: Share the draft plan with your team before finalizing. The people doing the work always spot timeline issues the plan misses.

Define a Project Scope Document

Write a scope document for this project: Project: [name] Business objective: [why are we doing this?] Key deliverables: [list main outputs] Stakeholders: [who needs what] The scope document should include: objectives and success criteria (measurable), in-scope items (explicitly what we ARE doing), out-of-scope items (explicitly what we are NOT doing — this is the most important section), assumptions we're making, dependencies on other teams or systems, acceptance criteria for each deliverable, and a change request process for scope modifications. Write it in clear language a non-technical stakeholder can understand.

A clear scope document prevents scope creep. The "out of scope" section does more work than the "in scope" section — it sets boundaries everyone can reference.

💡

Pro tip: Get stakeholder sign-off on the scope document before starting work. When scope creep happens (it will), point to this document and use the change request process.

Build a Sprint/Iteration Plan

I need to plan the next [sprint length: 1/2/3 week] sprint for my team. Team capacity: [number of developers/designers/etc., minus PTO and meetings]. Carryover from last sprint: [unfinished items]. Product backlog priority items: [List backlog items with brief descriptions] Create a sprint plan that: selects items that fit within capacity (don't overfill), orders them by dependency and priority, assigns them to team members based on skills, identifies blockers we need to resolve before starting, sets a sprint goal (one sentence that captures what we're trying to achieve), and includes buffer for unexpected work ([X]% of capacity). Format as a table: Item | Assignee | Estimate | Dependencies | Priority.

Plans a realistic sprint based on actual team capacity, not wishful thinking. The buffer for unexpected work prevents every sprint from being "overcommitted."

💡

Pro tip: If the team consistently doesn't finish sprint work, reduce planned capacity by 20% rather than pressuring the team. Sustainable pace delivers more over time.

Create a Project Kickoff Agenda

I'm running a kickoff meeting for [project name] with [audience: team, stakeholders, or both]. Meeting duration: [time]. Create an agenda that covers: project background and business context (why this matters), scope overview and key deliverables, timeline and major milestones, team roles and responsibilities, communication plan (how we'll collaborate), risks and open questions to discuss, immediate next steps and first sprint preview. Include time allocations for each section. Mark which sections need discussion vs are informational. End with clear action items and owners.

Structures your kickoff to cover everything important without running over time. The discussion vs informational distinction keeps the meeting focused.

💡

Pro tip: Send the agenda 48 hours before the meeting with any pre-read materials. Kickoffs that start with everyone on the same page are 2x more productive.

Estimate Project Effort and Timeline

Help me estimate this project: Deliverables: [List each deliverable with brief description] Team: [size and roles] Constraints: [fixed deadlines, dependencies, resource limits] For each deliverable: break it into estimable tasks, provide optimistic/realistic/pessimistic time estimates, identify dependencies that affect sequencing, and note assumptions behind the estimate. Then: calculate the total project duration accounting for parallel work, identify the critical path (longest sequential chain), add appropriate buffers for unknowns ([X]% based on project novelty), and flag which estimates have the highest uncertainty.

Creates three-point estimates that account for uncertainty instead of the "best case" numbers everyone defaults to. The critical path analysis shows what actually determines your deadline.

💡

Pro tip: Use the pessimistic estimate when communicating to stakeholders. Under-promise and over-deliver beats the alternative every time.

Map Project Dependencies Across Teams

My project depends on work from other teams. Help me create a dependency map: My project deliverables: [List them with dates needed] External dependencies: [List what you need from other teams, with team names] Create: a dependency matrix showing what we need from whom and by when, critical dependencies (if this is late, our project is late), risk assessment for each dependency (based on that team's track record or capacity), a communication plan for each dependency (who to contact, escalation path), contingency plans for the highest-risk dependencies, and a visual timeline showing our work vs dependency delivery dates. Highlight any dependency that has less than 1 week of buffer.

Cross-team dependencies are where most projects die. This prompt forces you to identify, assess, and plan for them before they become surprises.

💡

Pro tip: Meet with each dependent team early and get their commitment in writing (even a Slack message). Verbal agreements have a way of being forgotten.

Status Reports & Communication

Write a Weekly Status Report

Write a weekly status report for [project name]. Here's the raw information: Completed this week: [list items] In progress: [list items with % complete] Blocked: [list blockers] Key metrics: [any numbers — velocity, bug count, etc.] Budget: [on track/over/under] Timeline: [on track/at risk/delayed] Format the report with: a one-line executive summary (green/yellow/red status with reason), completed items grouped by workstream, in-progress items with expected completion dates, risks and blockers with owners and next steps, upcoming milestones for next week, and any decisions needed from leadership. Keep it under 1 page. Use bullet points, not paragraphs.

Turns raw project notes into a clean, actionable status report. The one-line executive summary means busy stakeholders get the key message even if they read nothing else.

💡

Pro tip: If the status is yellow or red, lead with what you're doing about it — not just the problem. Stakeholders want to see a plan, not just bad news.

Prepare a Stakeholder Update Presentation

I need to present a project update to [audience: executives/board/client]. Meeting duration: [time]. The project is currently [on track/at risk/delayed]. Key updates: [List major updates, wins, issues] Create a slide outline (5-7 slides) with: executive summary slide (status, key metrics, headline), progress against milestones (visual timeline), wins and completed deliverables, risks and issues (with mitigation plans), budget and resource status, upcoming milestones and decisions needed, and Q&A prep (likely questions and answers). For each slide, provide: title, 3-4 bullet points (maximum), speaker notes with what to say, and data visualizations to suggest.

Creates a presentation that tells a story, not just reports data. The speaker notes and Q&A prep mean you walk in ready for any question.

💡

Pro tip: Executives care about outcomes and risks, not task-level details. If you're spending more than 30 seconds on any single task, you're too deep in the weeds.

Draft a Project Delay Communication

I need to communicate a project delay to [audience]. The details: Original deadline: [date] New deadline: [date] Reason for delay: [honest explanation] Impact: [what this affects] What we're doing about it: [mitigation actions] Write a communication that: leads with the new timeline (don't bury the bad news), explains the root cause honestly without throwing anyone under the bus, outlines what we've already done to minimize the delay, presents a recovery plan with specific actions, offers to meet to discuss concerns, and maintains confidence in the team's ability to deliver. Write two versions: one for executives (3 paragraphs) and one for the broader team (more detailed).

Communicates bad news professionally and constructively. The recovery plan is what separates "this project is in trouble" from "we hit a bump and here's how we're handling it."

💡

Pro tip: Communicate delays as soon as you know, not when the deadline arrives. Early warning gives stakeholders time to adjust their plans.

Summarize a Long Meeting into Action Items

I just finished a [meeting type: standup/planning/review/retro] that ran [duration]. Here are my raw notes: [paste meeting notes] Create: a clean summary (3-5 sentences capturing key decisions), action items extracted as a table: Action | Owner | Due Date | Priority, decisions made (list each with brief rationale), open questions that need follow-up, parking lot items deferred to future discussion, and any risks or concerns raised. Format this as something I can paste directly into [Slack/email/Confluence/Notion].

Turns chaotic meeting notes into structured outcomes in 30 seconds. The action items table with owners and dates is what makes meetings actually produce results.

💡

Pro tip: Send the summary within 1 hour of the meeting while memory is fresh. People correct mistakes when the meeting is recent — they ignore summaries sent the next day.

Write a Change Request Justification

I need to submit a change request for [project name]. The change: What: [describe the change] Why: [business reason] Impact on timeline: [delay/no delay] Impact on budget: [cost change] Impact on scope: [what changes] Risk of NOT making this change: [what happens if we keep the original plan] Write a change request document that: clearly describes the change, provides business justification, quantifies the impact on timeline, budget, and resources, compares the cost of change vs cost of not changing, proposes an implementation approach, and identifies who needs to approve. Keep it factual and objective — let the data make the argument.

Documents scope changes formally so they're tracked and approved, not silently absorbed. The "cost of not changing" comparison is often the strongest argument.

💡

Pro tip: Never make a significant scope change without a documented change request, even if the stakeholder says "just do it." You need the paper trail when timelines shift.

Create a Project Communication Plan

Design a communication plan for [project name]. Stakeholders: [List each stakeholder/group and what they care about] Team: [size and distribution: co-located/remote/hybrid] Duration: [project length] Create a plan that specifies: who needs what information, how often (daily/weekly/monthly/ad hoc), through what channel (Slack/email/meeting/dashboard), in what format (report/presentation/standup), and who is responsible for each communication. Include: a meeting cadence (recurring meetings with purpose and attendees), escalation paths for blockers and risks, how decisions get documented and shared, and templates for recurring communications.

Prevents the two project killers: people not having information they need, and meetings that exist without purpose. Every communication has a who, what, when, and why.

💡

Pro tip: Fewer, more focused communications beat more frequent unfocused ones. If a weekly meeting has no agenda, it should be a weekly email instead.

Risk & Issue Management

Build a Risk Register for a Project

Create a risk register for [project name]. Project context: Type: [software/construction/marketing/etc.] Timeline: [duration] Team: [size and experience] Dependencies: [external dependencies] Stakeholder complexity: [low/medium/high] Identify 15-20 risks across categories: technical, resource, schedule, scope, external, and organizational. For each risk: description, likelihood (1-5), impact (1-5), risk score (likelihood × impact), trigger (how we'll know it's happening), mitigation strategy (reduce likelihood), contingency plan (reduce impact if it happens), and owner. Sort by risk score descending. Highlight the top 5 risks that need immediate attention.

Creates a comprehensive risk register that goes beyond listing risks to include triggers, mitigations, and contingencies. The trigger identification means you catch risks early.

💡

Pro tip: Review the risk register every sprint/week. Risks change as the project evolves. A risk register from kickoff that's never updated is useless.

Analyze Why a Project Is Falling Behind

My project is behind schedule. Help me analyze why: Original plan: [key milestones and dates] Actual progress: [where we are vs where we should be] Team size: [current vs planned] Scope changes: [any additions since kickoff] Blockers encountered: [list them] Quality issues: [bugs, rework] Perform a root cause analysis: is this a planning problem (underestimated), execution problem (slow velocity), scope problem (creep), resource problem (understaffed), or dependency problem (waiting on others)? For each root cause identified, suggest specific corrective actions. Then: create a recovery plan with revised timeline, identify what can be cut or deferred to hit the original deadline, and recommend what to communicate to stakeholders.

Diagnoses WHY a project is late instead of just noting that it is. The root cause distinction between planning, execution, scope, resource, and dependency problems leads to very different solutions.

💡

Pro tip: Most delayed projects have multiple root causes. Address all of them — fixing the biggest one while ignoring the others means you'll be late again next month.

Facilitate a Pre-Mortem

Run a pre-mortem for [project name]. Imagine it's [deadline date] and the project has failed completely. What went wrong? Project context: [Brief description of the project, team, timeline] Generate: 10 plausible failure scenarios, ordered from most likely to least, the chain of events that would lead to each failure, early warning signs for each scenario, preventive actions we can take NOW for each, and a prioritized list of the top 3 actions that would prevent the most failures. Frame everything as "we could prevent this by..." rather than doom and gloom.

A pre-mortem identifies project killers before they happen. It's psychologically easier to imagine failure and work backward than to list risks from scratch.

💡

Pro tip: Run this exercise with your actual team, not just ChatGPT. Team members see risks you don't — especially the people doing the hands-on work.

Write an Issue Escalation

I need to escalate a project issue. Details: Issue: [describe the problem] Impact: [what happens if unresolved] What I've tried: [actions already taken] What I need: [decision/resources/help from leadership] Deadline: [when this needs to be resolved by] Write an escalation message to [audience: skip-level manager/VP/steering committee] that: summarizes the issue in one sentence, provides enough context without over-explaining, shows what I've already done (I'm not just passing the problem up), clearly states what I need from them and by when, and proposes 2-3 options with my recommendation. Tone: professional, urgent without being panicked, solution-oriented.

Escalation is a skill. Done poorly, it looks like complaining. Done well, it gives leadership the information and options they need to help.

💡

Pro tip: Escalate early with a recommendation. Leaders prefer choosing between options over being handed an open-ended problem.

Create a Decision Log

Help me set up and populate a decision log for [project name]. Key decisions already made: [List decisions with rough dates and context] For each decision, document: decision (what was decided), date, context (why this decision was needed), options considered (what alternatives were evaluated), rationale (why this option was chosen), decision maker(s), impact (what changes as a result), and review date (when to revisit if applicable). Create a template for future decisions. Include a section for "decisions pending" with the information needed to make them.

A decision log prevents "why did we do it this way?" conversations three months later. It also prevents re-litigating decisions that were already made thoughtfully.

💡

Pro tip: Link your decision log in every project channel. When someone questions a past decision, share the specific entry instead of re-explaining.

Assess Impact of a New Requirement

A stakeholder just requested a new requirement for [project name]: New requirement: [describe it] Current project status: [phase, % complete, remaining timeline] Current scope: [brief summary of what's in scope] Assess the impact: effort estimate to implement this (in developer days/sprint points), timeline impact (will it delay the deadline? by how much?), resource impact (do we need additional people?), technical impact (does this conflict with existing architecture or decisions?), quality risk (does adding this increase bug risk?), opportunity cost (what existing work gets delayed?). Provide three options: 1) Add it and accept the timeline impact 2) Add it but remove something else 3) Defer it to a future release. Recommend one option with justification.

Forces a structured impact assessment instead of the typical "sure, we can add that" followed by a missed deadline. The three options give stakeholders real choices.

💡

Pro tip: Present all three options to the stakeholder. Letting them choose makes them co-own the decision and its trade-offs.

Team Ceremonies & Retrospectives

Run an Effective Sprint Retrospective

Facilitate a sprint retrospective for my team. Context: Sprint: [number/name] Sprint goal: [what we aimed to do] Outcome: [did we hit the goal? what shipped?] Velocity: [planned vs actual] Key events: [anything notable — outages, scope changes, team changes] Generate: a retrospective agenda using [format: Start/Stop/Continue, 4Ls, Sailboat, or Mad/Sad/Glad], 3 discussion prompts for each category that are specific to OUR sprint (not generic), facilitation tips for drawing out quiet team members, a framework for turning complaints into actionable improvements, an action items template with owner and deadline, and a follow-up template to track if last retro's actions were completed.

Creates a retrospective tailored to your actual sprint experience — not generic "what went well?" questions. The action tracking ensures retro improvements actually happen.

💡

Pro tip: Limit retro actions to 2-3 items. Teams that leave with 10 action items complete none of them. Pick the highest-impact improvements.

Facilitate a Productive Daily Standup

My team's daily standups are [describe the problem: too long, unfocused, people zone out, same updates daily, etc.]. Team size: [number], working on [type of project], using [methodology]. Design an improved standup format that: keeps it under [target minutes], stays focused on blockers and collaboration (not status reporting), engages everyone without putting people on the spot, handles async/remote team members, surfaces risks early, and replaces the boring "what I did yesterday" format with something more useful. Include: the new format/questions, ground rules, what to take offline, and how to handle when someone has nothing new to share.

Fixes the most common meeting in software development. Most standups are status reports disguised as collaboration — this prompt redesigns them for actual value.

💡

Pro tip: The purpose of standup is to identify blockers and coordinate, not to prove you worked yesterday. If there are no blockers or coordination needs, the standup should take 2 minutes.

Run a Sprint Planning Session

Help me prepare for sprint planning. Context: Team capacity: [available person-days this sprint, accounting for PTO and meetings] Backlog items: [list top priority items with brief descriptions] Technical debt items: [if any] Carryover: [unfinished items from last sprint] Sprint length: [days/weeks] Create a sprint planning agenda that: reviews last sprint metrics (5 min), presents sprint goal candidates for team vote, walks through backlog items in priority order, includes estimation guidance for the team, allocates [X]% of capacity to technical debt, reserves [X]% buffer for unexpected work, and produces a clear sprint backlog with acceptance criteria for each item. Also prepare: a capacity worksheet and a "what if we can't fit everything" conversation framework.

Structures sprint planning to be efficient and produce a realistic sprint backlog. The capacity worksheet prevents the #1 sprint failure: overcommitting.

💡

Pro tip: Involve the team in estimation, not just the PM. Developer estimates are more accurate, and involvement creates commitment.

Write Sprint Review Demo Notes

I need to prepare a sprint review/demo for stakeholders. This sprint we completed: [List completed items with brief descriptions] For each item, help me create: a demo script (what to show, in what order, what to say), talking points connecting this feature to business value, before/after comparison if applicable, any limitations or known issues to address proactively, and metrics or data showing the impact. Also create: an opening that reminds stakeholders of the sprint goal, a closing that previews what's coming next sprint, and answers to likely stakeholder questions.

Turns a sprint review from an awkward feature walkthrough into a business-value presentation. Stakeholders care about outcomes, not implementation details.

💡

Pro tip: Demo from the user's perspective, not the developer's. Show the workflow end-to-end, not individual features in isolation.

Design a Team Working Agreement

Help my team create a working agreement. Team context: Size: [number] Distribution: [co-located/remote/hybrid, time zones] Methodology: [Scrum/Kanban/hybrid] Current pain points: [what's not working] Draft a working agreement covering: communication norms (response time, channels, async vs sync), meeting etiquette (cameras, agenda, note-taking), code review standards (turnaround time, approval requirements), definition of done (when is a task truly complete?), conflict resolution process, work-life boundaries (core hours, after-hours expectations), and decision-making framework (when to decide independently vs when to discuss). Frame each item as a positive agreement, not a rule. Include a review date to revisit and update.

Creates explicit team norms instead of letting unspoken expectations cause friction. The best teams have these conversations early, not after conflict.

💡

Pro tip: The whole team should discuss and modify this document. An agreement imposed by the PM isn't an agreement — it's a policy.

Resource & Capacity Management

Create a Resource Allocation Plan

I need to allocate my team across [number] concurrent projects/workstreams: Team members: [List each person with their skills and current capacity] Projects: [List each project with: required skills, priority, deadline, estimated effort] Create a resource allocation plan that: assigns people to projects based on skills and priority, avoids splitting anyone across more than 2 projects (context switching tax), identifies skill gaps where we need to hire or contract, shows utilization per person (flag anyone over 85%), highlights conflicts where multiple projects need the same person simultaneously, and includes a contingency plan for unplanned absences. Format as a person-by-project matrix showing allocation percentages.

Balances team allocation across competing priorities while protecting individuals from the productivity-killing effects of too much context switching.

💡

Pro tip: If someone is allocated to more than 2 projects, they're effectively at 50% capacity on each. Focused allocation delivers more total output than distributed allocation.

Make a Business Case for More Resources

I need to justify hiring [number] more [role] for my team. Current state: Team size: [current] Current workload: [projects in flight, backlog size] Delivery metrics: [velocity, lead time, quality] Pain points: [what's suffering — quality, speed, morale] Business impact of delays: [revenue, customer satisfaction, competitive risk] Build a business case that: quantifies the current capacity gap (specific numbers), shows the cost of NOT hiring (delayed projects, quality issues, burnout turnover), calculates ROI of the new hire(s) based on project value, proposes a ramp-up timeline with expected productivity curve, offers alternatives considered (contractors, process improvements, scope reduction) and why they're insufficient, and includes a specific job profile and hiring timeline.

Turns "we need more people" (which every manager says) into a data-driven business case that finance and leadership can actually approve.

💡

Pro tip: Frame the ask in terms of business outcomes, not team comfort. "We can't hit the Q3 revenue target without shipping Feature X, which requires 2 more engineers" is stronger than "the team is overloaded."

Build a Skill Matrix for Your Team

Create a skill matrix for my team to identify gaps and growth opportunities: Team members: [List each person with their role] Skills needed for our projects: [List technical and soft skills] Create a matrix template that: lists each team member against each skill, uses a rating scale (1=learning, 2=can do with help, 3=independent, 4=can teach others), highlights single points of failure (only one person knows a critical skill), identifies cross-training priorities (highest business risk skill gaps), suggests a development plan for each person (one skill to grow this quarter), and flags any skills where we have zero coverage (hiring or training emergency).

Identifies your team's bus factor — skills held by only one person — and creates a plan to fix it before that person takes vacation or leaves.

💡

Pro tip: Share the matrix with the team and let them self-assess. It's a development tool, not a performance evaluation. People are more honest when they don't feel judged.

Plan for Team Member Offboarding

A key team member is leaving the project/company in [timeframe]. They own: [List their responsibilities, knowledge areas, and ongoing work] Create a knowledge transfer plan that: lists everything that needs to be transferred, identifies who will take over each responsibility, creates a transfer schedule (what to cover each day/week), includes documentation the departing person needs to create, plans for pairing sessions on complex areas, identifies anything that needs to be deprioritized to make time for knowledge transfer, and has a "dead man's switch" checklist (access, accounts, recurring tasks). Prioritize by: what's impossible to recover if not transferred vs what we could figure out later.

Prevents the knowledge loss that usually happens when someone leaves. The prioritization ensures you capture the irreplaceable knowledge first.

💡

Pro tip: Start the knowledge transfer immediately, not "after they finish their current work." Current work can be reassigned; institutional knowledge cannot be reconstructed.

Estimate Team Velocity for Planning

Help me calculate and forecast my team's velocity for better sprint planning. Historical data (last 6 sprints): [Sprint 1: committed X points, completed Y points] [Sprint 2: committed X points, completed Y points] [continue...] Upcoming factors: [new team members, holidays, complex upcoming work, etc.] Analyze: average velocity and trend (improving, declining, stable), variance and predictability, commitment accuracy (are we overcommitting?), impact of team composition changes, and recommended capacity for next sprint. Also: identify patterns (do we slow down before releases? after sprints with carryover?), suggest a sustainable velocity target, and create a simple forecasting model for "when will we finish [X] remaining points?"

Turns sprint data into reliable forecasts. Understanding velocity trends helps you make realistic promises instead of optimistic ones.

💡

Pro tip: Velocity is for planning, not performance evaluation. Using it as a performance metric incentivizes inflating estimates, which defeats the purpose.

Process Improvement & Templates

Create a Project Handoff Document

I'm handing off [project name] to [new PM/team]. Create a comprehensive handoff document that covers: project overview and current status, key stakeholders and their concerns/priorities, team members and their roles/strengths, outstanding risks and issues (with status), decisions made and their rationale, upcoming milestones and deadlines, where to find everything (documents, repos, boards, channels), recurring meetings and their purpose, budget status and approvals, things I would do differently (lessons learned), and the #1 thing the new PM needs to pay attention to. Format as a reference document they can consult repeatedly, not a narrative they'll read once.

Creates a handoff document that actually helps the incoming PM, not just documents what happened. The "things I would do differently" section is the most valuable part.

💡

Pro tip: Schedule a walkthrough meeting to review the handoff document together. Documents answer "what" but conversations answer "why."

Build a Project Dashboard Specification

Design a project dashboard for [project name]. Audiences: [List each audience and what they care about: execs want progress, team wants blockers, clients want deliverables] For each audience, specify: key metrics to display (and how to calculate them), visualizations that make the data clear at a glance, update frequency (real-time, daily, weekly), data sources and how to pull them, red/yellow/green thresholds for status indicators, and drill-down paths (what can they click to see more detail?). Keep the main view to one screen — no scrolling. Include a mock layout description.

Designs a dashboard that gives each audience exactly what they need without information overload. The one-screen constraint forces prioritization.

💡

Pro tip: Build the executive view first — it forces you to identify what actually matters. The detailed views can come later.

Standardize Your Definition of Done

Create a "Definition of Done" for my team. Context: Team type: [frontend/backend/full-stack/design/etc.] Methodology: [Scrum/Kanban] Deployment: [CI/CD/manual releases] Quality standards: [code review required? testing standards?] Create a DoD checklist for: user stories/features, bugs, technical debt items, and documentation tasks. Each checklist should be: specific enough that two people would agree whether each item is met, realistic (achievable within a sprint), and ordered from development through testing to deployment. Include a "DoD violation" process (what happens when something is "done" but doesn't meet the checklist). Make it a printable one-page reference.

Eliminates the "but I thought it was done" problem. When done means the same thing to everyone, handoffs and reviews become frictionless.

💡

Pro tip: Start strict and relax if needed. A DoD that's too lenient creates quality problems. A DoD that's too strict can always be simplified.

Optimize a Slow or Broken Process

One of our team processes is broken: Process: [name and description of the process] Current steps: [list each step, who does it, how long it takes] Pain points: [what's frustrating about it] Frequency: [how often this process runs] People involved: [who participates] Analyze: where are the bottlenecks (steps that take longest or block most often)? What steps could be automated, eliminated, or combined? What's the root cause of the pain points? Propose a redesigned process with: new steps and owners, estimated time savings, automation opportunities, implementation plan (how to transition from old to new), and metrics to track if the new process is actually better.

Systematically improves a broken process instead of just complaining about it. The root cause analysis prevents fixing symptoms while the real problem persists.

💡

Pro tip: Involve the people who actually do the process in the redesign. They know the pain points and workarounds better than anyone.

Create a Lessons Learned Document

Help me create a lessons learned document for [project name] that just [completed/reached a milestone]. Project summary: [brief description, timeline, outcome] What went well: [list wins] What went poorly: [list problems] Surprises: [things we didn't expect] Organize lessons by category: planning and estimation, execution and delivery, communication and stakeholder management, technical decisions, team dynamics and collaboration, and process and tools. For each lesson: what happened (factual), why it happened (root cause), what we'd do differently, and specific recommendation for future projects. End with the top 5 lessons the organization should adopt across all projects.

Creates organizational learning from project experience. The "specific recommendation for future projects" forces actionable insights instead of vague observations.

💡

Pro tip: Share lessons learned across the PM team, not just within your project. One team's hard-won lesson can save another team from the same mistake.

Design a Project Governance Framework

Design a lightweight governance framework for [organization/team]. We manage [number] projects with [team size]. Current problems: [List governance issues: unclear decision authority, inconsistent processes, lack of visibility] Create a framework that covers: project intake and prioritization (how do new projects get approved?), project categorization (small/medium/large with different oversight levels), decision authority matrix (who can approve what, at what threshold), reporting cadence and format for each project tier, escalation paths and trigger criteria, quality gates and phase reviews, and portfolio-level visibility (how leadership sees across all projects). Keep it lightweight — governance should enable speed, not create bureaucracy.

Creates just enough governance to maintain control without slowing teams down. The tiered approach means small projects don't get big-project overhead.

💡

Pro tip: The best governance is invisible to teams working on small projects. Only add oversight at the level where the risk justifies the overhead.

Write a Post-Incident Review

We had an incident that affected [project/product/service]. Help me write a post-incident review: Incident: [what happened] Impact: [who was affected, for how long] Timeline: [when detected, when resolved] Root cause: [what caused it] Response: [what we did] Create a review document with: incident summary (3 sentences), detailed timeline with timestamps, root cause analysis (use "5 Whys" technique), contributing factors (what made this worse), what went well in our response, what could be improved, action items to prevent recurrence (with owners and deadlines), and a severity classification with criteria. Maintain a blameless tone throughout — focus on systems and processes, not individuals.

Creates a blameless post-incident review that improves systems instead of assigning fault. The "5 Whys" technique finds the real root cause, not the surface-level symptom.

💡

Pro tip: Publish post-incident reviews broadly. Transparency builds trust and helps other teams learn from incidents they didn't experience.

Frequently Asked Questions

No. ChatGPT is a powerful PM tool, not a PM replacement. It excels at generating documents, analyzing data, structuring communications, and creating templates — the administrative overhead that consumes 40-60% of a PM's time. It cannot build stakeholder relationships, read team dynamics, make judgment calls on competing priorities, or navigate organizational politics. Use it to spend less time on admin and more time on the human side of project management — which is where PMs actually earn their value.
Use it to prepare, not to facilitate. Before sprint planning: generate the agenda, pre-analyze the backlog, draft the sprint goal. Before retrospectives: create custom discussion prompts based on what actually happened this sprint. Before reviews: build demo scripts and talking points. After meetings: transform messy notes into clean action items. The facilitation itself should be human-led — AI can't read the room, manage dominant voices, or draw out quiet team members. ChatGPT makes your prep 5x faster so you can focus on facilitation quality.
They should — because you're reviewing and customizing everything before sending it. These prompts generate drafts, not final documents. You add the context, judgment, and nuance that makes them relevant to your specific project and audience. The output quality depends on the input quality: paste real project data and you get useful results. Use generic inputs and you get generic outputs. Most stakeholders can't tell AI-assisted documents from manually written ones — and frankly, the AI-assisted ones are often more structured and complete.
All of them. The prompts are methodology-agnostic — they work for Scrum, Kanban, Waterfall, SAFe, PRINCE2, or hybrid approaches. When a prompt references a specific ceremony (sprint planning, retrospective), adapt the terminology to your methodology. A "sprint plan" in Scrum is an "iteration plan" in SAFe and a "phase plan" in Waterfall. The underlying activities — planning work, tracking progress, managing risks, communicating status — are universal across all methodologies.
PMs who use these prompts consistently report saving 5-8 hours per week, primarily on: status reports (30 min → 5 min per report), meeting preparation (45 min → 15 min per meeting), stakeholder communications (20 min → 5 min per email), risk assessments (2 hours → 30 min), and project documentation (varies widely). The savings compound: a well-structured plan reduces firefighting later, clear communications reduce follow-up meetings, and proactive risk management prevents the crises that consume entire days.

Want to go deeper?

These prompts are just the beginning. Learn the full workflow with step-by-step video courses on our academy.