How to Use Claude for Project Management:
7 Workflows PMs Actually Use

Write a project brief for the following initiative. I'll give you rough notes and you'll build the complete document. Project name: [name] What we're building / doing: [describe in plain language] Why this project exists (the business reason): [what problem are we solving or what opportunity are we capturing] Who requested it: [stakeholder or team] Who's doing the work: [team or roles involved] Goals (what does success look like): - [Goal 1 — specific and measurable where possible] - [Goal 2] - [Goal 3] What's in scope: [list] What's explicitly out of scope: [list — this is important] Key constraints: [budget / timeline / resource / technical] Timeline: [rough dates or duration] Budget: [if relevant] Key milestones: [list any you know] Risks or open questions I have: [list — even rough] Write a project brief with: 1. Project overview (2–3 sentences — what, why, and for whom) 2. Goals and success criteria 3. Scope (in / out) 4. Stakeholders and roles (RACI-style or narrative) 5. Timeline and milestones 6. Constraints and assumptions 7. Open questions that need to be resolved before kickoff Plain language. No PM jargon. Someone reading this for the first time should understand the project in under 5 minutes.

Write a stakeholder update email for [project name]. Audience: [executive sponsor / board member / client / department head / cross-functional team] Update frequency: [weekly / bi-weekly / ad hoc] Current project phase: [planning / execution / review / closeout] Status this period: - Overall status: [Green / Yellow / Red] and why in one sentence - What we accomplished: [list] - What we're working on next: [list] - Any blockers or risks: [list — be honest] - Any decisions needed from the stakeholder: [specific — if none, say so] Tone: [executive-facing and brief / detailed and collaborative / client-facing and professional] Length: [under 200 words / one page / no constraint] Write an update that: - Leads with the headline (status and one key fact) — not background - Is scannable (use short bullets, not paragraphs, for lists) - Is honest about what's at risk without being alarmist - Makes any ask or decision explicit and easy to action Subject line options: give me three versions (urgent / informational / check-in).

Build a risk register for this project: [project name and brief description] Project context: - What we're delivering: [description] - Key dependencies: [teams, vendors, systems, approvals we're depending on] - Timeline pressure: [fixed deadline / flexible / unknown] - Budget status: [comfortable / tight / unknown] - Team or stakeholder dynamics: [any known issues — e.g. "key SME is only 20% allocated" or "client is known for late approvals"] Known risks I'm already aware of: [list what you already know] Build a risk register with columns: Risk | Category | Likelihood (H/M/L) | Impact (H/M/L) | Risk Score | Mitigation Strategy | Owner | Status For each risk: - Be specific — not "timeline risk" but "SME availability for UAT is uncertain and could compress testing by 2 weeks" - Give a realistic mitigation, not just "monitor closely" - Assign ownership to a role, not a person (I'll fill in names) Also: flag the top 3 risks that need immediate attention and tell me why. Include at least 10–12 risks. Don't just cover the obvious ones — look at stakeholder, dependency, scope, resource, and external risks.

Here are my raw notes from our [meeting type — e.g. weekly project sync / stakeholder review / kickoff] today: [Paste raw notes — messy is fine] Meeting attendees: [list roles or names] Project context: [1 sentence — what project is this] Extract and format the following: 1. Decisions made (state them clearly — "We decided to..." not "There was discussion about...") 2. Action items as a table: | Action Item | Owner | Due Date | Notes | 3. Open questions that came up but weren't resolved (and who owns getting the answer) 4. A 3-sentence meeting summary I can paste into Slack or email to people who weren't there 5. Any risks or blockers that surfaced in the discussion Flag: any action item where owner or due date wasn't explicitly stated in my notes. I'll need to follow up on those. Format this so I can paste it directly into Confluence / Notion / our project tracker.

Analyze these retrospective notes from [project name] and produce a retro summary document. What went well (I'll paste the raw contributions): [Paste] What didn't go well / what we'd change: [Paste] What we want to try or experiment with next: [Paste] Project context: - Project type: [software build / campaign / event / process change / etc.] - Duration: [how long it ran] - Team size: [rough number] - Overall outcome: [delivered on time / late / scope changed / etc.] Produce a retro summary with: 1. Top 3 themes from "what went well" (with supporting observations) 2. Top 3 themes from "what didn't go well" (with root cause analysis — don't just restate the symptom) 3. Specific process improvements to implement on the next project (not suggestions — commitments) 4. One team recognition worth calling out 5. A "what we learned" section (2–3 sentences that capture the real insight from this project) Format this so the team can reference it at the start of the next similar project. Make the process improvements specific enough that someone could actually use them.

Write a timeline narrative for a [project name] presentation deck. The audience is [executive team / client / board]. Here's the timeline (paste your Gantt, milestones, or phase dates): [Paste your timeline data — even rough dates work] Key phases: - Phase 1: [name and dates] — what happens in this phase - Phase 2: [name and dates] — what happens in this phase - [Continue for each phase] Key dependencies to explain: [e.g. "Phase 2 can't start until legal review is complete in Phase 1"] Key decision points: [moments where leadership will need to review or approve] Buffer or contingency built in: [is there any? Where?] The riskiest part of the timeline: [be honest] Write a timeline narrative that: - Explains the logic of the phasing (why we're doing it in this order) - Calls out the key milestones that matter to this audience - Names the dependencies without burying them - Is honest about where we're tight on time - Fits on 2–3 presentation slides (written as slide text, not paragraphs) Give me slide titles and bullet text. I'll handle the visual formatting.

Draft a client status report for [client name] for the period [date range]. Project: [project name and brief description] Client relationship: [new / established — how formal should this be] Reporting cadence: [weekly / bi-weekly / monthly] Status this period: Overall status: [Green / Yellow / Red] Reason for status: [one clear sentence] Accomplishments this period: [List what was completed — be specific, clients notice vague updates] In progress / coming up next: [List what's in flight and what's starting next] Items requiring client input or decision: [List any — with deadlines if applicable] [If none, write "None this period"] Issues or risks to flag: [Be honest — clients respect transparency more than surprises later] Report format the client prefers: [email / PDF doc / shared doc / structured template] Tone: [formal / professional but warm / project-partner style] Write a status report that: - Starts with the headline (overall status in one sentence) - Is specific about what was accomplished (not "we made progress on Phase 2") - Makes any client action needed explicit with a clear deadline - Is honest about issues without being alarmist - Ends with a clear next touchpoint Under 400 words. Clients don't read long status reports.

Write a scope change request document for the following change: Project: [project name] What's changing: [describe the scope change clearly — what's being added, removed, or modified] Why it's changing: [business reason — not "the client asked for it" but what's driving the request] Who requested the change: [client / internal stakeholder / discovered during execution] Impact analysis: - Timeline impact: [add X days / weeks / no change — be specific] - Budget impact: [add $X / no change — or "to be estimated"] - Resource impact: [who needs to do additional work, and how much] - Risk impact: [does this change introduce new risks?] - Dependencies affected: [does this change anything downstream] Approval needed from: [client / project sponsor / budget owner] Decision deadline: [when we need an answer to stay on track] Write a scope change document with: 1. Change description (clear, specific — what exactly is changing) 2. Reason for change 3. Impact summary (timeline / budget / resources — in a table) 4. Options (if there are alternatives — e.g. "we can include this in the current phase for $X or defer it to Phase 2 at no additional cost") 5. Recommendation (what you think they should do and why) 6. Approval signature lines Tone: professional, factual, no defensiveness about the impact. Scope changes happen — document them cleanly.