AI prompts for project managers

Break this goal into a work breakdown structure.

GOAL: [WHAT WE WANT TO ACHIEVE]
DONE LOOKS LIKE: [OBSERVABLE END STATE]
DEADLINE: [DATE, or 'none']
PEOPLE AVAILABLE: [ROLES AND ROUGH CAPACITY]
CONSTRAINTS: [BUDGET, TECH, POLICY, DEPENDENCIES ON OTHER TEAMS]
WHAT IS EXPLICITLY OUT OF SCOPE: [LIST, or 'not decided']

Produce:

1. WORK BREAKDOWN - three levels: workstream, deliverable, task. Every task must be completable by one person in under a week. If it cannot be, break it further.

2. TASK TABLE - Task | Workstream | Depends on | Rough effort (days) | Skill needed | Can it start now? (Y/N and why not)

3. CRITICAL PATH - the chain of dependent tasks that determines the end date. State the minimum duration this implies, ignoring resource limits.

4. THE UNKNOWNS - tasks where the effort estimate is a guess rather than an estimate. These are where the plan will break. For each, name the cheapest thing you could do this week to reduce the uncertainty.

5. SCOPE CUT LADDER - if the deadline is fixed, what comes out first, second, third, and what each cut costs.

Rules:
- Do not produce a Gantt chart or assign dates. Sequence and dependencies only.
- Flag any task that depends on a team I did not list as available.
- If the deadline is not achievable from the critical path alone, say so plainly in section 3.

Write a project brief.

PROJECT: [NAME]
PROBLEM WE ARE SOLVING: [DESCRIPTION]
WHO HAS THIS PROBLEM: [USERS/STAKEHOLDERS]
HOW WE WILL KNOW IT WORKED: [SUCCESS MEASURE]
DEADLINE AND WHY: [DATE AND THE REAL REASON]
BUDGET/RESOURCE: [DETAIL]
DECISION MAKER: [WHO SIGNS OFF]

Structure:

1. PROBLEM - two sentences. The problem, not the solution.
2. WHY NOW - what changes if we do nothing for six months. If the answer is 'nothing much', say so.
3. SUCCESS CRITERIA - maximum three, each measurable, each with a target and a measurement method.
4. IN SCOPE - specific deliverables.
5. OUT OF SCOPE - this section must be at least as long as 'in scope'. List the adjacent things people will assume are included. Be aggressive.
6. ASSUMPTIONS - what must be true for this plan to hold. Each with an owner who will verify it.
7. DEPENDENCIES - other teams or systems, with what we need from each and by when.
8. DECISION RIGHTS - who decides what. Specifically: who can change scope, who can move the date, and who can stop it.
9. WHAT WE ARE NOT DOING INSTEAD - the opportunity cost. What is not getting done because of this.

Rules:
- Section 5 must not be shorter than section 4.
- Success criteria must not include 'launch' or 'deliver'. Shipping is not success.
- Anything I have not told you: mark [TO CONFIRM] with the question to ask.

Build a RAID log from these notes.

PROJECT NOTES:
"""
[PASTE EVERYTHING - MEETING NOTES, EMAILS, SLACK, PLAN DOCS]
"""

Produce four tables.

RISKS - things that might happen: ID | Risk | Likelihood | Impact | Mitigation | Owner role | Review by
ASSUMPTIONS - things we are taking as true: ID | Assumption | Who assumed it | How to verify | Consequence if false | Verify by
ISSUES - things that have already happened: ID | Issue | Impact now | Action | Owner role | Due
DEPENDENCIES - things we need from elsewhere: ID | What we need | From whom | Needed by | Confirmed? (Y/N/unknown) | What we do if it slips

Rules:
- Every entry must trace to something in my notes. Quote the source phrase in a final column.
- Classify correctly: a risk that has already materialised is an ISSUE, not a risk. An unverified belief is an ASSUMPTION, not a fact.
- 'Owner role' not owner name unless my notes named someone.
- Where my notes imply something but do not state it, add the entry and mark it [INFERRED].
- Flag any dependency where 'confirmed' is unknown - those are the most dangerous entries in the log.

End with: the three entries across all four tables that most deserve attention this week, and why.

Estimate this work. Give ranges, not points.

WHAT NEEDS BUILDING/DOING: [DESCRIPTION]
WHO WILL DO IT: [SKILL LEVEL AND HOW MANY]
SIMILAR WORK WE HAVE DONE BEFORE: [WHAT AND HOW LONG IT TOOK, or 'nothing comparable']
KNOWN UNKNOWNS: [WHAT WE HAVE NOT FIGURED OUT YET]
DEFINITION OF DONE: [INCLUDING TESTING, DOCS, REVIEW, DEPLOYMENT?]

Produce:

1. TASK BREAKDOWN with three estimates each: optimistic (everything goes right), likely, pessimistic (normal friction). Show all three.

2. TOTAL - as a range, not a number. State the range as 'X to Y days' and say which end you would bet on.

3. WHAT IS IN THE PESSIMISTIC CASE - the specific things that would have to go wrong. Name them.

4. NOT-IN-THE-ESTIMATE LIST - work that is real but usually omitted: code review time, waiting for approvals, meetings, context switching, bug fixing after release, documentation, handover, the third round of feedback. Give each a rough overhead.

5. CONFIDENCE - low / medium / high, with the reason. If there is nothing comparable in our history, confidence cannot be high.

6. HOW TO HALVE THE UNCERTAINTY - the one investigation worth doing before committing to a date.

Rules:
- Never give a single-number estimate.
- If the definition of done excludes testing or review, say that the estimate is therefore not an estimate of shipping.
- Do not pad silently. If you add contingency, show it as a separate line.

Run a pre-mortem on this plan.

THE PLAN:
"""
[PASTE PLAN OR DESCRIPTION]
"""

DEADLINE: [DATE]
TEAM: [WHO AND HOW MANY]
WHAT HAS GONE WRONG ON SIMILAR PROJECTS HERE BEFORE: [NOTES, or 'unknown']

Imagine it is [DATE + 3 months] and this project has failed completely. Write the story of how.

Produce:

1. THE FAILURE NARRATIVE - 200 words, past tense, specific. Not 'communication broke down' but the actual sequence.

2. TOP TEN FAILURE MODES - table: Failure mode | Likelihood (H/M/L) | Impact (H/M/L) | Earliest detectable signal | Who would notice it first

Cover at minimum: dependency on one person, a dependency team deprioritising us, scope growing quietly, the estimate being wrong by 2x, a key assumption being false, the thing being built but nobody using it, and approval taking longer than the work.

3. THE TOP THREE by likelihood x impact, each with: a mitigation to do now, and a tripwire - a specific observable condition that means it is happening.

4. THE ASSUMPTION MOST LIKELY TO BE WRONG - name it, and the cheapest test to check it this week.

5. WHAT WOULD MAKE ME CANCEL THIS - the conditions under which stopping is the right call. Write them down now, while it is still easy.

Be specific to this plan. Generic project risks are not useful.

Write a project status report.

PROJECT: [NAME AND GOAL]
ORIGINAL DEADLINE: [DATE]
CURRENT FORECAST: [DATE]
ORIGINAL BUDGET/SCOPE: [DETAIL]
WHERE WE ACTUALLY ARE: [PASTE HONEST NOTES]
BLOCKERS: [LIST]
AUDIENCE: [WHO AND WHAT THEY CAN DO ABOUT IT]

Produce:

1. RAG STATUS with a stated rule, not a feeling:
   - GREEN: on track for original date and scope, no unresolved blockers
   - AMBER: forecast date has moved, or scope reduced, or a blocker exists with a known path
   - RED: forecast date has moved more than once, or a blocker exists with no known path, or the goal is no longer achievable as defined
   Apply the rule literally to my inputs. State which condition triggered the rating.

2. SCHEDULE - original vs forecast, and how many times the forecast has moved if I told you.

3. WHAT IS DONE / IN PROGRESS / NOT STARTED - as counts and a short list, not a narrative.

4. BLOCKERS - table: Blocker | Owner | Age in days | What unblocks it | Who can do that.

5. THE ASK - the single most useful thing the audience could do this week.

6. IF NOTHING CHANGES - one honest sentence about where this lands.

Do not rate green because progress is being made. Progress is not the criterion; the criteria are above.

Build a stakeholder communication plan.

PROJECT: [NAME AND WHAT IT CHANGES]
STAKEHOLDERS: [LIST ROLES AND THEIR RELATIONSHIP TO THE PROJECT]
DURATION: [TIMEFRAME]
THE CHANGE PEOPLE WILL RESIST: [IF ANY]

Produce:

1. STAKEHOLDER MAP - table: Role | Interest (what they want) | Influence (H/M/L) | Current stance (supporter / neutral / sceptic / blocker / unaware) | What would move them one step

2. COMMUNICATION PLAN - table: Role | What they need to know | Channel | Frequency | Who from us | Format
   Match depth to influence and interest. High influence + low interest needs short and rare. Low influence + high interest needs detail but not your time - point them at a document.

3. THE SCEPTICS - for each: their most legitimate objection, stated fairly, and how to address it. Assume at least one of them is right about something.

4. BAD NEWS PROTOCOL - who hears bad news first, second, and never last. Specifically: who must never learn about a problem from someone else.

5. THE UNAWARE - anyone in my list who does not yet know this is happening, and when they should.

6. OVER-COMMUNICATION CHECK - anywhere this plan is asking for more of someone's attention than the project warrants. Cut it.

Do not recommend a weekly all-hands.

Write a change request.

PROJECT: [NAME]
WHAT IS BEING REQUESTED: [THE CHANGE]
WHO IS ASKING: [ROLE]
WHY THEY WANT IT: [THEIR REASON]
CURRENT STATE: [WHERE THE PROJECT IS, TIMELINE, BUDGET]

Produce:

1. THE REQUEST - one paragraph, stated in the requester's terms, fairly. Steelman it.
2. THE CASE FOR - the strongest version of why this should be approved.
3. IMPACT - a table: Dimension | Effect | Confidence. Cover: timeline, effort, cost, risk, other workstreams, things that would have to be cut, and effect on the original success criteria.
4. OPTIONS - at least three: (a) approve as requested, (b) a reduced version that captures most of the value, (c) defer to a later phase, (d) reject. For each: what it costs, what it delivers, and who will be unhappy.
5. RECOMMENDATION - one option, with reasoning in three sentences.
6. THE DECISION - who must make it, by when, and what happens automatically if they do not decide by then.

Rules:
- Section 2 must be written as its advocate would write it, not as a strawman.
- Never present 'approve' and 'reject' as the only options.
- Section 6's default must be a real default. 'It waits' is a valid answer; 'it stays open' is not.

Write a meeting agenda designed to be as short as possible.

MEETING PURPOSE: [WHAT NEEDS TO HAPPEN]
ATTENDEES: [NAMES AND ROLES]
TIME AVAILABLE: [MINUTES]
BACKGROUND: [CONTEXT, OR PASTE PRIOR NOTES]

Structure each agenda item as:
- Item title
- Type: DECISION / INPUT NEEDED / INFORMATION
- Decision to be made (one sentence, phrased as a question with a yes/no or pick-one answer)
- Who must be present for this item
- Minutes allocated
- Pre-read required (yes/no, and what)

Rules:
- Anything typed INFORMATION should not be in a meeting. For each one, say what it could be instead (email, doc, async comment) and remove it from the time budget.
- Total allocated minutes must be at most 80% of the time available.
- Order items so that anyone only needed for one item can leave early - put those first.
- End with 'Who can skip this meeting entirely and why'.

Turn these meeting notes into a structured summary.

MEETING: [MEETING NAME]
DATE: [DATE]
ATTENDEES: [NAMES AND ROLES]

NOTES/TRANSCRIPT:
"""
[PASTE]
"""

Produce exactly these sections:

1. DECISIONS MADE - only things actually decided. For each: the decision, who made it, and what it supersedes if anything. If nothing was decided, write 'No decisions were made.' Do not pad this section.

2. ACTION ITEMS - a table: Action | Owner (a named person) | Due date | Blocked by. If no owner was named, write OWNER UNASSIGNED in capitals. If no date was given, write DATE UNASSIGNED.

3. OPEN QUESTIONS - things raised and not resolved, with who raised them.

4. DISCUSSED, NO ACTION - topics that came up and went nowhere. One line each.

Rules:
- Never invent an owner or a date. Unassigned is a finding, not a gap to fill.
- Do not editorialise or summarise tone.
- If someone disagreed and was overruled, record it in Decisions.

Facilitate a blameless post-mortem.

WHAT HAPPENED: [INCIDENT OR FAILURE]
IMPACT: [WHO WAS AFFECTED AND HOW]
TIMELINE: [PASTE WHAT YOU KNOW, ROUGH IS FINE]
WHO WAS INVOLVED: [ROLES, NOT NAMES]

Produce:

1. TIMELINE - reconstructed, with times where known and [TIME UNKNOWN] where not. Separate 'what happened' from 'when we found out'.

2. CONTRIBUTING FACTORS - grouped as: process, tooling, information, and workload/time pressure. Every factor must be a system condition, not a person's choice. Rewrite any 'X forgot to' as 'the process relied on memory with no check'.

3. WHAT WENT RIGHT - genuinely. What limited the damage.

4. THE FIVE WHYS - run it once, but stop when you reach a system condition rather than a person.

5. ACTIONS - a table: Action | Type (prevent / detect faster / reduce impact) | Owner role | Effort (S/M/L). Include at least one 'detect faster' action - most post-mortems only produce prevention.

6. WHAT WE ARE ACCEPTING - risks we are consciously choosing not to fix, and why.

Never name an individual as a cause. If the input names someone, replace with their role.

Prepare talking points for a team update.

AUDIENCE: [WHOLE COMPANY / TEAM / BOARD]
LENGTH: [MINUTES]
WHAT HAPPENED (results, news, changes): [PASTE]
THE ONE MESSAGE PEOPLE MUST REMEMBER: [MESSAGE]
SENSITIVE TOPICS: [e.g. layoffs rumours, missed targets]

Produce:
1. OPENING - 2-3 sentences that say the most important thing first
2. 3-5 TALKING POINTS - each with the point, one supporting fact, and what it means for the audience
3. THE HARD PART - how to address bad news or rumours honestly and specifically
4. LIKELY QUESTIONS - 6 questions people will ask, with honest answers; mark any where the answer is "we don't know yet" and suggest how to say that well
5. CLOSE - what happens next and when they will hear more

Rules: plain language, no corporate filler ("synergies", "right-sizing"). Do not promise anything I did not state.