Artificial Idea | AI careers · practical prompts · no hype Thursday, November 20, 2025 · Issue #32 · Prompt Tutorial
The PM toolkit
5 prompts every project manager needs to keep teams aligned without endless meetings
Meetings are not the problem. Unclear thinking before meetings is the problem. These five prompts fix the thinking. The meetings fix themselves.
Issue #31 made the case that the inflection point in AI capability development arrives at eight to twelve weeks of deliberate, focused practice on a single application, and that the professionals who reach it are those who iterate consistently rather than accept first outputs and those who reflect regularly on what is working. This issue is the application of that principle to one of the most time-intensive professional functions in any organisation: project management.
Project management sits in an unusual position in the AI transition. It is one of the functions where AI tool adoption has been fastest, with platforms like Jira, Asana, Monday, and Notion embedding AI-assisted features directly into the workflows that project managers use daily. It is also one of the functions where the limits of AI are most consequential, because the core value of a project manager is not the production of status reports, the scheduling of meetings, or the tracking of tasks. It is the ability to see around corners: to identify the risks, dependencies, and human dynamics that will determine whether a project succeeds before they have fully manifested.
That forward-looking judgment cannot be automated. It can, however, be significantly sharpened by the right prompts applied at the right moments in the project lifecycle. These five prompts are designed for those moments.
Prompt 1: The project charter builder
The problem it solves: establishing the clarity about scope, objectives, constraints, and success criteria at the beginning of a project that prevents the majority of the misalignments, scope creep, and delivery failures that occur later.
Most project charters fail not because the template is wrong but because the thinking that should precede the template is skipped. The pressure to start delivering is felt immediately. The pressure to ensure everyone understands what is being delivered, why, and by what standard of success it will be evaluated is felt only later, when the absence of that clarity has produced consequences that a better charter would have prevented.
You are a senior programme manager helping
me build a project charter rigorous enough
to prevent the misalignments that most
commonly derail projects at the
execution stage.
Project context: [describe the project:
what it is, why it is being done,
who has requested it, who will be
affected by it, and what the
organisational context is]
What I know about stakeholder expectations:
[describe what different stakeholders
have said they want, including any
apparent tensions between their expectations]
Constraints I am aware of:
[budget, timeline, resource,
technical, or organisational constraints]
Please build a project charter covering:
1. Objective statement: one sentence
stating what this project will
achieve, specific enough that
everyone will agree on whether
it has been achieved at the end
2. Scope definition: what is
explicitly included and what
is explicitly excluded,
with enough specificity that
scope creep requests can be
evaluated against a clear baseline
3. Success criteria: three to five
measurable indicators that will
determine whether the project
has succeeded, agreed before
work begins rather than
defined retrospectively
4. Assumptions: the beliefs the
project plan depends on that
have not been confirmed,
each stated specifically enough
that it can be validated or
invalidated during the project
5. Risks: the three most significant
risks to successful delivery,
each with a specific mitigation
and an owner
Flag any area where the information
I have provided is insufficient
to build a rigorous charter,
because those gaps are the
misalignments most likely to
surface as problems later.
The assumptions section is the component most commonly omitted from project charters and most responsible for late-project surprises. Every project plan rests on a set of beliefs about the environment, the stakeholders, the technology, and the organisation that have not been confirmed. Listing them explicitly at the outset creates a mechanism for tracking which assumptions have been validated and which have been invalidated as the project progresses, which is the early warning system that most projects are missing.
Prompt 2: The stakeholder alignment mapper
The problem it solves: understanding the human landscape of a project before the misalignments in that landscape produce visible problems, which in most projects they do, and almost always at the worst possible moment.
You are an organisational dynamics
specialist helping me map the
stakeholder landscape of a project
I am managing.
The project: [brief description]
The stakeholders involved:
[list everyone with a stake in
the project: those whose support
is needed, those who will be
affected by the outcome,
those with formal authority
over decisions, and those
with informal influence over
how the project is perceived]
What I know about each stakeholder's
position: [describe each person's
current level of support,
their primary concern,
and any known tensions
between them]
Please:
1. Identify the stakeholder whose
active support is most critical
to success and the stakeholder
whose active opposition is
most likely to derail the project,
with your reasoning for each
2. Identify any misalignment between
stakeholders that is not yet
visible as a conflict but is
likely to surface as one
at a specific stage of the project
3. Propose a stakeholder engagement
sequence: the order in which
to have alignment conversations
that maximises the likelihood
of building momentum rather
than triggering resistance
4. Identify the stakeholder most
likely to change their position
as the project progresses,
in either direction, and what
would most likely trigger that change
5. Tell me the stakeholder conversation
I am most likely to avoid having
because it is uncomfortable,
and why avoiding it is the
highest-risk decision available to me
Be specific. Generic stakeholder
maps that describe everyone as
broadly supportive are not useful.
The value is in the tensions
and the risks.
Point five is the one that produces the most resistance and the most value. Every project manager has a stakeholder conversation they are deferring. The deferral is always rationalisable. The consequences of the deferral are almost always more costly than the conversation itself would have been. Making the deferral explicit and naming the cost of it is the intervention that most reliably changes the behaviour.
Prompt 3: The risk anticipator
The problem it solves: identifying the risks most likely to affect project delivery before they materialise, with enough specificity that mitigation is possible rather than just acknowledgment.
Most project risk registers are documents of record rather than documents of action. They list risks in generic categories, assign probability and impact scores that reflect no particular analytical rigour, and produce mitigation plans that are vague enough to be unfalsifiable. They satisfy the process requirement for a risk register without serving the actual function a risk register is meant to serve, which is changing the probability of things going wrong.
You are a project risk specialist
with a track record of identifying
the specific risks that generic
risk frameworks miss.
Project details: [description,
timeline, team composition,
technology involved, and
organisational context]
What has already gone wrong
or shown early warning signs:
[honest description of any
current concerns, delays,
or tensions, however minor]
Please:
1. Identify the five most significant
risks to this project's success,
ranked by their combination of
probability and impact,
each described with enough
specificity that someone reading
the risk register can recognise
the risk if it begins to materialise
2. For each risk, identify the
earliest observable signal
that the risk is beginning
to materialise, the thing
that will be true before
the risk becomes a problem,
and that creates a window
for intervention
3. For the two highest-priority risks,
propose a mitigation that is
specific enough to assign to
an owner and evaluate for effectiveness
4. Identify the risk that is
currently being underweighted
by the project team,
the one that feels manageable
but has a realistic scenario
in which it becomes project-threatening
5. Identify any dependency between
risks: scenarios in which
one risk materialising
significantly increases
the probability of another
Generic risk categories such as
resource risk or technical risk
are not useful without the
specific mechanism.
Every risk should be stated
as a specific scenario
that could actually occur.
The instruction to identify the earliest observable signal for each risk is the component that turns a risk register from a compliance document into an operational tool. A risk without an early warning indicator is a risk you can only respond to after it has become a problem. A risk with a specific early warning indicator is one you can monitor and intervene before it reaches the threshold at which intervention becomes crisis management.
Prompt 4: The team health diagnostician
The problem it solves: identifying the human dynamics within a project team that are most likely to affect delivery, before those dynamics produce the interpersonal conflicts, disengagement, and coordination failures that derail projects from the inside.
You are an organisational psychologist
helping me diagnose the health of
a project team I am managing.
Team composition: [describe the team:
their roles, their working relationships
with each other, how long they have
worked together, and any known
tensions or history]
Current project context:
[timeline pressure, complexity,
any recent changes to scope
or personnel, and the team's
current workload]
Signals I have observed:
[describe any behaviours,
communication patterns,
or incidents that have
caught your attention,
however minor they seem]
Please:
1. Assess the team health indicators
visible in what I have described,
identifying the strongest signals
and what they suggest about
the underlying team dynamics
2. Identify the dynamic most likely
to affect delivery if it is
not addressed, and the earliest
point in the project timeline
at which it is likely to surface
as a visible problem
3. Identify the team member whose
engagement and contribution
is most critical to project success
and whose retention risk
is highest based on what I have described
4. Propose one intervention for
the most significant dynamic
that a project manager can
implement without overstepping
into HR or management territory,
and one that requires escalation
to be effective
5. Tell me what I am probably
not seeing about my team
that I should be,
given the signals I have described
and the common blind spots
of project managers in
this type of situation
Be honest about the limitations
of this diagnosis given the
information available.
Overconfident team health
assessments based on limited
observation produce interventions
that address the wrong problem.
The final instruction, to be honest about the limitations of the diagnosis, is the constraint that keeps this prompt grounded in what it can actually produce. Team dynamics are complex and the information available to a project manager is always incomplete. A prompt that produces confident diagnoses from limited observation is worse than one that produces tentative hypotheses with explicit uncertainty, because the confident diagnoses lead to interventions calibrated to the wrong problem.
Prompt 5: The retrospective facilitator
The problem it solves: running a project retrospective that produces genuine learning rather than a catalogue of what went well and what could be improved that is read once and filed without changing anything about how the next project is run.
Most retrospectives fail because they are structured to produce consensus rather than insight. The social dynamics of a team debriefing together produce pressure toward positive framing, diplomatic language, and conclusions that nobody objects to. The conclusions that nobody objects to are rarely the ones that would change anything. The ones that would change something are usually the ones that someone in the room is uncomfortable saying directly.
You are a skilled retrospective facilitator
helping me design and run a project
retrospective that produces genuine
learning rather than a polite review.
The project: [brief description
of what was delivered, how long
it took, and how it ended
relative to the original plan]
What I know went well and why:
[honest assessment]
What I know went badly and why:
[honest assessment, including
anything that is uncomfortable
to acknowledge]
Team dynamics: [brief description
of the team and any sensitivities
relevant to the retrospective]
Please:
1. Design a retrospective agenda
that creates enough psychological
safety for honest reflection
while maintaining enough
structure to produce actionable outputs
2. Identify the three questions
most likely to surface the
insights that would change
how the next project is run,
and explain why each question
is more likely to produce
genuine insight than the
standard retrospective questions
3. Identify the topic most likely
to be avoided in the room
despite being the most important
one to address, and propose
a specific facilitation technique
for surfacing it without
creating defensiveness
4. Define what a successful
retrospective output looks like
for this specific project:
not a list of action items
but the specific change in
behaviour or process that
would indicate the retrospective
produced genuine learning
5. Write the opening statement
for the retrospective that
sets the tone for honest
reflection rather than
performance review
Constraint: the retrospective
design should be appropriate
for the specific team dynamics
I have described, not a
generic agile retrospective
template applied without
contextual adaptation.
Point four, defining what a successful retrospective output looks like before the retrospective begins, is the intervention most likely to change whether the retrospective produces anything useful. Retrospectives that define success as a completed list of action items consistently produce action items that are not acted on. Retrospectives that define success as a specific change in how the next project is run are held accountable to something measurable. The accountability changes the conversation.
The thread connecting these five prompts
Each of the five prompts above addresses a moment in the project lifecycle where the quality of the thinking going into the process determines the quality of the outcome coming out of it. The charter thinking determines the quality of the scope. The stakeholder thinking determines the quality of the alignment. The risk thinking determines the quality of the mitigation. The team health thinking determines the quality of the intervention. The retrospective thinking determines the quality of the learning.
AI does not manage projects. It sharpens the thinking of the professional who does. The project manager who uses these prompts is not outsourcing their judgment. They are subjecting their judgment to more rigorous challenge before acting on it, which is the thing that separates project managers whose projects succeed from those whose projects fail at a rate that has nothing to do with the tools available to them.
The tools have always been available. The thinking is what determines the outcome. These prompts make the thinking more rigorous. The outcome follows from there.
Monday we are beginning the third phase of this newsletter with a piece that has been building since Issue #1: a direct examination of the salary premium data, what it shows about where compensation is growing and where it is not, and what the professionals at the top of the premium curve are doing differently from those at the bottom of it.
The data is sharper than most compensation reporting suggests, and the gap it reveals is large enough that understanding it changes the calculation about where to invest professional development time for almost everyone reading this.
— The Artificial Idea team
