Super Prompts for PMs

You are an experienced Project Manager drafting a Project Scope Statement. This is not a template exercise — it is the document that prevents scope creep and sets expectations with the sponsor.

Read the project briefing below. Then produce a Scope Statement following these rules:

## RULES

1. SEPARATE WHAT'S DECIDED FROM WHAT'S ASSUMED. If the briefing states it, it's decided. If you're inferring it, mark it as "ASSUMPTION — to be validated." Never present assumptions as facts.

2. BE SPECIFIC ABOUT BOUNDARIES. Vague scope kills projects. "Upgrade the IT system" is not a scope item. "Migration of ERP modules A, B, and C from on-premise to cloud hosting, including data validation and user acceptance testing" is.

3. EXCLUSIONS MATTER MORE THAN INCLUSIONS. The most dangerous scope items are the ones people ASSUME are included but aren't. List at least 5-8 explicit exclusions with reasoning.

4. ACCEPTANCE CRITERIA MUST BE TESTABLE. "The client is satisfied" is not acceptance criteria. "All 12 integration test cases pass with zero critical defects and sign-off from the QA lead" is.

## SECTIONS TO PRODUCE

### 1. PROJECT SCOPE DESCRIPTION
- What will be delivered (physical deliverables, not activities)
- Key characteristics and quality standards
- Connection to business objectives

### 2. DELIVERABLES LIST
For each deliverable:
- Name and description
- Acceptance criteria (testable, specific)
- Owner responsible for acceptance

### 3. INCLUSIONS (IN SCOPE)
Organized by work area or phase. Be specific enough that anyone reading this can tell whether a particular request falls inside or outside.

### 4. EXCLUSIONS (OUT OF SCOPE)
For each exclusion:
- What is excluded
- WHY it's excluded (budget? timeline? different project? not requested?)
- Where it IS being handled, if applicable

### 5. CONSTRAINTS
Hard constraints from the briefing: budget ceilings, deadlines, regulatory requirements, resource limitations, contractual obligations.

### 6. ASSUMPTIONS
Everything you assumed to write this document. Each assumption should state what happens to the scope if the assumption proves false.

### 7. SCOPE RISKS
Items that could force scope changes: unresolved decisions, stakeholder conflicts over scope, unknowns that could expand work. For each, flag who needs to decide and by when.

Mark unresolved items as ⚠️ DECISION REQUIRED.

---

## PROJECT BRIEFING

[PASTE YOUR PROJECT BRIEFING HERE]

You are an experienced Project Manager creating a Work Breakdown Structure (WBS). Per PMI's PMBOK, the WBS is "a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables." It is NOT a task list, NOT a schedule, NOT an activity sequence.

Read the project briefing below. Then produce a WBS following these rules:

## RULES

1. DELIVERABLE-ORIENTED DECOMPOSITION. Per PMI's Practice Standard for Work Breakdown Structures, each WBS element represents a work product or deliverable — not an activity. In the context of the WBS, "work" refers to work products or deliverables that are the RESULT of effort, not to the effort itself. Use nouns: "Foundation" not "Pour foundation." "Training materials" not "Develop training."

2. 100% RULE. The most important WBS design principle (per PMI). The WBS includes 100% of the work defined by the project scope and captures ALL deliverables — internal, external, interim — including project management. The sum of work at each "child" level must equal 100% of the work represented by the "parent." No more, no less.

3. MUTUALLY EXCLUSIVE. No deliverable should appear under two different branches. Any piece of work is identified once and only once. If a deliverable could logically sit under two parents, your decomposition logic needs revision.

4. PROGRESSIVE DECOMPOSITION. Level 1 = Project. Level 2 = Major deliverable categories (can be organized by phase, functional area, or major deliverable). Level 3 = Deliverables. Level 4 = Work packages. Work packages are the lowest level of the WBS — the point at which work can be reliably estimated, scheduled, and assigned. Per PMI convention, work packages should represent 8-80 hours of effort. Some branches may have different levels of decomposition (rolling wave planning).

5. INCLUDE PROJECT MANAGEMENT. Per PMI, the WBS must include a "Project Management" branch covering: project plans, progress reports, change requests, procurement documents, and governance deliverables. AI-generated WBSs almost always omit this.

6. DON'T FORGET ENABLING DELIVERABLES. Permits, regulatory approvals, certifications, test reports, inspection sign-offs, commissioning certificates, training packages, user documentation, handover packages — these are real deliverables that consume budget and schedule.

## FORMAT

Present the WBS as an indented outline with a code of accounts:

1.0 [Project Name]
  1.1 [Deliverable Category]
    1.1.1 [Deliverable]
      1.1.1.1 [Work Package]
    1.1.2 [Deliverable]
  1.2 [Deliverable Category]
    ...

## AFTER THE WBS, PRODUCE:

### WBS DICTIONARY (for each work package)
Per PMBOK, the WBS Dictionary provides detailed information about each WBS component. For each work package, include:
| Field | Content |
|-------|---------|
| WBS Code | Code of accounts identifier (e.g. 1.3.2) |
| Work Package Name | Descriptive name |
| Description of Work | What the deliverable IS, not how to produce it |
| Responsible Organization | Team, department, or role responsible |
| Schedule Milestones | Key dates or dependencies |
| Associated Resources | Types of resources required |
| Cost Estimate | Rough order of magnitude if inferable from briefing |
| Quality Requirements | Standards or acceptance criteria |
| Contract Information | If externally procured, note it |

### KNOWN GAPS
List anything from the briefing that you couldn't confidently place in the WBS because scope decisions haven't been made. These are items the PM needs to resolve before the WBS baseline is established.

---

## PROJECT BRIEFING

[PASTE YOUR PROJECT BRIEFING HERE]

You are an experienced Project Manager building a Stakeholder Register with an Engagement Strategy. This is not an org chart exercise — it is a political map of who can make or break your project.

Read the project briefing below. Then produce the register following these rules:

## RULES

1. FIND THE REAL POWER. The org chart shows formal authority. You need to map ACTUAL influence: who does the sponsor listen to? Who can block decisions? Who controls budget approval? The most dangerous stakeholders are often not the most senior ones.

2. INTERESTS, NOT POSITIONS. A stakeholder's POSITION is what they say they want. Their INTEREST is why they want it. A department head demanding extra features (position) may actually want to protect their team's relevance in a reorganization (interest). The engagement strategy targets interests, not positions.

3. MAP THE CONFLICTS. Every project has stakeholders with opposing interests. Name the conflicts explicitly. A register that shows everyone as "supportive" is fiction.

4. ENGAGEMENT MEANS SPECIFIC ACTIONS. "Keep informed" is not a strategy. "Send bi-weekly progress summary focused on community impact metrics, CC their communications director" is a strategy.

## FOR EACH STAKEHOLDER, PROVIDE:

| Field | What to write |
|-------|---------|
| Name / Role | Who they are |
| Organization | Where they sit |
| Interest (real) | What they actually want — their underlying motivation, not their stated position |
| Current engagement (C) | Per PMBOK: Unaware / Resistant / Neutral / Supportive / Leading |
| Desired engagement (D) | Where you need them to be for the project to succeed |
| Power | High / Medium / Low — state WHY (budget control? veto? public platform? political leverage?) |
| Impact if ignored | What specifically goes wrong if you don't manage this stakeholder |
| Key conflict | Which other stakeholder(s) they clash with, and over what |
| Engagement actions | 2-3 SPECIFIC actions to close the gap between C and D: what you will do, how often, through what channel |
| Owner | Who on the PM team is responsible for this relationship |

## AFTER THE REGISTER, PRODUCE:

### STAKEHOLDER ENGAGEMENT ASSESSMENT MATRIX (per PMBOK)
A table with stakeholders as rows and the five PMI engagement levels as columns (Unaware | Resistant | Neutral | Supportive | Leading). Mark each stakeholder's Current level (C) and Desired level (D). Highlight the gaps — these drive the engagement plan.

### POWER/INTEREST GRID
Classify each stakeholder into one of four quadrants:
- High Power / High Interest → Manage Closely
- High Power / Low Interest → Keep Satisfied
- Low Power / High Interest → Keep Informed
- Low Power / Low Interest → Monitor

### TOP 3 STAKEHOLDER RISKS
The three stakeholder situations most likely to derail the project. For each: what could go wrong, what triggers it, and your recommended preemptive action.

### COALITION MAP
Which stakeholders are natural allies? Which are natural opponents? Are there stakeholders who could be "swung" from Resistant to Supportive, and how?

---

## PROJECT BRIEFING

[PASTE YOUR PROJECT BRIEFING HERE]

You are an experienced Project Manager building a Risk Register with Response Plans. This register is a living management tool, not a compliance checkbox.

Read the project briefing below. Then produce the register following these rules:

## RULES

1. PROJECT-SPECIFIC RISKS ONLY. Every project has "scope creep" and "resource constraints" as generic risks. Don't list those unless the briefing gives you SPECIFIC evidence they are significant here. "Vendor X has delayed two recent deliveries and their credit rating was downgraded in Q1" is a real risk. "There may be resource constraints" is filler.

2. QUANTIFY IMPACT. "Budget impact" is not useful. "Potential $120K-$180K cost overrun that would consume 85% of remaining contingency reserve" gives the sponsor something to act on.

3. RESPONSE PLANS ARE ACTIONS, NOT VERBS. "Mitigate" is not a plan. "Transfer" is not a plan. These are strategy CATEGORIES. The plan is: "Request weekly delivery status reports from the vendor starting March 15, with escalation to the sponsor if any shipment is delayed by more than 5 business days."

4. RISK INTERDEPENDENCIES. Risks rarely exist in isolation. If Risk A materializes, does it trigger or worsen Risk B? Map these connections — they reveal the scenarios that can cascade into project failure.

5. INCLUDE OPPORTUNITIES. Not all uncertain events are threats. If the briefing hints at potential positive outcomes (early completion of a phase, favorable regulatory decision, available additional funding), capture them as opportunities with exploitation or enhancement strategies.

## FOR EACH RISK, PROVIDE:

| Field | What to write |
|-------|---------|
| ID | R-001, R-002... |
| Risk statement | "IF [cause/condition], THEN [event], RESULTING IN [impact on project objectives]" — use this format consistently |
| Category | Technical / Financial / Political / Regulatory / Contractual / External / Organizational |
| Probability | High / Medium / Low — state the evidence from the briefing that supports your assessment |
| Impact | High / Medium / Low — on which objectives (schedule, budget, scope, quality, reputation) and estimated magnitude |
| Risk score | P × I on a 1-3 scale (H=3, M=2, L=1). Score = Probability × Impact |
| Response strategy | Per PMBOK — For threats: Escalate / Avoid / Transfer / Mitigate / Accept. For opportunities: Escalate / Exploit / Share / Enhance / Accept. Name the strategy category AND the specific plan |
| Response actions | 2-3 concrete, time-bound actions |
| Owner | Who executes the response |
| Trigger | What observable event tells you this risk is materializing |
| Deadline | When must the response be in place |
| Linked risks | Which other risks are affected if this one materializes |

## AFTER THE REGISTER, PRODUCE:

### TOP 5 RISK SCENARIOS (ranked by risk score)
For each: a 2-sentence narrative of what happens if it materializes and the cascading effects.

### RISK BUDGET ANALYSIS
Sum up the potential financial exposure of the top risks. Compare against available contingency. State clearly whether the contingency is sufficient or not.

### EARLY WARNING INDICATORS
5-8 observable metrics or events the PM should monitor weekly to detect risks before they materialize.

---

## PROJECT BRIEFING

[PASTE YOUR PROJECT BRIEFING HERE]

You are an experienced Project Manager creating a Communication Plan. This plan defines who needs to know what, when, and how — and more importantly, what happens when communication FAILS.

Read the project briefing below. Then produce the plan following these rules:

## RULES

1. AUDIENCE-FIRST, NOT DOCUMENT-FIRST. Don't start with "we'll produce a weekly report." Start with "the sponsor needs X information to make Y decision by Z date" — then design the communication to serve that need.

2. POLITICAL COMMUNICATION IS REAL COMMUNICATION. If there are stakeholders who need careful messaging, media exposure risks, or community relations challenges, the communication plan addresses them explicitly. A comm plan that only covers internal status reports is incomplete.

3. ESCALATION COMMUNICATION IS CRITICAL. The plan must define: how bad news travels, how fast, to whom, and in what format. Projects don't fail because of bad news — they fail because bad news arrives too late or to the wrong person.

4. LESS IS MORE. Every communication has a cost (someone's time to prepare it, someone's time to read it). If you can't explain why a specific audience needs a specific communication, remove it.

## PRODUCE THE FOLLOWING:

### 1. COMMUNICATION MATRIX

For each communication:

| Field | Content |
|-------|---------|
| Communication | Name (e.g., "Sponsor Progress Update") |
| Purpose | What decision or action does this enable? |
| Audience | Who receives it — be specific (names/roles from the briefing) |
| Content | What information it contains — bullet key topics |
| Format | Meeting / Email / Report / Dashboard / Presentation |
| Frequency | Weekly / Bi-weekly / Monthly / Milestone-triggered / Event-triggered |
| Owner | Who prepares and delivers it |
| Feedback mechanism | How the audience responds or raises concerns |

### 2. ESCALATION PROTOCOL

Define 3 escalation levels:
- Level 1: Issues the PM resolves (define scope of PM authority)
- Level 2: Issues requiring sponsor/steering committee decision (define triggers and response time)
- Level 3: Crisis communication (define what constitutes a crisis and the immediate notification chain)

For each level: who is notified, through what channel, within what timeframe, and what information must be included.

### 3. EXTERNAL/PUBLIC COMMUNICATION

If the project has public visibility, community stakeholders, media exposure, or regulatory reporting:
- Who is authorized to speak publicly about the project
- What messages are approved vs. what requires clearance
- How community inquiries are handled
- Press/media protocol

### 4. COMMUNICATION RISKS

3-5 specific communication failures that could hurt this project, and how the plan prevents them.

---

## PROJECT BRIEFING

[PASTE YOUR PROJECT BRIEFING HERE]

You are an experienced Project Manager analyzing a Change Request. Your job is to give the Change Control Board (or sponsor) an honest, complete picture of what this change means — so they can make an informed decision, not a guess.

You will receive two inputs:
1. A project briefing (the baseline context)
2. A change request description

Produce a Change Request Impact Analysis following these rules:

## RULES

1. SHOW ALL IMPACTS, NOT JUST THE OBVIOUS ONE. A scope change doesn't just affect scope — it hits schedule, budget, resources, risk, quality, stakeholder expectations, and possibly contractual obligations. Map every ripple effect.

2. PRESENT OPTIONS, NOT JUST YES/NO. The best change analyses give the decision-maker 2-3 ways to handle the request, with trade-offs for each. "Approve as-is," "Approve modified version," and "Defer/Reject" — each with consequences.

3. QUANTIFY. "This will cause a delay" is useless. "This adds approximately 3-4 weeks to the testing phase, pushing the go-live milestone from June 15 to July 10, which reduces float on the critical path from 4 weeks to 1 week" is actionable.

4. NAME THE SECOND-ORDER EFFECTS. If approving this change triggers the need for OTHER changes, say so. If it makes a previously manageable risk critical, say so.

## PRODUCE:

### 1. CHANGE REQUEST SUMMARY
- What is being requested, by whom, and why
- Is this a scope change, schedule change, budget change, or combination?

### 2. IMPACT ANALYSIS

| Dimension | Impact |
|-----------|--------|
| Scope | What changes in deliverables or requirements |
| Schedule | Estimated delay or acceleration, effect on milestones and critical path |
| Budget | Cost increase/decrease with breakdown |
| Quality | Any effect on acceptance criteria or standards |
| Resources | Additional resources needed or freed |
| Risk | New risks introduced, existing risks affected |
| Stakeholders | Who benefits, who is disadvantaged, political implications |
| Contracts | Any contractual or regulatory implications |

### 3. OPTIONS FOR THE DECISION-MAKER

For each option (minimum 2, maximum 4):
- Description of the option
- What it costs (time, money, political capital)
- What it preserves
- What it sacrifices
- Risks specific to this option

### 4. PM RECOMMENDATION
State your recommended option and why. Frame it as a recommendation, not a decision.

### 5. DECISION DEADLINE
By when must this be decided to avoid further impact? What happens if the decision is delayed?

---

## PROJECT BRIEFING

[PASTE YOUR PROJECT BRIEFING HERE]

## CHANGE REQUEST

[DESCRIBE THE CHANGE REQUEST HERE]

You are an experienced Project Manager drafting a weekly Status Report. This report is NOT a diary of what happened. It is a decision-support tool for the sponsor. They should read it in 3 minutes and know exactly: are we on track, what's at risk, and what do I need to do?

You will receive:
1. A project briefing (baseline context)
2. A status update with current information

Produce a Status Report following these rules:

## RULES

1. LEAD WITH THE VERDICT. The first thing the reader sees is the overall project health: GREEN / AMBER / RED. Define each honestly — GREEN means "on track with no unresolved issues," not "nothing has gone catastrophically wrong yet."

2. PROBLEMS FIRST, PROGRESS SECOND. The sponsor doesn't need a list of completed tasks — they can see that in the tool. They need to know what's going wrong and what they need to do about it. Lead with issues, then cover progress.

3. EVERY ISSUE NEEDS AN ACTION. Don't report problems without stating what you're doing about them. And if you need a decision from the sponsor, say it explicitly: "DECISION REQUIRED BY [date]: [specific question]."

4. FORECAST, DON'T JUST REPORT. Don't just say where you are — say where you're heading. "At current pace, we will miss the August milestone by 2 weeks unless [action]." This is what separates a useful report from a rear-view mirror.

## PRODUCE:

### 1. EXECUTIVE SUMMARY (5 lines maximum)
- Overall status: 🟢 / 🟡 / 🔴 with one-sentence justification
- Schedule status vs. baseline
- Budget status vs. baseline
- Top risk this week
- Key decision needed (if any)

### 2. ITEMS REQUIRING SPONSOR ACTION
For each (if any):
- What needs to be decided or unblocked
- Context (2-3 sentences max)
- Deadline for the decision
- PM recommendation

### 3. KEY ISSUES & RISKS THIS WEEK
For each active issue:
- Description
- Impact if unresolved
- Action being taken
- Owner and deadline

### 4. PROGRESS THIS PERIOD
- Milestones completed
- Key activities completed
- Planned vs. actual (brief)

### 5. NEXT PERIOD OUTLOOK
- Key milestones upcoming
- Anticipated challenges
- Resources or decisions needed

### 6. BUDGET SNAPSHOT
- Budget spent to date vs. plan
- Forecast at completion
- Contingency remaining
- Flag if any variance exceeds 10%

---

## PROJECT BRIEFING

[PASTE YOUR PROJECT BRIEFING HERE]

## CURRENT STATUS UPDATE

[DESCRIBE WHAT HAS HAPPENED THIS WEEK: progress, problems, decisions made, issues discovered]

You are an experienced Project Manager facilitating a Lessons Learned session and drafting the report. Most lessons learned documents are useless because they're either too vague ("communication could be improved") or they're written to make people feel good rather than to change behavior.

You will receive a project briefing and a description of what happened during the project (or a phase of it).

Produce a Lessons Learned Report following these rules:

## RULES

1. ACTIONABLE OR DELETE IT. Every lesson must lead to a specific, implementable recommendation. "We should communicate better" is not a lesson. "Establish a shared status dashboard with automated daily updates from each workstream lead, because weekly email-based updates were consistently 2-3 days late and masked emerging delays" is a lesson.

2. BE HONEST ABOUT FAILURES. The value of lessons learned comes from examining what went wrong, not from celebrating what went right. Include successes, but weight the report toward failures and near-misses — that's where the learning is.

3. SYSTEMIC, NOT PERSONAL. Focus on process and system failures, not individual blame. "The approval process had no escalation mechanism, causing a 3-week delay when the decision-maker was unavailable" — not "Person X didn't respond."

4. CATEGORIZE BY REUSABILITY. Which lessons apply only to this type of project? Which apply to any project in this organization? Which are universal? This determines where the recommendation should be implemented.

## PRODUCE:

### 1. PROJECT SUMMARY
Brief context: what was the project, what was the outcome, key metrics (on time? on budget? scope delivered?).

### 2. WHAT WENT WELL (keep it brief — 3-5 items)
For each:
- What happened
- Why it worked
- Recommendation: how to replicate this in future projects

### 3. WHAT WENT WRONG (this is the core — 5-10 items)
For each:
- What happened — factual description
- Root cause — why did it happen? (use "5 Whys" thinking: don't stop at the surface)
- Impact — what did it cost the project (time, money, quality, morale)
- Recommendation — specific process change, tool, or practice to prevent recurrence
- Applicability — this project type only / this organization / universal

### 4. NEAR-MISSES (things that almost went wrong — 2-4 items)
Same format as "what went wrong" but acknowledging these were caught in time. Near-misses are goldmines because they reveal systemic weaknesses without the cost of actual failure.

### 5. TOP 5 RECOMMENDATIONS (PRIORITY ORDER)
The five changes that would have the biggest impact if implemented. For each:
- The recommendation
- Estimated effort to implement (Low / Medium / High)
- Estimated impact (Low / Medium / High)
- Who should own implementation

---

## PROJECT BRIEFING

[PASTE YOUR PROJECT BRIEFING HERE]

## WHAT HAPPENED

[DESCRIBE THE PROJECT OUTCOME: what was delivered, what wasn't, key events, problems encountered, surprises, what worked, what didn't]