ChatGPT Prompts for Project Managers

<context> You are a senior project manager planning [PROJECT]. The project must deliver by [TIMELINE]. The core deliverables are: [LIST DELIVERABLES]. The team has [NUMBER] people across these roles: [LIST ROLES]. </context> <task> 1. Decompose [PROJECT] into a work breakdown structure with 4-6 top-level workstreams. 2. Under each workstream, list the concrete tasks needed to complete it. 3. For every task, estimate effort in person-days and name the role responsible. 4. Flag any task that depends on another task finishing first. 5. Present the WBS as a nested numbered outline, then summarize total effort per workstream. </task>

<context> You are scheduling [PROJECT] for delivery by [TIMELINE]. Here are the tasks and their estimated durations: [PASTE TASKS WITH DURATIONS]. Known dependencies: [LIST DEPENDENCIES]. The team is unavailable on: [BLACKOUT DATES]. </context> <task> 1. Sequence the tasks into a logical timeline working backward from [TIMELINE]. 2. Group the work into 4-6 milestones with target dates. 3. Identify the critical path and label which tasks sit on it. 4. Add a 15% schedule buffer and show where you placed it and why. 5. Output a week-by-week schedule table: week, tasks, owner, milestone. </task>

<context> You are estimating effort for [PROJECT]. Here are the tasks: [PASTE TASK LIST]. The team has delivered similar work before, with these reference points: [PAST EXAMPLES OR 'none']. </context> <task> 1. For each task, give a three-point estimate: optimistic, most likely, and pessimistic (in person-days). 2. Compute the PERT expected value for each task using (O + 4M + P) / 6. 3. Sum the expected values and the standard deviation across all tasks. 4. State the confidence range (expected value plus or minus one standard deviation). 5. Call out the three tasks with the widest spread and ask me clarifying questions to tighten them. </task>

<context> You are allocating people on [PROJECT] delivering by [TIMELINE]. Team members and their weekly capacity: [LIST PEOPLE AND HOURS]. Workstreams and their estimated effort: [LIST WORKSTREAMS]. Some people are only skilled for certain workstreams: [NOTE CONSTRAINTS]. </context> <task> 1. Assign people to workstreams respecting skill constraints and weekly capacity. 2. Flag any workstream that is under-resourced for the [TIMELINE]. 3. Identify anyone over-allocated beyond 100% in any week. 4. Propose two reallocation options to fix the worst bottleneck. 5. Output an allocation table: person, workstream, % time, weeks engaged. </task>

<context> You are running the kickoff for [PROJECT] with [STAKEHOLDER] and the delivery team. Target delivery is [TIMELINE]. Project goal: [ONE-LINE GOAL]. Meeting length: [DURATION]. </context> <task> 1. Build a timeboxed kickoff agenda that fits [DURATION]. 2. Include sections for goals, scope boundaries, roles, timeline, risks, and ways of working. 3. For each section, write the one outcome the group must leave with. 4. Add three discussion questions designed to surface hidden assumptions. 5. End with a clear list of decisions to capture and owners to assign. </task>

<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>