ChatGPT Prompts for Project Managers

<context> You are documenting scope for [PROJECT], a project sponsored by [STAKEHOLDER] for delivery by [TIMELINE]. Business objective: [OBJECTIVE]. Known deliverables: [LIST]. Things explicitly out of scope so far: [LIST OR 'unclear']. </context> <task> 1. Write a scope statement with: objective, in-scope deliverables, out-of-scope items, assumptions, and constraints. 2. Make every in-scope item specific and verifiable (no vague verbs like 'support' or 'improve'). 3. Propose three additional out-of-scope items commonly forgotten on projects like this. 4. List the assumptions that, if wrong, would blow up the scope. 5. Keep it under 400 words and format with clear headers. </task>

<context> You are translating raw requests from [STAKEHOLDER] into requirements for [PROJECT]. Here are the requests, verbatim: [PASTE REQUESTS]. </context> <task> 1. Rewrite each request as a clear, testable requirement using 'The system shall...' or a user story format. 2. Classify each as functional or non-functional. 3. Assign a MoSCoW priority (Must, Should, Could, Won't) and justify it in one line. 4. Flag any request that is ambiguous, conflicting, or untestable, and write the clarifying question I should ask. 5. Output a requirements table: ID, requirement, type, priority, open question. </task>

<context> You are setting up traceability for [PROJECT]. Here are the requirements: [PASTE REQUIREMENTS]. Here are the planned deliverables and test cases: [PASTE DELIVERABLES AND TESTS OR 'tests not written yet']. </context> <task> 1. Map each requirement to the deliverable(s) that satisfy it. 2. Map each requirement to the test case(s) that verify it. 3. Flag any requirement with no deliverable (orphaned) or no test (unverified). 4. Flag any deliverable that maps to no requirement (gold-plating). 5. Output the matrix as a table: requirement ID, deliverable, test case, status. </task>

<context> You are evaluating a change request on [PROJECT] due [TIMELINE]. The change: [DESCRIBE CHANGE]. Current scope baseline: [SUMMARIZE BASELINE]. Current schedule and budget status: [STATUS]. </context> <task> 1. Summarize what the change actually asks for in one paragraph. 2. Assess impact on scope, schedule, budget, and risk, with a magnitude (low / medium / high) for each. 3. List the tasks that would need to be added, changed, or removed. 4. Give two options: accept with adjustments, or defer, each with consequences. 5. Draft a recommendation I can take to [STAKEHOLDER] in 100 words. </task>

<context> You are defining done for a deliverable on [PROJECT]. Deliverable: [DESCRIBE DELIVERABLE]. Who signs off: [STAKEHOLDER]. What good looks like, in their words: [PASTE OR 'unknown']. </context> <task> 1. Write acceptance criteria in Given/When/Then format covering the main scenarios. 2. Add criteria for edge cases and failure modes, not just the happy path. 3. Note any criterion that cannot be objectively verified and propose how to make it measurable. 4. List what evidence [STAKEHOLDER] will need to see to sign off. 5. Keep each criterion to one sentence and number them. </task>

<context> You are identifying risks for [PROJECT] delivering by [TIMELINE]. Project summary: [SUMMARY]. Team size: [NUMBER]. Known constraints: [CONSTRAINTS]. Key dependencies: [DEPENDENCIES]. </context> <task> 1. Brainstorm 12-15 candidate risks across categories: scope, schedule, budget, resources, technical, external, and stakeholder. 2. Phrase each risk as 'cause leads to event leads to impact', not a vague worry. 3. Group near-duplicate risks and keep the clearest wording. 4. Highlight the three risks most specific to this project rather than generic ones. 5. Output a numbered risk list grouped by category. </task>

<context> You are scoring risks for [PROJECT]. Here are the identified risks: [PASTE RISK LIST]. Use a 1-5 scale for both probability and impact. </context> <task> 1. For each risk, assign a probability (1-5) and impact (1-5) with a one-line rationale. 2. Compute the risk score (probability x impact) and rank all risks. 3. Assign each risk a response strategy: avoid, mitigate, transfer, or accept. 4. Name a likely owner role for each risk. 5. Output a risk register table: risk, probability, impact, score, strategy, owner, sorted highest score first. </task>

<context> You are planning responses for the top risks on [PROJECT] due [TIMELINE]. Top risks: [PASTE TOP 5 RISKS WITH SCORES]. </context> <task> 1. For each risk, write a mitigation plan (actions to reduce probability or impact before it happens). 2. Write a contingency plan (what we do if it happens anyway). 3. Define the trigger or early-warning sign that tells us to activate the contingency. 4. Estimate the cost or effort of each mitigation so I can judge if it is worth it. 5. Output per risk: mitigation, contingency, trigger, cost. </task>

<context> You are running a pre-mortem for [PROJECT] before it starts. Goal: [GOAL]. Timeline: [TIMELINE]. Imagine it is delivery day and the project has failed badly. </context> <task> 1. Generate 10 plausible stories for how [PROJECT] failed, written in past tense as if it already happened. 2. For each failure story, trace back to the root cause and the earliest moment it could have been caught. 3. Identify the two or three failure modes that show up across multiple stories. 4. Recommend the single highest-leverage action to prevent each recurring mode. 5. Output as: failure story, root cause, earliest signal, prevention. </task>

<context> You are mapping dependencies for [PROJECT] due [TIMELINE]. Internal dependencies between tasks: [LIST]. External dependencies on other teams or vendors: [LIST WITH OWNERS]. Current blockers: [LIST OR 'none yet']. </context> <task> 1. Build a dependency map showing what blocks what. 2. Identify the dependencies on the critical path that would delay [TIMELINE] if late. 3. Flag every external dependency where we do not control the timeline. 4. For each high-risk dependency, suggest a fallback or a way to de-risk it now. 5. Output a prioritized list of dependencies to actively manage this week. </task>

<context> You are writing a weekly status update on [PROJECT] for [STAKEHOLDER], who has five minutes. Delivery target: [TIMELINE]. This week's raw notes: [PASTE NOTES ON PROGRESS, BLOCKERS, DECISIONS]. </context> <task> 1. Open with an overall status: on track, at risk, or off track, and one sentence of why. 2. Summarize progress this week in three bullets focused on outcomes, not activity. 3. List blockers and exactly what you need from [STAKEHOLDER] to clear them. 4. State what happens next week. 5. Keep the whole update under 150 words and lead with the status color. </task>

<context> You are building a status dashboard for [PROJECT] due [TIMELINE]. Workstreams and their current state: [PASTE WORKSTREAMS WITH NOTES]. Budget status: [STATUS]. Schedule status: [STATUS]. </context> <task> 1. Assign a RAG status (red / amber / green) to each workstream with a one-line reason. 2. Assign an overall project RAG that honestly reflects the worst material issue. 3. For every amber or red item, state the action and owner to move it toward green. 4. Show schedule and budget as separate RAG indicators. 5. Output a dashboard table: workstream, RAG, reason, action, owner. </task>

<context> You are reporting a delay on [PROJECT]. Original target: [TIMELINE]. New realistic target: [NEW DATE]. What caused the slip: [CAUSES]. What you are doing about it: [RECOVERY ACTIONS]. </context> <task> 1. Write a clear, non-defensive explanation of the slip and its root cause. 2. State the revised timeline and the confidence level behind it. 3. Describe the recovery plan and what it will and will not fix. 4. Be explicit about any decision or trade-off you need leadership to make. 5. Keep the tone accountable, not apologetic, and under 200 words. </task>

<context> You are catching up on [PROJECT]. Below is a long thread of updates, messages, and notes from the past two weeks: [PASTE THREAD]. </context> <task> 1. Summarize the current state of the project in one paragraph. 2. Extract all decisions that were made, with who made them. 3. Extract all open action items, with owner and due date if stated. 4. Flag any contradiction or unresolved disagreement in the thread. 5. List the three things I should follow up on first and why. </task>

<context> You are preparing the monthly steering committee report for [PROJECT] sponsored by [STAKEHOLDER], due [TIMELINE]. Inputs: progress against milestones [DATA], budget vs plan [DATA], top risks [DATA], key decisions needed [LIST]. </context> <task> 1. Structure the report: executive summary, milestone progress, budget, risks, decisions needed, next month. 2. In the executive summary, lead with the one thing the committee must know. 3. Frame each 'decision needed' so the committee can decide in the meeting, with a recommended option. 4. Keep risk to the top three with current trend (improving / stable / worsening). 5. Output a polished, headed report under 600 words. </task>

<context> You are mapping stakeholders for [PROJECT] due [TIMELINE]. Stakeholders and what you know about each: [LIST NAMES, ROLES, INTERESTS, ATTITUDE]. </context> <task> 1. Plot each stakeholder on a power/interest grid (high or low for each). 2. Recommend an engagement approach per quadrant: manage closely, keep satisfied, keep informed, monitor. 3. For each high-power stakeholder, note their likely concern and what would make them an advocate. 4. Flag any stakeholder whose attitude is unknown or hostile and propose a first move. 5. Output an engagement plan table: stakeholder, quadrant, approach, cadence, key message. </task>

<context> You need to deliver hard news to [STAKEHOLDER] about [PROJECT]. The situation: [DESCRIBE]. Their likely reaction: [REACTION]. Relationship history: [CONTEXT]. Desired outcome of the message: [OUTCOME]. </context> <task> 1. Draft a message that states the news plainly in the first two sentences. 2. Give the context they need to understand it without burying the point. 3. Address their most likely objection before they raise it. 4. End with a clear, specific ask or next step toward [OUTCOME]. 5. Provide two tone variants: direct and more diplomatic. </task>

<context> You are communicating a [PROJECT] update. The core facts: [PASTE FACTS]. Audiences: executives, the delivery team, and [STAKEHOLDER] / clients. </context> <task> 1. Write three versions of the same update, one per audience. 2. For executives: outcomes, risks, and decisions only, under 100 words. 3. For the delivery team: specifics, dependencies, and what to do next. 4. For [STAKEHOLDER] / clients: benefits and reassurance, minimal jargon. 5. Keep the underlying facts identical across all three; only framing changes. </task>

<context> You are negotiating with [STAKEHOLDER] on [PROJECT]. The point of tension: [ISSUE]. What you want: [YOUR POSITION]. What you think they want: [THEIR POSITION]. Constraints you cannot move: [CONSTRAINTS]. </context> <task> 1. Identify the underlying interests behind each stated position, for both sides. 2. Propose three options that could satisfy both sets of interests. 3. Define your BATNA and the walk-away point. 4. Anticipate their three strongest arguments and prepare a response to each. 5. Suggest an opening framing that lowers defensiveness. </task>

<context> You are documenting a [PROJECT] meeting with [STAKEHOLDER] and the team. Here are my rough notes from the meeting: [PASTE NOTES]. </context> <task> 1. Write a clean summary of what was discussed, grouped by topic. 2. Extract every decision made into a clearly labeled Decisions section. 3. Extract every action item with owner and due date; mark any missing owner or date as TBD. 4. Note any topic raised but left unresolved, as Parking Lot items. 5. Keep it skimmable: short paragraphs, bold labels, no filler. </task>

<context> You are designing a retrospective for [PROJECT] with the delivery team. Duration: [DURATION]. The team's mood: [MOOD]. Notable events this period: [PASTE EVENTS]. </context> <task> 1. Recommend a retro format that fits [DURATION] and the team's mood (e.g. Start/Stop/Continue, 4Ls, Sailboat). 2. Build a timeboxed agenda with each activity and its purpose. 3. Write the specific prompting questions for each section, tied to the notable events. 4. Include a technique to keep quieter team members contributing. 5. End with how to turn discussion into 2-3 committed action items. </task>

<context> You are analyzing raw retrospective input for [PROJECT]. Here is everything the team submitted: [PASTE ALL FEEDBACK]. </context> <task> 1. Cluster the feedback into themes and name each theme. 2. For each theme, count how many people raised it and quote one representative point. 3. Separate systemic issues (recurring, structural) from one-off complaints. 4. Identify the two themes with the highest impact-to-effort ratio to fix. 5. Draft a candidate action item for each high-priority theme. </task>

<context> You are capturing lessons learned at the end of [PROJECT]. Outcome vs goal: [OUTCOME]. What went well: [LIST]. What went badly: [LIST]. Key surprises: [LIST]. </context> <task> 1. Organize lessons into: what to repeat, what to change, what to stop. 2. For each lesson, write it as a specific, transferable recommendation, not a vague platitude. 3. Tie each lesson to the evidence or event that produced it. 4. Note which lessons are project-specific vs applicable to all future projects. 5. End with the top three lessons the next project manager must read first. </task>

<context> You are closing out [PROJECT] delivered for [STAKEHOLDER]. Deliverables: [LIST]. Contracts or vendors involved: [LIST OR 'none']. Systems and access created: [LIST]. </context> <task> 1. Generate a closeout checklist across: deliverable sign-off, finance, contracts, access/decommissioning, documentation, and team release. 2. For each item, name who must confirm it is done. 3. Flag anything that, if missed, creates legal, security, or financial exposure. 4. Include a formal acceptance step with [STAKEHOLDER]. 5. Output as a checklist grouped by category with owner and a done column. </task>

<context> You are writing the final closure report for [PROJECT], sponsored by [STAKEHOLDER], delivered against [TIMELINE]. Final results: [RESULTS VS OBJECTIVES]. Budget outcome: [ACTUAL VS PLAN]. Major lessons: [PASTE]. </context> <task> 1. Structure the report: objectives vs outcomes, schedule performance, budget performance, scope changes, key lessons, and handover status. 2. State plainly whether the project met its objectives, with evidence. 3. Summarize variance in schedule and budget and explain the main drivers. 4. List what has been handed over to operations and what remains open. 5. Output a professional closure report under 700 words with clear headers. </task>