Project Management Prompts

Draft the project scoping document for [project name] at [company]. Project objective: [objective]. Sponsor: [sponsor]. Team: [composition]. Budget: [budget]. Target deadline: [deadline]. Trigger for the project: [context].

Structure: context and problem to solve (3 lines), measurable objective, included scope, explicitly EXCLUDED scope (as detailed as the included part to prevent scope creep), deliverables with acceptance criteria, dated milestones, roles and responsibilities (RACI: who decides, who executes, who is consulted, who is informed), identified risks with mitigation plans for each ([suspected risks]), assumptions, and dependencies.

Formulate each section so that any disagreement surfaces NOW, during review, rather than mid-project. End with the 3 critical questions the steering committee must resolve before launch.

Transform my raw meeting notes into structured minutes. Meeting: [subject] on [date], participants: [participants]. Here are my notes: [raw notes, even if messy].

Output format: decisions made (unambiguously phrased, stating who decided), actions (table: action, owner, deadline; if one is missing in my notes, mark it "TO BE SPECIFIED" rather than inventing), points discussed without decision (max 2 lines each), deferred items with the next discussion date.

Rules: maximum one page, no paraphrasing that alters the meaning, no diplomatic phrasing that dilutes decisions (avoid "it was agreed to move forward on the subject"). End with the list of "TO BE SPECIFIED" items to send to participants for validation.

Break down the following project into work packages and build its schedule. Project: [description and final deliverable]. Deadline: [date]. Available team: [people and availability, e.g., 2 people at 50%]. Known constraints: [constraints: client validation, vendor dependency, holiday periods].

Process: break down into work packages that produce a verifiable deliverable (no "coordination" package), decompose each package into tasks of 0.5 to 3 days, identify dependencies and the critical path, place an explicit buffer on uncertain tasks rather than hidden margins everywhere.

Deliver: structured list of work packages → tasks with estimates, weekly schedule with validation milestones, highlighted critical path, and the 3 tasks to start immediately because they condition the rest. Signal if the [date] deadline is untenable with the described team, using data to justify rather than silently compressing estimates.

Draft the weekly flash report for [project name] for [recipients, e.g., Steering Committee]. Data for the week: progress [done vs planned], difficulties [issues encountered], evolving risks [risks], budget burn [actual vs planned], pending decisions [blocking decisions and duration of delay].

Strict one-page format: project health (Green/Amber/Red) with ONE sentence justifying the color, 3 key highlights of the week, progress vs plan (one line per active work package), risks and bottlenecks (only what changed since last week), pending decisions with the owner's name and impact of delay, priorities for next week.

Rules: a project never returns to Green without explaining what fixed the issue; an Amber status for two consecutive weeks becomes Red; pending decisions must cite the date of the initial request.

Prepare the facilitation guide for a retrospective on [project name], which just ended [outcome: on time, X days late, cancelled]. Participants: [participants and roles]. Duration: [duration, e.g., 90 min]. Project highlights: [what went well or poorly, potential tensions].

Deliver: timed agenda (opening that sets the rule "we seek causes, not culprits," individual brainstorming before group discussion to avoid conformity, discussion of major points, decisions), exact questions to ask to get past generalities ("at what exact moment did we know the deadline was slipping? what stopped us from saying it?"), and the technique to handle [sensitive topic] without it turning into a trial.

Output format for lessons: each learning becomes an actionable rule for the next project ("from now on we..."), with an owner for implementation. Maximum 5 rules: beyond that, nothing will be applied.

You are an experienced Project Director. Help me build the business case for [project name] considered by [company]. Problem or opportunity at the source: [context]. Expected benefits: [expected benefits]. Maximum feasible budget: [amount]. Known alternatives: [alternatives, including doing nothing].

Structure the file into 6 parts: problem to solve and cost of inaction, possible options (including status quo) with pros and cons, rough cost and timeline estimates by option using wide ranges, expected benefits linked to measurable KPIs, major risks for each option, reasoned recommendation.

Constraints: each benefit must be attached to a verifiable indicator, otherwise classify it as a "non-measurable bet." Formulate 5 go/no-go decision criteria for the committee. End with a list of missing information that weakens the study and who should provide it.

Draft a one-page project charter for a small project that doesn't justify a full scoping note. Project: [2-sentence description]. Requester: [requester]. People involved: [people and available time]. Desired deadline: [date]. Potential budget: [amount or none].

Mandatory format, max one page: objective in one measurable sentence, final deliverable and how we know it's done, what is excluded from the scope (min 3 lines, this is the most useful section), who decides in case of conflict, milestones (max 3), the main risk and its mitigation.

Constraints: no project management jargon, use sentences a non-expert understands on first reading. If my input information is insufficient for a section, write "TO BE CLARIFIED with [person]" rather than inventing. End with the 2 questions to ask the requester before starting.

I am starting [project name] for [company] and need to gather requirements before freezing the scope. People to interview: [list of profiles, e.g., management, field users, support, IT]. What the project should produce: [suspected deliverable]. Time available per interview: [duration].

Prepare a tailored interview guide for each profile: 8 to 10 open-ended questions ranked from broadest to most specific, distinguishing questions on current operations (pain points, workarounds, volumes) from questions on future needs. Add 2 "trap" questions for each profile to surface unexpressed needs, e.g., "what do you do when the current tool isn't enough?".

Constraints: ban questions that suggest an answer or yes/no questions. Provide a synthesis template to consolidate interviews: expressed needs, inferred needs, contradictions between profiles to resolve, and key quotes.

Transform these raw needs into actionable user stories for a development team. Project: [name and short description]. Users involved: [user profiles]. Expressed needs: [list of needs, even vague].

For each need, produce: the user story in the format "As a [profile], I want [action] so that [benefit]", 3 to 5 acceptance criteria phrased in binary terms (verifiable by yes/no, no "fast" or "user-friendly" without thresholds), and questions to ask the requester if the need is too vague to be broken down.

Constraints: a story must be achievable in a few days, otherwise suggest breaking it down. Flag needs that aren't actually needs (solutions disguised as needs) and rephrase them. Present the result in a table: story, acceptance criteria, estimated size (S/M/L), open questions. End with the list of dependencies between stories.

Help me prioritize the backlog for [project name]. Pending items: [list of requests with a one-sentence description each]. Team capacity: [capacity, e.g., 15 man-days per month]. Priority objective for the quarter: [objective]. Requesters pushing the hardest: [potential political context].

Evaluate each item on two axes: value (contribution to the quarterly objective, number of users affected, cost of the unresolved problem) and estimated effort in relative size. Then classify into 4 categories: Do Now (high value, low effort), Plan (high value, high effort), Fillers (low value, low effort), Explicitly Refuse or Defer (low value, high effort).

Constraints: requester pressure is not a value criterion, but list separately the refusals that will require an explanation message. Produce the ranking in a table with a one-sentence justification per line, then draft the 3 most delicate refusal messages, keeping them short and factual.

Build the roadmap for the next 2 quarters for [product or project] at [company]. Annual objectives: [objectives]. Candidate projects: [list of considered projects]. Team capacity: [size and availability]. Existing commitments: [non-negotiable client or internal commitments].

Organize the roadmap by quarter, phrasing each line as an expected outcome, not a feature ("reduce request processing time" rather than "develop module X"). For each quarter: 2 or 3 projects max, the target outcome, the KPI for success, and dependencies.

Constraints: keep 20% of capacity unallocated for the unexpected and state this explicitly. List what is intentionally absent and why, to cut off "why not X?" questions. Provide two versions: a detailed one for the team and a 5-line version for management. Flag candidate projects whose value is too vague to be scheduled.

Help me estimate the workload for [project name]. Content: [list of packages or tasks]. Team: [profiles and experience]. Available history: [comparable projects and their actual duration, if known].

For each package: a range estimate (optimistic, likely, pessimistic) rather than a single number, the assumptions underlying the estimate (what must be true for it to hold), and the factor that would trigger the pessimistic scenario.

Constraints: when history of comparable projects exists, compare the estimate to the actual duration recorded and explain the variance. Systematically add workloads often forgotten: post-UAT fixes, coordination, learning curve, predictable absences. Present the total in 3 scenarios with the percentage gap between optimistic and pessimistic. If the gap exceeds double, state what information would reduce uncertainty before committing to a number.

Build the full budget for [project name] at [company]. Planned internal labor: [man-days per profile and daily rate if known]. External purchases and services: [list]. Duration: [duration]. Approved envelope: [amount].

First, produce the budget by line item: valued internal labor, external services, licenses and tools, miscellaneous costs, and a contingency provision with a justified percentage based on project uncertainty. Check consistency with the approved envelope and flag any overruns during construction rather than discovering them later.

Then, build the monthly tracking setup: actuals vs budget table, re-estimated Estimate to Complete (ETC) (not just remaining budget), end-of-project projection, and 2 numeric alert thresholds that trigger sponsor notification. End with the 3 most frequent budget drifts for this type of project and how to spot them early.

Establish the risk register for [project name]. Context: [project description, deadline, stakes]. Suspected risks: [identified risks]. External dependencies: [vendors, other teams, pending validations].

Complete my list with typical risks for this type of project that I haven't mentioned, looking across 4 categories: human (departures, overload, missing skills), technical, organizational (delayed decisions, scope creep), and external. For each risk: concrete description of what would happen, probability (Low/Med/High), impact (Low/Med/High), resulting criticality, observable early warning signal, prevention plan, fallback plan if the risk occurs, and monitoring owner.

Constraints: phrase each risk as an event ("vendor delivers one month late"), never as a vague theme ("delays"). Rank by descending criticality and limit the register to the 10 risks truly worth monitoring. Specify the review ritual: frequency and questions to ask.

Map the stakeholders for [project name] at [company]. Identified actors: [list of people or entities with their role]. What the project changes for each: [suspected impacts]. Perceived support and resistance: [context].

Position each actor on two axes: influence on the project (can block it, accelerate it, or neither) and current buy-in (support, neutral, reluctant). For each influential actor: what they stand to gain or lose, their likely objection in their own words, and the appropriate engagement action (involvement in decisions, regular updates, 1-on-1 before announcements).

Constraints: do not confuse the org chart with real influence; flag actors without a title whose opinion carries weight. Produce the engagement plan in a table: actor, current position, necessary position for success, actions, owner, deadline. End with the 2 actors to see as a priority this week and why.

Build the communication plan for [project name]. Target audiences: [audiences, e.g., sponsor, team, impacted users, other departments]. Project duration: [duration]. Known key moments: [milestones, go-live, announcements]. Available channels: [channels: meetings, email, intranet, signage].

For each audience, define: what they need to know (and only that), the appropriate frequency, the channel, the format (2 lines, one page, meeting), and who produces the message. Distinguish between recurring communication (progress) and event-based communication (launch, go-live, incident, project close).

Constraints: every communication must answer the recipient's question "what does this change for me?", otherwise remove it from the plan. Provide the draft launch message and go-live message. Present the plan in a summary table, then list the 3 most common communication errors for this type of project and how this plan avoids them.

Build the RACI matrix for [project name]. Main activities: [list of major activities or deliverables]. Actors: [people or functions involved]. Existing tensions or ambiguities: [context, e.g., two people think they decide on the same topic].

For each activity, assign roles: R (Responsible - does the work), A (Accountable - owner of the decision, only one per line), C (Consulted - before), I (Informed - after). Explain any non-obvious assignments in one line.

Quality constraints to check before delivering: never two As on a line, no line without an R, signal actors who are C on almost every line (consultation bottleneck) and actors with no role (to be removed or repositioned). Present the matrix in a table, then list the 3 lines most likely to create conflict during the project with your recommendation to secure them, and the questions to resolve in a team meeting before distributing the matrix.

Prepare the kick-off meeting for [project name]. Participants: [participants and roles]. Duration: [duration, e.g., 1 hour]. Scoping status: [validated or in-progress scoping document]. Sensitive points: [tensions, skepticism, history of failed projects on this topic].

Deliver: timed agenda (why this project and why now, the concrete final result, what is out of scope, who does what, milestones, team ground rules, Q&A), the 3 messages every participant must remember when leaving, and how to address [sensitive point] without letting it derail the meeting or avoiding it.

Constraints: the kick-off is not a top-down info session; plan 2 moments where participants produce something (on-the-spot risk identification, roundtable of individual constraints). Also provide the invitation message with the agenda and what everyone should prepare, and the list of what must be validated BEFORE the kick-off to avoid launching a vague project.

Prepare the next Steering Committee (SteerCo) for [project name]. Participants: [SteerCo members]. Duration: [duration]. Project status: [progress, difficulties, budget]. Decisions I need: [expected decisions with their options]. Subjects likely to monopolize discussion: [sensitive topics].

Build the agenda starting from the decisions to be obtained, not the progress: each expected decision becomes a point with allocated time, prepared options (2 or 3, with pros, cons, and recommendation), and what happens if the decision is deferred again. Progress is handled in 10 minutes max based on a document sent beforehand.

Provide: timed agenda, exact phrasing for each decision request, technique to politely cut off digressions on [sensitive topic], and the decision log template to be sent within 24 hours. End with the list of what I must send to participants 48 hours in advance.

Structure the presentation deck for the Steering Committee of [project name]. Monthly data: progress [actual vs planned], budget [actual vs budget], risks [risk evolution], pending decisions [list], highlights [monthly events].

Produce the slide-by-slide outline, max 10 slides: one-slide summary (health status, main message, pending decisions), progress by work package with variance vs plan, budget trajectory, risks with changed ratings, deep dive into the month's bottleneck with options and recommendation, requested decisions (one slide per decision), next steps.

For each slide: title phrased as a message ("Work Package 2 Catching Up," not "WP2 Progress"), content in max 5 bullets, and what to say verbally that isn't on the slide. Constraints: no context slides for things the committee already knows, rounded and compared numbers (vs plan, vs last month), details in the appendix. End with the test: if the committee only reads slide 1, do they have the essentials?

Set up the change request (CR) process for [project name]. Context: [origin of requests, e.g., client adds requests on the fly, management changes mind]. Existing bodies: [current meetings and committees]. Available buffer: [remaining time and budget margin].

Define: minimal request form (description, requester, justification, real urgency), 4 systematic assessment questions (impact on schedule, budget, other packages, what happens if we don't do it), who decides based on impact size (propose numeric thresholds), and how to track decisions in a change log.

Draft 3 template responses: request accepted with announced impact, request deferred to a later version, request refused with justification. Constraints: the process must fit on half a page or no one will use it; no request should be accepted verbally without entering the log. End with how to present this process to the most persistent requester without alienating them.

Help me prepare the renegotiation of an untenable deadline. Project: [project name]. Requested deadline: [date]. My conviction: we need [realistic duration] because [reasons: estimated workload, dependencies, team availability]. Sponsor: [sponsor profile and what matters to them]. Stakes behind the date: [why this date, if known].

Build: factual demonstration of the gap (workload vs capacity, in simple verifiable numbers), then 3 honest options to present: meet the date by reducing scope (state exactly what gets cut), keep scope by shifting the date, add resources with the cost and limits of this option (a new person isn't productive in week one).

Constraints: never say "it's impossible" without an alternative, never accept an unquantified compromise in a meeting. Prepare responses to the 3 likely sponsor objections, including "just make it work" and "we'll see." Format: one page of arguments plus the table of 3 options with compared consequences.

Build the recovery plan for [project name], currently [duration of delay] behind a [date] deadline. Identified causes: [causes of delay]. Remaining work: [remaining packages or tasks with estimates]. Team: [composition and availability]. Levers: [possible additional budget, negotiable scope].

Start by verifying the diagnosis: is the delay due to low estimates, scope creep, diverted resources, or external blocks? The answer changes the plan. Then, build the recovery using only real levers: scope reduction, re-sequencing for parallelism, removing now-useless tasks, targeted reinforcement on the critical path only.

Constraints: forbidden to recover by "compressing" remaining estimates without justification, forbidden to cut UAT/testing time. Deliver: new schedule with a reliable new date, what was sacrificed to get it, the 2 conditions for this plan to hold, and the announcement message to the sponsor that owns the delay without drowning it.

Prepare the escalation of a bottleneck on [project name]. Bottleneck: [description, e.g., pending decision, unallocated resource, conflict between two departments]. Since: [date]. What I've already tried: [follow-ups and steps taken]. Escalation recipient: [person and level]. People involved in the block: [actors, with potential sensitivities].

Draft the escalation message: reminder of the block in 3 factual, dated lines; concrete consequences of status quo quantified where possible (days lost, cost, threatened milestones); 2 or 3 resolution options with my recommendation; the requested decision and by when.

Constraints: no personal blame, let facts and dates carry the message; the recipient must be able to decide by reading only this message, without a meeting. Also provide the 60-second oral version for an elevator pitch, and the info message for people affected by the escalation so they don't discover it second-hand.

Organize action tracking for [project name] between meetings. Current situation: [observed problem, e.g., half the actions decided aren't done, follow-ups feel like policing]. Meeting frequency: [frequency]. Available tools: [tools: spreadsheet, ticketing tool, messaging].

Propose a complete system: action log format (action phrased with a verb and verifiable deliverable, single owner, deadline, status), update ritual (who updates, when, how long it takes), and graduated follow-up mechanics: automatic reminder at D-2, factual individual message at deadline, mention in meeting only on the second miss.

Draft the 3 levels of follow-up message templates, short and blame-free. Constraints: an action without a deadline or single owner is refused at the source and must be rephrased in meeting; the log must not exceed what the team can actually absorb, suggest a limitation rule. End with how to present the system to the team so it's perceived as helpful.

Design the dashboard for [project name]. Project nature: [type and deliverable]. Duration: [duration]. Sensitive points to monitor: [stakes, e.g., tight deadline, constrained budget, critical quality]. Available data: [sources: ticketing tool, timesheets, budget].

Select 6 to 8 indicators max, across 3 blocks: Progress (actual vs planned in completed deliverables, not declared percentage of tasks in progress), Health (overdue actions, pending decisions and their age, risks with rising ratings), Resources (actual vs budget, team workload).

For each indicator: precise definition, source, update frequency, justified alert threshold. Constraints: ban unverifiable declarative indicators ("80% done") in favor of binary done/not done; every indicator must trigger a possible action when it turns red, otherwise remove it. Describe the 15-minute weekly review: reading order, questions to ask, and when to alert beyond the team.

Write the monthly progress report for [project name] for [recipients, e.g., Executive Committee]. Monthly data: achievements [what was delivered], variances [delays or overruns], budget [actual vs planned], risks [evolutions], decisions made [list], alerts [bottlenecks].

Mandatory one-page format: overall trajectory in 2 sentences (will the project land on time and budget, yes or no, and what changed this month), monthly achievements in 3 bullets linked to milestones, variances with cause and treatment (no orphan variance without a plan), budget in one line with end-of-project projection, alerts requiring management with the associated explicit request.

Constraints: management reads 20 reports like this, no self-promotion or filler; every alert must lead to a specific request (trade-off, resource, decision) otherwise keep it for the team report. Variances and bad news first, not buried at the bottom.

Help me arbitrate resources between several competing projects. Current projects: [list of projects with deadlines, stakes, and progress]. Shared resources: [people on multiple projects and current allocation]. Current conflict: [description of resource conflict]. Final decision maker: [body or person].

First, build an honest snapshot: who is working on what, in real percentage (not theoretical), and where are people allocated at over 100%. Then, propose an arbitration grid on explicit criteria: value to the company, cost of delay for each project, irreversibility (closing window of opportunity), external commitments made.

Apply the grid to the current conflict and produce 2 allocation scenarios with what each project wins and loses clearly stated, and the resulting end date. Constraints: forbidden to resolve conflict by overloading people or promising 50% on 3 projects; the chosen scenario must be announceable to losing PMs with a justification that holds.

Prepare the next sprint planning for [team] on [project name]. Sprint duration: [duration]. Capacity: [people present, planned absences, recurring non-sprint time: support, meetings]. Prioritized backlog: [candidate items with estimated size]. Carryover: [unfinished items from previous sprint].

Structure the session: calculate real capacity (available time minus recurring minus buffer, with a simple displayed rule), formulate the sprint goal in one sentence stating the outcome (not a list of tickets), select items within capacity starting with carryovers, collective verification that each item is understood and defined enough to start.

Constraints: refuse items without acceptance criteria; if the requester pushes beyond capacity, the answer is a choice between items, never a silent acceptance of overload. Deliver the timed agenda, the sprint goal phrasing, and the 3 signs during the sprint that the commitment won't be met.

Prepare the facilitation for [team]'s sprint retrospective. Duration: [duration, e.g., 45 min]. Current mood: [context, e.g., worn-out ritual where no one speaks, recent tension, new team]. Current topics: [events of the past sprint]. Actions from previous retros: [decided actions and real status].

Deliver: timed agenda starting with a review of previous actions (a retro where actions aren't done dies in 3 iterations), an animation format suited to [current mood] with exact instructions, follow-up questions for when the team stays surface-level, and selection method: max 2 improvement actions, chosen by the team, each with an owner and a deadline in the next sprint.

Constraints: no "communicate better" type actions, every action describes an observable change; topics beyond the team's control (org, hierarchy) are noted separately for escalation, not ruminated on. Suggest 2 alternative formats to rotate the ritual for future retros.

Scope the daily standup for [team] on [project name]. Current situation: [observed problem, e.g., daily lasts 30 mins, turns into reporting to the lead, some people tune out]. Team size: [number]. Work mode: [in-person, remote, hybrid].

Propose the target format: max duration, fixed time, and content refocused on coordination: what was finished since yesterday, what is blocking or might block, what I need from others. Non-coordination items (technical debates, problem solving) are noted and handled immediately after with only those involved.

Give: facilitation rules that prevent reporting-to-the-boss (team talks to each other, rotating facilitator), the phrase to cut off digressions politely, adaptations for [work mode], and the 3 signals that a daily is no longer useful with a fix for each. End with the announcement message for the new format, explaining the 'why' without discrediting the old way.

Help [team] define their Definition of Done (DoD) for [project name]. Type of deliverables: [nature of deliverables, e.g., software features, training materials, study reports]. Observed problems: [symptoms, e.g., items declared done then reopened, inconsistent quality, UAT finding holes].

Build the DoD in 3 levels: what makes an item "done" (verifiable criteria: peer-reviewed, tested, documented, validated by whom), what is explicitly excluded to stay realistic, and admitted exceptions with the rule to track rather than hide them.

Constraints: max 8 criteria, all verifiable by yes/no, no criteria the team cannot meet with current means (otherwise it will be ignored during the first rush). Deliver also: the method to get buy-in via a team workshop rather than imposing it, the application rule for work already in progress, and the review ritual after a few weeks of use.

Organize the User Acceptance Testing (UAT) for [project name]. Deliverable to test: [description]. Available testers: [profiles and availability]. Planned duration: [duration]. Existing acceptance criteria: [pre-defined criteria, or none].

Build: the UAT plan with test cases organized by real user journeys (not by screen or function), each case described by input data, action, and expected result; case prioritization (blocking for go-live, important, nice-to-have); anomaly classification rules with concrete examples for each level to avoid endless debates; the fix and re-test cycle.

Also deliver the UAT sign-off template: what was tested, anomalies by level, decision (Acceptance, Acceptance with listed and dated reservations, Rejection) and signatories. Constraints: testing without realistic data proves nothing, specify how to prepare the dataset; accepted reservations must have an owner and a deadline, otherwise they become permanent.

Prepare the deployment plan for [deliverable or system] for [project name]. Target date: [date]. Impacted users: [who and how many]. Possible maintenance window: [slot, e.g., weekend, night, business hours]. Go-live actors: [people and roles]. Rollback possible: [yes/no/partial, and how].

Build: pre-deployment checklist (technical prerequisites, validations obtained, comms sent, backups verified, key actor availability), hour-by-hour go-live schedule with owner for each step and observable success criteria, go/no-go decision points with who decides and on what criteria, rollback plan triggered by which signals and how to execute, and monitoring for the first few hours/days.

Constraints: every step has a verifiable success criterion, no "should be fine"; the rollback must be described with the same detail as the go-live, as it's executed under stress. End with the user announcement message before and after go-live.

Organize business continuity during the migration from [old system/process] to [new system/process] at [company]. Planned transition duration: [duration]. Activities that cannot stop: [critical activities]. Teams involved: [teams]. Known high-risk periods: [calendar constraints, e.g., end-of-year close, seasonal peak].

Address the questions that cause transition failures: during coexistence, which system is the source of truth for each data type or operation (clear rule by case, displayed), how to avoid double entry or organize it cleanly if inevitable, who handles "straddling" operations started in the old and finished in the new, and how to freeze or sync data at final cutover.

Deliver: critical activities table with their operating mode during transition, "source of truth" rules by case, reinforced support setup for the first weeks, and the 3 most likely incident scenarios with the required response for each.

Prepare the closure of [project name], deliverable accepted on [date]. Project elements: [vendors involved, budget, documentation produced, team]. Remaining reservations: [any UAT reservations].

Build the full closure checklist: Contractual (vendor final payments, clearing reservations, revoking external access), Financial (stopping time entries, actual vs budget report with variance explanation, closing budget lines), Documentary (where to archive what, what must be retrievable in 2 years and by whom), Human (properly announced team reassignment, specific thank-yous at the right level), Handover (who becomes responsible for the deliverable in production, with what support).

Constraints: distinguish what blocks closure from what can be finished after; a "98% finished" project dragging for 6 months is costly, set a firm closure date. Also deliver the one-page project summary: key figures, successes, variances, and where lessons learned are archived.

Organize the handover for [project name] between [outgoing PM] and [incoming PM]. Reason for departure: [reason and notice period]. Project status: [progress, hot spots, upcoming milestones]. Possible shadowing time: [overlap duration, or none].

Build the handover file prioritizing what isn't in any document: history of decisions and their reasons, verbal commitments made to client/sponsor, sensitive topics and actor temperaments, risks the outgoing PM monitors without formalizing, real status of each package beyond official reporting.

Organize shadowing: meetings where the outgoing PM introduces the incoming PM in person (sponsor, client, team), order of topics to transmit by urgency, and the change announcement message that reassures without overplaying continuity. Constraints: handover is verified, provide a list of questions the incoming PM must be able to handle alone by the end; what couldn't be transmitted is explicitly listed with a backup contact.

Prepare the onboarding for [newcomer, profile] joining [project name] on [date], mid-project. Project status: [progress and context]. Expected role: [assigned missions]. Team's available time for support: [real constraint].

Build the first 2 weeks' path: day one reading kit limited to essentials (scoping doc, last flash report, risk register, project glossary), 4 meetings to schedule with the right people and the objective for each, a first useful and well-defined contribution in week one (choose based on [expected role]), and a designated buddy with a 10-minute daily check-in.

Constraints: ban the tour of 15 passive meetings, the newcomer learns by doing; explicit what no one ever tells a newcomer: actor sensitivities, touchy subjects, real decision circuits. Deliver the 2-week schedule, ordered reading list, and questions the newcomer should be able to answer at D+15 to validate integration.

Help me manage a conflict in my project team. Context: [factual description of conflict between two people, without judgment], on [project name]. Observed impact: [effects on project: info withholding, tense meetings, delays]. My role: [PM, no direct report / with direct report]. History: [conflict duration, previous attempts].

Propose a 3-step approach: individual interviews first (questions to understand each version without validating or betraying, traps to avoid like playing judge on the merits), joint meeting next (framework to set at opening, how to return to facts when it gets personal, how to get agreement on 2 or 3 concrete ground rules), follow-up finally (how to verify the agreement holds without obvious spying).

Constraints: stay in the PM role; items requiring HR or line management are identified and escalated, not handled; neither person should leave the process designated as the culprit in front of the team. Indicate signals that require immediate escalation.

Help me course-correct a vendor who is slipping on [project name]. Vendor: [company and service]. Observed deviations: [dated facts: delays, poor quality, changed contact, unkept promises]. Contractual framework: [what the contract stipulates: deliverables, deadlines, potential penalties]. Dependency: [how replaceable this vendor is].

Build the gradation: first the correction meeting (factual file of gaps between commitment and reality, dated and sourced; meeting agenda demanding a dated recovery plan rather than excuses), then close monitoring (short milestones, explicit exit-from-crisis criteria, written minutes after every check), finally preparing the alternative if recovery fails (to be launched discreetly now if dependency is high).

Constraints: everything is formalized in writing after every verbal exchange, the file protects in case of dispute; stay factual and contractual, no threats that cannot be executed. Deliver: gap file table, meeting request email, meeting outline, and objective criteria that would trigger an exit.

Draft the RFP to consult vendors for [subject, e.g., site redesign, tool deployment, recurring service] for [company]. Need: [description of need and problem to solve]. Technical and organizational context: [existing setup, constraints]. Indicative budget: [range, or intentionally not shared]. Timeline: [deadlines].

Structure: company and context intro (half page), problem to solve and objectives phrased as expected outcomes (describe the need, not the solution, unless a real constraint is justified), scope and exclusions, non-negotiable constraints (technical, regulatory, calendar), expected deliverables, selection criteria with weighting, consultation process (Q&A, submission date, potential pitches), and mandatory response format for comparison.

Constraints: every requirement must be testable at delivery, otherwise rephrase; distinguish mandatory requirements from wishes, classifying everything as mandatory kills comparison. End with the 5 questions to ask during pitches that reveal which vendors truly understood the need.

Build the comparison grid for proposals received for [subject]. Proposals: [number of offers and summary of each: price, timeline, approach, highlights]. Criteria that matter to us: [priorities, e.g., meeting deadlines, support, total cost, vendor longevity]. Perceived signals: [impressions to verify, e.g., offer way below others, generic response].

Build the grid: criteria grouped by family (understanding of need, proposed approach, team actually assigned, total cost over time including what's not in the initial quote, verifiable comparable references, contractual terms), weighting justified by my priorities, scoring scale with a description per level to limit subjectivity.

Apply the grid to the described offers and flag: unexplained price variances (a very low offer often hides reduced scope, list questions to verify), resources presented in pitches that won't be on the project, recurring hidden costs. Deliver the filled comparison table, clarification questions to send per offer, and a 5-line reasoned recommendation.

Build the change management plan for [project, e.g., new tool deployment, process reorganization] at [company]. Impacted populations: [groups involved with headcount and what changes for each]. Expressed or suspected fears: [anticipated resistance]. Deployment schedule: [key dates]. Available means: [time, budget, potential champions].

For each population: what concretely changes in their daily life (gains AND losses, silenced losses are paid for later), the necessary support level (info, training, close assistance), and the key message phrased from their point of view.

Structure the plan over time: Before (announcement, network of internal champions chosen for credibility with peers not availability, training), During (reinforced assistance, organized feedback for pain points, visible and announced fixes for reported issues), After (measuring real usage rather than training rate, handling remaining pockets of resistance).

Constraints: no plan based on "communicating more" without saying what to whom; every action has an owner and a date. Deliver the plan in a table by population and the consolidated schedule.

Design the end-user training plan for the deployment of [tool or process] at [company]. Users: [profiles, headcounts, skill level, geographic distribution]. What each profile must know how to do: [tasks by profile]. Constraints: [team availability, budget, go-live deadline].

Build a setup by profile rather than a single training: for each, the 5 to 10 key actions to master drawn from real use cases (not an exhaustive tour of features), the appropriate format (short group session, tutorial, desk-side coaching), duration, and reference material to leave behind (one-page task sheets rather than a manual).

Schedule sessions as close to go-live as possible: training taken 6 weeks before usage is forgotten. Plan for catch-up sessions for absentees and local champions by site or team.

Constraints: measure success on real usage after go-live (ability to perform key actions, volume of support tickets) and not on participation rate. Deliver the plan in a table by profile and the prioritized list of materials to produce.

A major incident is affecting [project name]: [nature of incident, e.g., failed go-live, data loss, service outage, grave deviation discovered]. Observed impacts: [who is affected and how]. Resolution status: [what we know, what we don't know yet]. Audiences to inform: [management, internal teams, clients, partners].

Draft the communication sequence: the first message sent quickly, stating what we know, what we don't know, what we are doing, and when the next update will be (commit to an update time, not a resolution time we don't know), status updates at the announced rhythm even without news, and the resolution message with measures taken to prevent recurrence.

Tailor each message by audience: management wants impact and decisions to make, users want to know how to work in the meantime, clients want to know if they are affected and protected. Constraints: no speculation on cause until established, no blaming, no broken deadline promises: this is the credibility for everything that follows. Deliver ready-to-adapt messages and the rule of who talks to whom.

Help [team] at [company] draft their OKRs for [quarter]. Company priorities for the period: [priorities]. Team's recurring missions: [permanent activities]. Considered projects: [projects and ideas under discussion]. Headcount: [team size].

Produce 2 or 3 objectives max: each phrased as an inspiring but concrete state change (not a task list), explicitly linked to a company priority. For each objective, 2 to 4 Key Results (KRs): measurable with a starting value and a target value, measuring an outcome achieved and not an activity performed ("reduce processing time from X to Y" and not "deploy tool Z").

Constraints: daily operations do not become OKRs, they are managed separately; a KR for which we cannot say today how we will measure it is rephrased or abandoned; signal objectives the team doesn't control enough to commit to. Deliver the proposed OKRs, questions to resolve in a team workshop, and the tracking ritual: frequency, 15-minute format, and what to do when a KR slips.

Prepare the end-of-quarter OKR review for [team]. Past quarter OKRs: [objectives and KRs with attainment level]. Key events of the quarter: [context: unexpected events, priority changes, departures]. Review participants: [participants]. Duration: [duration].

Structure the review in 3 parts: honest scoring of each KR based on real numbers (an unmeasured result is an unachieved result, not "almost done"), variance analysis separating execution issues, poorly calibrated ambition, or external events (the response differs for each), decisions for next quarter (what we carry over, what we explicitly drop, what we recalibrate).

Constraints: the review is not a justification exercise, ban context slides and go straight to numbers; a 100% achieved objective in the first quarter questions ambition as much as a 20% one questions execution. Deliver: timed agenda, scoring grid, analysis questions per KR, and the summary message template to distribute after the review.

Prepare the post-mortem for [incident description] occurred on [date] on [project name]. Known timeline: [event sequence with times if available]. People involved: [actors]. Climate: [context, e.g., one person feels targeted, management is looking for someone to blame].

Structure the document and meeting: factual timeline collectively reconstructed (hour by hour, no interpretation), cause analysis going beyond individual error (a possible human error is a symptom: what allowed it to happen, what should have caught it before impact), what worked well in detection and reaction, and prevention actions.

Facilitation rules to set at opening: we seek how the system allowed the incident, not who made the error; whoever says "I made a mistake" helps everyone and must never regret it. Constraints: 5 actions max, each with an owner and deadline, prioritizing those that remove the possibility of error over those asking for more vigilance. Deliver the document template and meeting agenda.

Help me turn lessons learned accumulated by [team or company] into operational standards. Available material: [sources: retro minutes, project summaries, post-mortems, recurring feedback]. Current problem: [symptom, e.g., same errors repeat across projects, summaries are written then never read].

Process: group insights by theme and identify recurring ones (recurrence designates priority standards), transform each selected insight into an actionable rule phrased in one sentence with its trigger ("at every project start, we do X"), and define where these rules live to be seen at the right time: integrated into existing doc templates and checklists rather than a wisdom document no one opens.

Constraints: 10 rules total max, each rule has an owner who keeps it alive; plan the semi-annual review that deletes obsolete rules, a repository that only grows dies. Deliver: proposed rules ranked by usage moment, their integration support, and the announcement message to the team.

Prepare [project name] for an audit or quality review conducted by [auditor: internal audit, client, certifier, management] on [date]. Announced scope: [what will be examined]. Real project status: [known strengths and weaknesses, docs up to date or not]. Stakes: [what is at play: continued funding, client trust, certification].

Organize preparation: reference file to build (scoping, decisions, risk tracking, minutes, budget items) with a list of what is likely missing or obsolete to prioritize for update, questions the auditor will likely ask for this type of project, and for each known weakness the honest position to take: acknowledge it, show it is identified and managed, present the dated action plan.

Constraints: never doctor a document or backdate anything, an owned weakness with a credible plan passes better than a facade that cracks in interview; brief people who will be interviewed on facts, not talking points. Deliver: file checklist, likely questions with prepared answers, and the backward preparation schedule.