20 Claude Prompts for Project Management That Keep Things on Track

<context> Project name: [PROJECT NAME] Sponsor: [EXECUTIVE SPONSOR NAME AND TITLE] Problem statement: [WHAT BUSINESS PROBLEM THIS PROJECT SOLVES] Key stakeholders: [LIST STAKEHOLDERS AND THEIR ROLES] Budget range: [ESTIMATED BUDGET] Target completion: [DATE OR QUARTER] </context> <task> Create a project charter document: 1. Project purpose — why this project exists (tied to business objectives, not just deliverables) 2. Scope statement — what's IN scope and explicitly what's OUT of scope 3. Success criteria — 3-5 measurable outcomes that define "done" 4. Key assumptions and constraints 5. High-level milestones (5-7 max) 6. Roles and decision rights — who approves what 7. Risks that could kill the project before it starts </task> <constraints> - Success criteria must be measurable: numbers, dates, or binary yes/no - Out-of-scope items should anticipate the most common scope creep requests - Milestones should be outcome-based ("user testing complete") not activity-based ("testing phase") - Keep the charter to 2 pages — it's an alignment tool, not a project plan - Flag any missing information I need to gather before kickoff </constraints>

<context> Project: [PROJECT NAME AND BRIEF DESCRIPTION] Deliverables: [LIST THE MAJOR DELIVERABLES] Team composition: [ROLES AVAILABLE — e.g., 2 devs, 1 designer, 1 QA] Duration: [TOTAL PROJECT TIMELINE] Dependencies: [ANY KNOWN DEPENDENCIES OR BLOCKERS] </context> <task> Create a work breakdown structure (WBS): 1. Decompose each deliverable into work packages (max 2 levels deep) 2. For each work package: - Estimated effort (hours or days) - Required skills/role - Dependencies (what must finish before this starts) - Acceptance criteria (how we know it's done) 3. Identify the critical path — which work packages have zero float 4. Flag any work packages that seem underestimated or carry hidden complexity </task> <constraints> - No work package should exceed 40 hours of effort — decompose further if it does - Dependencies must be specific: "WP 2.1 depends on WP 1.3" not "depends on design" - Include a buffer recommendation for the overall timeline (as a percentage) - Acceptance criteria must be verifiable by someone other than the person doing the work - Call out any deliverables that need more information before they can be decomposed </constraints>

<context> Project: [PROJECT NAME] Start date: [DATE] Hard deadline: [DATE AND WHY IT'S FIXED] Work packages: [PASTE YOUR WBS OR LIST OF TASKS WITH ESTIMATES] Team availability: [WHO IS AVAILABLE AND AT WHAT PERCENTAGE] Key milestones: [ANY FIXED DATES — launches, reviews, external deadlines] </context> <task> Build a project timeline: 1. Sequence all work packages based on dependencies 2. Assign resources considering availability and skill match 3. Identify the critical path and total project duration 4. Create a phase-by-phase timeline with: - Phase name, start/end dates, key deliverables - Milestone checkpoints between phases 5. Buffer analysis — where is the schedule tight and where is there float? 6. Schedule risks — what's most likely to slip and what's the impact? </task> <constraints> - No resource should be allocated at more than 80% (leave room for meetings, interrupts) - If the timeline exceeds the deadline, propose what to cut or parallelize — don't just extend - Include a "schedule confidence" rating (Low / Medium / High) with reasoning - Milestones should be decision points, not just status checks - Output as a text-based timeline table that can be transferred to any Gantt tool </constraints>

<context> Project: [PROJECT NAME AND DURATION] Team members: [LIST NAMES, ROLES, AND CURRENT AVAILABILITY %] Work packages: [PASTE WBS OR TASK LIST WITH SKILL REQUIREMENTS] Competing priorities: [OTHER PROJECTS THESE PEOPLE ARE ON] Budget for contractors: [AVAILABLE BUDGET FOR EXTERNAL HELP] </context> <task> Create a resource allocation plan: 1. Skills matrix — map required skills to available team members 2. Allocation schedule — who works on what, and when (week by week) 3. Overallocation alerts — where someone is assigned more than 100% 4. Skill gaps — what's needed that nobody on the team can cover 5. Recommendations: - Which tasks to outsource or contract out - Where to cross-train team members for resilience - How to handle the top 2 "bus factor" risks (single points of failure) 6. Escalation triggers — when to raise a resourcing flag to leadership </task> <constraints> - Respect the competing priorities — don't assume 100% dedication - Include ramp-up time for new team members or contractors - Cross-training recommendations should be practical (not "everyone learns everything") - Escalation triggers must be specific: "If [person] drops below [X]% availability for more than [Y] weeks" - Factor in PTO, holidays, and typical meeting overhead </constraints>

<context> Project: [PROJECT NAME] Reporting period: [WEEK/SPRINT/MONTH] Audience: [WHO RECEIVES THIS — leadership, steering committee, full team] Overall status: [GREEN / YELLOW / RED] </context> <task> Write a project status update: 1. TL;DR — one sentence: where we are, and what needs attention 2. Status summary (traffic light): - Schedule: [G/Y/R] — are we on track? - Budget: [G/Y/R] — are we on budget? - Scope: [G/Y/R] — has scope changed? - Quality: [G/Y/R] — are deliverables meeting standards? 3. Accomplishments this period (3-5 bullets, outcome-focused) 4. Upcoming milestones (next 2 weeks) 5. Risks and issues — what could derail us, and what we're doing about it 6. Decisions needed — anything blocking progress that requires stakeholder input 7. Help wanted — specific asks (not vague "support needed") </task> <constraints> - Lead with what matters most — if there's a problem, don't bury it below accomplishments - Accomplishments should be outcomes ("shipped feature X to 500 users") not activities ("worked on feature X") - Every risk must have an owner and a mitigation action - Decisions needed must include a recommended option so stakeholders can approve vs. discuss - Keep under 300 words — stakeholders skim, not read </constraints>

<context> Project: [PROJECT NAME] Executive audience: [VP/C-SUITE/BOARD — who specifically] What they care about: [BUDGET? TIMELINE? STRATEGIC ALIGNMENT? RISK?] Project phase: [INITIATION / PLANNING / EXECUTION / CLOSING] Key metrics: [PASTE CURRENT METRICS — % complete, budget burn, etc.] </context> <task> Write an executive summary: 1. Bottom line — one sentence on project health and trajectory 2. Strategic alignment — how this project connects to company objectives 3. Key metrics dashboard (table: metric, target, actual, trend) 4. Top 3 achievements this period (business impact, not task completion) 5. Critical risks and mitigation status 6. Budget summary — spent vs. planned, forecast to completion 7. Timeline — current projected completion vs. original baseline 8. Decision or escalation — what you need from leadership (if anything) </task> <constraints> - Executives want the "so what" — don't report activities, report outcomes and implications - If we're behind schedule or over budget, lead with that and the recovery plan - Metrics should show trend direction (improving, stable, declining) - No jargon — translate technical issues into business impact - Keep to one page maximum </constraints>

<context> Meeting type: [STEERING COMMITTEE / KICKOFF / MILESTONE REVIEW / DECISION GATE] Attendees: [LIST NAMES AND ROLES] Meeting duration: [MINUTES] Project phase: [CURRENT PHASE] Key issues to address: [WHAT NEEDS TO BE DISCUSSED OR DECIDED] Pre-read materials: [ANY DOCUMENTS ATTENDEES SHOULD REVIEW BEFOREHAND] </context> <task> Create a meeting agenda: 1. Meeting objective — one sentence on what success looks like when we leave the room 2. Agenda items with time allocations: - Topic, owner, time, purpose (inform / discuss / decide) - For decision items: options on the table and recommended choice 3. Pre-work assignments — what each attendee should prepare 4. Parking lot — anticipated tangents to defer 5. Post-meeting: action items template with owner, due date, and follow-up mechanism </task> <constraints> - Total agenda time should be 80% of meeting duration (leave buffer for discussion) - Decision items must come in the first half while energy is high - Every agenda item must have a clear purpose tag: INFORM, DISCUSS, or DECIDE - Include "what happens if we don't decide today" for each decision item - Pre-work should be specific: "review pages 3-7 of [document]" not "review materials" </constraints>

<context> Project: [PROJECT NAME] Change requested by: [STAKEHOLDER NAME AND ROLE] Current baseline: [CURRENT SCOPE, TIMELINE, AND BUDGET] Change description: [WHAT THEY WANT TO ADD, MODIFY, OR REMOVE] Reason for change: [WHY THIS IS BEING REQUESTED NOW] </context> <task> Draft a change request document: 1. Change description — clear, specific statement of what's changing 2. Justification — business case for the change (not just "stakeholder wants it") 3. Impact analysis: - Schedule impact: [days/weeks added or saved] - Budget impact: [additional cost or savings] - Scope impact: [what's added, what's removed, what's modified] - Resource impact: [who's affected and how] - Risk impact: [new risks introduced or existing risks changed] 4. Alternatives — at least 2 other ways to address the underlying need 5. Recommendation — accept, reject, or modify — with reasoning 6. Approval required from: [decision maker(s)] </task> <constraints> - Impact analysis must be specific: "adds 2 weeks to Phase 3" not "may impact timeline" - Alternatives must be genuine options, not strawmen designed to make the change look good - Include the cost of NOT making this change (what happens if we say no) - If the change triggers other changes (cascade effect), document those - Recommendation must consider project health, not just stakeholder satisfaction </constraints>

<context> Project: [PROJECT NAME AND DESCRIPTION] Phase: [CURRENT PHASE] Team size: [NUMBER AND COMPOSITION] Timeline: [START DATE TO END DATE] Known constraints: [BUDGET, TECHNOLOGY, REGULATORY, ORGANIZATIONAL] Industry: [INDUSTRY AND RELEVANT COMPLIANCE REQUIREMENTS] </context> <task> Build a comprehensive risk register: 1. Identify 15-20 risks across these categories: - Technical (architecture, integration, performance) - Schedule (dependencies, availability, complexity underestimation) - Resource (turnover, skill gaps, competing priorities) - External (vendor, regulatory, market changes) - Organizational (sponsorship, priority shifts, change resistance) 2. For each risk: - Risk ID and description - Category - Probability: 1 (rare) to 5 (almost certain) - Impact: 1 (negligible) to 5 (project-threatening) - Risk score (P x I) - Risk owner - Mitigation strategy (reduce probability or impact) - Contingency plan (what to do if it happens) - Trigger/early warning signal 3. Top 5 risks summary with detailed mitigation plans </task> <constraints> - Include at least 3 risks that project teams typically overlook (organizational, political, assumption-based) - Mitigation strategies must be actions, not "monitor closely" - Every risk must have a specific owner role (not "the team") - Early warning signals must be observable and measurable - Sort the final register by risk score, highest first </constraints>

<context> Risk: [DESCRIBE THE SPECIFIC RISK IN DETAIL] Risk score: [PROBABILITY x IMPACT RATING] Project context: [WHICH PROJECT, WHAT PHASE, WHAT'S AT STAKE] Available resources: [BUDGET AND TEAM CAPACITY FOR MITIGATION] Current status: [IS THIS RISK INCREASING, STABLE, OR DECREASING?] </context> <task> Create a detailed mitigation plan for this risk: 1. Root cause analysis — what's actually driving this risk (not just symptoms) 2. Mitigation strategy — actions to reduce probability: - Immediate actions (this week) - Short-term actions (next 2-4 weeks) - Ongoing monitoring activities 3. Impact reduction — actions to reduce damage if the risk materializes: - Fallback plan - Communication plan (who to notify and when) - Recovery steps 4. Trigger points — specific, measurable thresholds that activate the contingency 5. Cost of mitigation vs. cost of occurrence (is it worth mitigating?) 6. Escalation path — when and how to escalate to leadership </task> <constraints> - Root causes should go at least 2 levels deep (ask "why" twice) - Every action must have an owner and a deadline - Trigger points must be binary (it either happened or it didn't) — no subjective judgments - If mitigation costs more than the expected impact, say so explicitly - Include a "do nothing" option with honest assessment of consequences </constraints>

<context> Issue: [DESCRIBE THE ISSUE — WHAT HAPPENED OR IS HAPPENING] Impact: [HOW THIS AFFECTS THE PROJECT — schedule, budget, quality, scope] Discovery date: [WHEN WAS THIS IDENTIFIED] Current workarounds: [WHAT THE TEAM IS DOING RIGHT NOW] Escalating to: [WHO NEEDS TO KNOW AND DECIDE] </context> <task> Draft an escalation document: 1. Issue summary — one paragraph: what, when, impact severity (Critical / High / Medium) 2. Timeline of events — how we got here (brief chronological account) 3. Current impact: - What's blocked right now - What will be affected if unresolved in [X] days - Downstream effects on other workstreams or projects 4. Options for resolution (minimum 3): - Option A: [description, cost, timeline, trade-offs] - Option B: [description, cost, timeline, trade-offs] - Option C: [description, cost, timeline, trade-offs] 5. Recommended option with justification 6. Decision needed by: [specific date — and why that date] 7. What happens if no decision is made (the default path) </task> <constraints> - Be factual, not emotional — this is a decision document, not a complaint - Every option must include what we give up (there are no free solutions) - The "no decision" path must be explicitly stated — inaction is a choice - Include who was consulted before escalating - Keep under 1 page — executives make faster decisions with less text </constraints>

<context> Project/incident: [NAME AND BRIEF DESCRIPTION] What happened: [FACTUAL SUMMARY OF THE EVENT OR PROJECT OUTCOME] Timeline: [KEY DATES — when it started, when it was detected, when it was resolved] Team involved: [ROLES, NOT NAMES — keep it blameless] Impact: [QUANTIFIED IMPACT — days lost, revenue affected, users impacted] </context> <task> Facilitate a structured post-mortem: 1. Timeline reconstruction — what happened in chronological order (facts only) 2. What went well — things we should keep doing (minimum 3) 3. What didn't go well — honest assessment without blame (minimum 5) 4. Root cause analysis — use "5 Whys" to get to the real root causes (not symptoms) 5. Contributing factors — systemic issues that made the problem possible 6. Action items: - Immediate fixes (prevent recurrence of this specific issue) - Systemic improvements (prevent this category of issue) - Process changes (what we'll do differently going forward) 7. Follow-up plan — who reviews action items and when </task> <constraints> - Strictly blameless — use roles, not names. "The deployment process" not "John deployed" - Root causes must go beyond the surface. "We didn't test" is not a root cause. WHY didn't we test? - Every action item must have an owner (role), deadline, and success metric - Include at least one positive finding — even failures have things that went right - Action items should be proportional to impact — don't overreact to small issues </constraints>

<context> Sprint: [SPRINT NUMBER AND DATES] Sprint goal: [WHAT WE'RE TRYING TO ACHIEVE THIS SPRINT] Team capacity: [AVAILABLE STORY POINTS OR HOURS — after PTO, meetings, etc.] Velocity (last 3 sprints): [AVERAGE POINTS COMPLETED] Carryover items: [UNFINISHED ITEMS FROM LAST SPRINT] Product priorities: [TOP PRIORITIES FROM PRODUCT OWNER] </context> <task> Prepare a sprint planning document: 1. Sprint goal statement — one sentence that the team can rally around 2. Proposed sprint backlog: - User stories ranked by priority - Story points for each - Dependencies between stories - Acceptance criteria summary 3. Capacity check — total points proposed vs. team capacity 4. Risk items — stories that might not fit or have unknowns 5. Spillover plan — if we can't finish everything, what gets cut first? 6. Definition of Done checklist for this sprint 7. Commitments to other teams — any cross-team dependencies or deliverables </task> <constraints> - Don't commit to more than 85% of capacity (leave room for bugs and interrupts) - Carryover items get priority unless the product owner explicitly deprioritizes them - Flag any story over 8 points — it probably needs to be split - Dependencies must name the specific team or person we depend on - The spillover plan must be agreed on BEFORE the sprint starts, not after </constraints>

<context> Feature: [DESCRIBE THE FEATURE OR CAPABILITY] User type: [WHO IS THE PRIMARY USER — role, persona, or segment] Business goal: [WHY WE'RE BUILDING THIS — what metric does it move] Technical context: [RELEVANT SYSTEM DETAILS, EXISTING FUNCTIONALITY] Constraints: [TECHNICAL LIMITATIONS, COMPLIANCE REQUIREMENTS, DESIGN GUIDELINES] </context> <task> Write user stories for this feature: 1. Epic-level story (the big picture) 2. Break it into 4-6 individual user stories, each following the format: "As a [user type], I want to [action] so that [benefit]" 3. For each story include: - Acceptance criteria (Given/When/Then format, 3-5 criteria each) - Edge cases to consider - Technical notes for the development team - Story point estimate (relative sizing: 1, 2, 3, 5, 8) - Dependencies on other stories 4. Suggest a logical implementation order </task> <constraints> - Stories must be independent enough to be worked on separately (INVEST criteria) - Each story should be completable within one sprint - Acceptance criteria must be testable — a QA engineer should know exactly what to verify - Don't include implementation details in the story — keep the "what" separate from the "how" - Edge cases should include error states, empty states, and permission boundaries </constraints>

<context> Product: [PRODUCT NAME AND CURRENT STATE] Current backlog: [PASTE YOUR BACKLOG ITEMS — titles and brief descriptions] Business objectives this quarter: [TOP 3 OBJECTIVES] Team capacity: [AVAILABLE CAPACITY FOR THE QUARTER] Technical debt items: [ANY TECH DEBT THAT'S SLOWING THE TEAM] Customer feedback themes: [TOP REQUESTS OR PAIN POINTS FROM USERS] </context> <task> Prioritize the backlog using a structured framework: 1. Score each item on: - Business value (1-5): revenue impact, strategic alignment, customer demand - Effort (1-5): development complexity, dependencies, risk - Urgency (1-5): time sensitivity, competitive pressure, compliance deadline - Cost of delay: what happens if we DON'T do this item this quarter 2. Calculate priority score: (Business Value x Urgency) / Effort 3. Create a prioritized list grouped into: - Must do this quarter (non-negotiable) - Should do this quarter (high value, schedule permitting) - Could do this quarter (nice to have) - Won't do this quarter (explicitly deferred with reasoning) 4. Recommended sprint allocation — which items go in which sprint 5. Technical debt recommendation — how much capacity to allocate to debt reduction </task> <constraints> - At least 15-20% of capacity should go to technical debt (justify if you recommend more or less) - "Cost of delay" must be specific: revenue at risk, churn impact, or competitive disadvantage - Every "Won't do" item needs a one-line explanation (so stakeholders understand why) - Don't just rank by score — consider dependencies and sequencing - Flag any items where you need more information to score accurately </constraints>