Playbook: Alex for Project Managers

Your reference for applying Alex to project planning, stakeholder communication, risk management, and delivery execution. Ready-to-run prompts — built around the hard realities of project work, not the methodology textbook.

What This Guide Is Not

This is not a habit formation guide (see Self-Study Guide for that). This is a domain use-case library — the specific things Alex can do in your project work, and how to do them well.

Where to Practice These Prompts

Every prompt in this guide works with any AI assistant — ChatGPT, Claude, GitHub Copilot, Gemini, or whatever tool you prefer. The prompts are the skill; the tool is just where you type them. Pick the one you’re comfortable with and start today.

For an integrated experience, the Alex VS Code extension (free) was purpose-built for this workshop. It understands project management context, lets you save effective prompts with /saveinsight, and brings your playbook and practice exercises into one workspace. VS Code is a free editor that takes minutes to set up, even if you’ve never used it before.

You don’t need a specific tool to benefit. You need the habit of reaching for AI when the work is genuinely hard — not just when it’s repetitive.

Core Principle for Project Managers

Project management is the discipline of managing uncertainty while maintaining the confidence of people who need certainty. The hardest thing is not the planning — it is holding both the authentic picture of risk and the stakeholders’ need for stability at the same time, without letting either collapse the other.

Alex is most valuable to project managers not as a scheduling tool, but as a thinking partner for the ambiguous, politically loaded, and hard-to-structure problems that fill the real job: the conversations that need framing, the risks that need articulating, the plans that need defending to someone who does not want to hear the honest answer.

The Seven Use Cases

1. Project Planning and Scope Definition

The project manager’s scope challenge: Scope creep does not usually arrive as a dramatic request. It arrives as a series of small, individually reasonable additions — each one approved in the moment, with no one tracking the cumulative picture. By the time scope is visibly broken, it has been broken for weeks. The discipline of scope definition is the discipline of saying what the project is not, as precisely as what it is.

Prompt pattern:

I am planning [project name and one-sentence description].
Stakeholders: [list with decision-making authority].
Constraints: [budget, timeline, team, dependencies].
Business goal this project serves: [what success looks like for the sponsor, not the PM].

Generate:
1. Project scope statement (what is in, what is explicitly out)
2. Success criteria (measurable, not vague)
3. Key assumptions I need to validate before kickoff
4. The five most likely scope-creep vectors for this type of project
5. The question the sponsor hasn't asked yet that I should raise proactively

Follow-up prompts:

A stakeholder has just requested [specific addition]. Draft my response that acknowledges the value, explains the impact on scope, and offers a structured choice.

Review this scope statement and flag anywhere the boundaries are soft enough to become a negotiation later.

What is the most likely scope addition that will feel urgent but is not actually necessary for the core deliverable?

Try this now: You are kicking off a 6-month ERP migration for a 200-person manufacturing company. The sponsor wants it done in 4 months, two key SMEs are going on parental leave in month 3, and the vendor assumes a dedicated 8-person team — you have 3. Paste those constraints into the scope definition prompt and ask for a realistic scope statement that names the tradeoffs explicitly. The conversation with the sponsor will go better when you have the tradeoffs written down.

2. Risk Register Development

The project manager’s risk challenge: Risk registers become shelfware because they are built as a compliance exercise rather than a thinking exercise. A risk register that anyone will actually use must be specific to this project, honest about probability and impact rather than professionally optimistic, and connected to real owners with real mitigation actions.

Prompt pattern:

I need a risk register for [project description].
Project type: [software build / process change / vendor integration / organizational restructuring / other].
Key dependencies: [external teams, third-party systems, regulatory approvals, other projects].
My biggest concern: [the thing that keeps me up at night].

Generate a risk register with:
- Risk description (specific, not generic — "the API integration may fail" not "technical risk")
- Probability (high / medium / low) with rationale
- Impact if it occurs (on scope, timeline, budget, relationships)
- Early warning indicator (what I should watch for)
- Mitigation action and owner
- Contingency if mitigation fails

Follow-up prompts:

What risks am I most likely not thinking about for a project of this type?

This risk has materialized: [describe]. Build a rapid response plan.

Translate the top five risks into executive language for a steering committee update.

3. Stakeholder Communication

The project manager’s communication challenge: Project communications fail not because the information is wrong but because it is calibrated for the wrong audience. The executive wants the bottom line first and does not want to read a paragraph to find it. The technical team wants the detail. The impacted end user wants to know what it means for them. Writing one update for all audiences produces something that satisfies none of them.

Prompt pattern:

I need to communicate [project update / milestone / decision / problem] to [audience: executive sponsor / steering committee / project team / end users / impacted department].
Current status: [honest one-sentence summary].
Key message: [what I need them to understand or decide].
Context they need: [what they know vs. what they are missing].
Tone: [reassuring / urgent / matter-of-fact / requesting a decision].

Follow-up prompts:

The project is in trouble and I need to communicate the delay honestly without destroying stakeholder confidence. Help me draft this.

I need to deliver bad news to the executive sponsor who has a low tolerance for surprises. Draft a conversation opening, not a written note.

Review this project status update for anything that could be misread as more positive than the situation warrants.

4. Meeting Facilitation

The project manager’s meeting challenge: Most project meetings produce conversation without decisions. The role of meeting facilitation is to create the conditions where decisions can be made — which requires more than good agenda management. It requires knowing who in the room is blocking, what they actually need to move forward, and how to surface the real disagreement without letting it derail the session.

Prompt pattern:

I am facilitating [meeting type: kickoff / design review / go/no-go / retrospective / stakeholder alignment] for [project].
Goal of the meeting: [specific decision or outcome, not "alignment"].
Participants: [list with context about any tensions or differing agendas].
Known blockages: [what is unresolved going in that could derail the session].
Time available: [duration].

Generate:
1. Agenda with time allocations
2. Opening frame that sets the right tone
3. Key questions to surface the real disagreement early
4. Decision-forcing question for the moment the conversation stalls
5. Closing sequence that captures decisions and assigns owners

Follow-up prompts:

Two stakeholders have opposing positions on [issue] and neither will yield. Generate three reframe options that let the group move forward.

The retrospective is going to surface difficult feedback about [person or decision]. How do I facilitate that productively without it becoming a blame session?

Design a decision-forcing question I can use when the meeting stalls — something that moves the group from discussion to commitment.

5. Change Management and Project Recovery

The project manager’s recovery challenge: When a project is in trouble, the instinct is to replan. But replanning without diagnosing is paper over glass — the new plan inherits the same structural problems that broke the first one. Project recovery requires ruthless diagnosis of what actually happened and honest answers about what needs to change that is not just the schedule.

Prompt pattern:

My project is in trouble: [describe current state — timeline, budget, team, stakeholder confidence].
What I believe went wrong: [your diagnosis].
What I need to do by [date] to recover: [your current recovery thinking].
Constraints on recovery: [what I cannot change — headcount, deadline, budget, scope].

Help me:
1. Stress-test my diagnosis — what am I missing?
2. Build a recovery plan that is credible, not optimistic
3. Draft the communication to the sponsor that is honest without catastrophizing
4. Identify the one or two structural changes required vs. just replanning

Follow-up prompts:

I need to have the "we're in trouble" conversation with the sponsor this afternoon. Help me prepare: what to say, what not to say, and what decision to ask for.

The team is demoralized from the delays. What do I say to restore momentum without gaslighting them about the situation?

What is the one structural change in this project that would prevent the same failure mode from recurring — beyond just adjusting the timeline?

6. Vendor and Dependency Management

The project manager’s dependency challenge: The most common way projects slip is not internal failure — it is external dependencies that are not tracked with the same rigor as internal tasks. Vendors over-promise in sales mode and under-deliver in delivery mode. Other internal teams treat your project as lower priority than their own work. Managing what you cannot directly control is one of the most important and least taught aspects of project management.

When to use: Projects with significant external vendor relationships, cross-functional internal dependencies, or third-party integration requirements.

Prompt pattern:

I have [number] external dependencies on this project:
[List each: what they deliver, when I need it, who owns it, my current confidence level, and the last time I verified it].

Help me:
1. Identify which dependencies are most likely to fail silently (no warning until it is too late)
2. Build an escalation strategy for each at-risk dependency
3. Draft a communication to [vendor / internal team] that creates urgency without damaging the relationship
4. Define my contingency for each scenario where the dependency does not deliver

Follow-up prompts:

The vendor is going to miss the milestone and is not telling me directly. I can see it in the signals. Draft the conversation that gets the truth out of them.

I have two internal teams I depend on who keep deprioritizing my project. What is my escalation path and how do I frame it without burning bridges?

Vendor performance has been unacceptable. Help me draft a formal performance letter that is firm, documented, and does not get our legal team angry at me before I send it.

7. Resource and Capacity Planning

The project manager’s capacity challenge: Resource plans are built on best-case assumptions: everyone is available when you need them, no one has competing priorities, and skill sets are exactly matched to the work. Reality is the opposite. The project manager who builds credible capacity plans is the one who has honest conversations about availability before they become crises, and who knows which of their resources are actually over-committed.

When to use: Project kickoff planning, mid-project replanning, arguing for additional resources, or identifying bottlenecks before they materialize.

Prompt pattern:

I am planning resource needs for [project] across [timeframe].
Team: [list members with roles and allocation percentage to this project vs. other work].
Key skills needed: [skills required for each phase, with timing].
Known capacity constraints: [vacations, competing projects, skill gaps].

Help me:
1. Identify the capacity bottlenecks hidden in this plan
2. Flag the phases where I am at highest risk of under-resourcing
3. Build the case for [additional headcount / contractor support / scope adjustment] in language a sponsor will accept
4. Draft the capacity conversation I need to have with [resource manager / individual contributor] before the plan solidifies

Follow-up prompts:

A critical resource has just been pulled to a higher-priority project mid-delivery. Build my rapid response options.

I need to request two additional resources from the team manager who has told me the team is already at capacity. Help me build the business case.

Build a one-page resource summary I can show to the steering committee that makes the capacity risk visible without triggering panic.

What Great Looks Like

After consistent use, you should notice:

• Project briefs and charters are sharper and the stakeholder alignment is easier because expectations are clearer
• Risk registers are actually consulted — because they contain real risks with real owners, not placeholder language
• Stakeholder communications are calibrated by audience instead of one-size-fits-all updates
• You are having the hard conversations earlier — before they become crises
• Vendor and dependency management is proactive rather than reactive

The project managers who will be most effective in the next phase of their careers are not the ones who can produce plans faster with AI. They are the ones with clearer thinking about risk, communication, and organizational dynamics — and AI is most powerful as a thinking discipline, not a document factory.

Your AI toolkit: These prompts work in ChatGPT, Claude, Copilot, Gemini — and in the Alex VS Code extension, which was designed around them. Start with whatever you have. The skill transfers across all of them.

Your First Week Back: Practice Plan

Month 2–3: Advanced Applications

Track Your Growth

Stakeholder Map Reference

/saveinsight title="Project [name] stakeholder map" insight="[Stakeholder, role, decision authority, current concern, preferred communication style]" tags="stakeholders,project-management"

Lessons Learned Synthesis

After each project close, capture what you learned:

Project [name] retrospective: The decisions that made the project succeed were [list]. The decisions we will never repeat are [list]. The risk that materialized that was predictable in hindsight: [describe]. What to do next time: [specific change in approach].

Continue your practice: Self-Study Guide — the 30/60/90-day habit guide.