Project Management prompts

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.

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

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.

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.

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.

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.