AI for project management: status reports, RAID logs, and updates that hold up

What AI changes for a project manager

A project manager's raw material is messy: a forty-minute steering call, a board of half-updated tickets, a vendor email that hedges on a date. The job is to turn that into five action items, one paragraph a sponsor will read, and a risk entry with a trigger and an owner. That conversion is where chat assistants earn their place.

What the assistant does not have is your project. It has not read the plan, it does not know how much surprise your sponsor tolerates, and it never heard the dependency your lead engineer mentioned on the way to lunch. It also writes smooth, confident prose whether the facts are good or bad, which is how a yellow project gets reported green.

So the method in this guide has two halves: give the assistant enough context to translate well, and keep the judgment calls yourself. The project managers role page has a 30-day plan; this guide is the working detail.

Set up once: the project brief

Every good output starts with the same input: a one-page brief you paste into every session or store once in a Claude Project, a custom GPT, or a Gemini Gem. It contains:

• The goal in one sentence, and what is explicitly out of scope
• Team, roles, and who decides what
• Milestones with dates, and the current status of each
• The top five risks and issues, with owners
• Stakeholders and what each cares about (the CFO reads for cost, the sponsor for the date)
• Your status definitions: what makes this project Yellow, what makes it Red
• A glossary of your acronyms and system names

Update it every Friday; a stale brief produces a stale report.

The status definitions are the line people skip. If your brief says "Yellow means any milestone has slipped more than five working days or any risk has become an issue without a response," the assistant can apply your rule to your notes. Without it, the assistant applies its own rule, which is generous.

Status reports

Decide the status color before you prompt. Then give the assistant your raw notes, last week's report, the milestones due this period, and the brief, and ask for a report that is honest about what moved and what did not.

You are a senior project manager drafting a weekly status report for [AUDIENCE]. Project brief: [PASTE BRIEF]. Last week's report: [PASTE LAST REPORT]. My raw notes for this week: [PASTE NOTES]. Milestones due this period: [PASTE MILESTONES]. I have decided the status is [GREEN, YELLOW, OR RED] because [ONE-SENTENCE REASON].

Write the report in this structure, under 250 words:
1. Status line: the color I gave you and my reason, stated plainly in the first sentence.
2. What changed since last week: only items that moved, with the old and new date or state.
3. What did not move that should have, and why, if the notes say.
4. Risks and issues: new ones, escalated ones, closed ones, with an owner for each.
5. Decisions needed from the reader, each with a date by which we need it.

Rules: use only my notes, my brief, and last week's report. Where a date or owner is missing, write NEEDS DATE or NEEDS OWNER. Do not soften bad news or add reassurance I did not provide. If my notes contradict the status I chose, tell me before writing.

The "what changed" section is why this beats refilling a template: sponsors need the delta and the ask, not the whole project restated.

Verify every date against the schedule and every percentage against the tracker before sending; models copy stale milestones forward without hesitation. Then ask: "What would make this report Yellow?" If any answer is already true, fix the color.

Meeting follow-ups

The general routine is in the AI meeting notes guide: record with consent, extract decisions and actions with quotes, verify owners and dates, send within the hour. Two additions for PMs.

First, map actions to your tracker. Paste the extracted action table and your current task list and ask: "For each action, tell me whether it is already a task in my tracker, a change to an existing task (new date, new owner, new scope), or a new task. Show the tracker ID where it exists."

Second, ask for the plan changes the meeting implied: "Reading this transcript against my milestones, list anything that suggests a date, dependency, or scope change, with the quote that suggests it." A sentence like "we'll need the new API before we can test that" is a dependency nobody wrote down.

Risk registers and RAID logs

A RAID log tracks Risks, Assumptions, Issues, and Dependencies in one place. AI helps in three ways: drafting entries from messy sources, challenging what you already have, and running a pre-mortem.

For drafting, paste a thread, transcript, or vendor email and ask for entries with every field filled or marked:

Act as a PMO analyst maintaining a RAID log. Source material: [PASTE THREAD, TRANSCRIPT, OR NOTES]. Project brief: [PASTE BRIEF].

From the source, draft RAID entries as a table with columns: Type (Risk, Assumption, Issue, or Dependency), Description, Trigger or indicator (what would tell us it is happening), Impact if it occurs, Proposed owner, Proposed response, Source quote.

Rules: an Issue is something that has already happened; a Risk is something that might. Do not rate likelihood; I will do that. Where the source does not name an owner, write NEEDS OWNER. Quote the exact words that led to each entry. If the source contains nothing that belongs in a RAID log, say so.

For challenging, paste the current register and ask for: risks that are already issues, entries with no trigger or response, entries with no owner, entries that have not changed in a month and may be stale, and up to five risks visible in the plan that the register does not list. Treat its additions as questions for your judgment; it does not know this vendor slips on every project, and likelihood and impact ratings stay yours.

For the pre-mortem, one prompt: "Assume it is [END DATE] and the project has failed. Write the three most plausible post-mortems, each in one paragraph, using only what you know from my brief and plan. For each, name the earliest warning sign we would have seen." Run it at kickoff and at every phase gate.

Schedule sanity checks

Export your schedule (task, duration, predecessors, resource, dates) and ask the assistant to read it the way a skeptical scheduler would.

You are a scheduling reviewer. Here is my project schedule as a table: [PASTE SCHEDULE EXPORT]. Working calendar: [DAYS PER WEEK, HOLIDAYS, KNOWN LEAVE]. Team: [NAMES OR ROLES AND AVAILABILITY].

Check for and list, with the task IDs involved:
1. Tasks with no predecessor or no successor, other than the first and last.
2. Any person assigned to overlapping tasks in the same week.
3. Tasks involving approvals, procurement, or external parties with less than [NUMBER] days of duration or no buffer after them.
4. Milestones with nothing feeding into them.
5. Durations that look optimistic given the task name, with your reason.

Do not change any duration or date. Do not estimate. Report what you find and ask me about anything ambiguous.

The assistant can spot a missing link; it cannot be trusted to add up a critical path, so recompute anything numeric in your scheduling tool. Never let it invent durations; a generic estimate in a real schedule is a commitment you did not make on purpose.

Stakeholder communications

One source, several audiences. Paste the finished status report and ask for three versions: five lines for the sponsor, leading with the decision needed; a fuller note for the team with the detail behind each change; and a formal update for the client or vendor with only what they need to know. Add: "Use only the facts in the report; do not add promises, dates, or reassurance."

Two habits for the hard messages. For bad news, instruct the assistant to state the slip in the first sentence; left alone it buries the slip under two paragraphs of context. For change requests, paste the original scope wording so the impact section is anchored in text, and supply the schedule and cost numbers yourself; the model must never estimate them.

Retrospectives

Collect inputs first (survey answers, notes, the chat thread) and strip names. Then ask the assistant to group them into themes with a count of separate comments behind each, propose a likely root cause per theme, separate one-off events from repeating patterns, and pick the two changes with the best effort-to-impact ratio. Share the themes, not the raw comments.

The larger win is across projects. Paste the last three retros and ask what repeats and what was promised as a fix and appears again. Patterns that survive three retrospectives are process problems, and those are the ones a PM can actually fix.

Worked example: a Monday morning on a slipping integration project

A PM runs a systems-integration project with a vendor, an internal data team, and a sponsor who reads only first sentences. She has Friday's vendor-call transcript, the tracker export, last week's status report, and her brief.

She starts with the transcript. The extraction prompt returns nine actions, two with NEEDS OWNER, and one plan change: the vendor said "the connector should be fine once your data team finishes the mapping," which nobody had logged as a dependency. She checks the timestamp; the words are right.

She pastes the vendor thread into the RAID prompt. It drafts a Dependency entry for the mapping work with a NEEDS OWNER flag, and a Risk that the vendor's "should be fine" has no test behind it. She adds the owner, rates the likelihood herself, and adds a response: a joint test on the mapped data before the connector goes anywhere.

The schedule check flags that user acceptance testing is scheduled to start three days before the data mapping ends. She had not seen it; the two tasks sat on different pages of the plan. She moves UAT and the end date slips a week.

Now the status report. She decides Yellow before prompting: a milestone slipped more than five days, per her own definition. The draft comes back with the slip in the first sentence and a decision request for the sponsor about whether to compress UAT. She rejects one line, "the team remains confident," because nobody said it. Three audience versions follow. The whole loop takes about ninety minutes instead of half a day, and the sponsor's reply asks about the UAT decision, which means the first sentence did its job.

What project managers should never delegate

• The status color. You decide; the assistant formats.
• Estimates, dates, and cost figures you will be held to. The model does not know your team's velocity or your vendor's history; its numbers are placeholders at best.
• Escalation decisions. Whether to raise a risk with the sponsor this week is judgment about people and politics.
• Scope negotiation and conversations about performance. Draft the email if you like; do not let the draft decide the position.
• Contract interpretation. What the SOW obliges the vendor to do is a question for the contract and, when it matters, for legal.
• The final send. Every date, name, and number gets a human check before it reaches a stakeholder. The fact-checking guide has the routine.

And one rule about inputs: contracts, vendor rates, client names, and personnel matters are often covered by NDAs or privacy obligations. Never paste confidential data into a consumer AI tool unless your organization has approved it. Use the enterprise tier your company licenses, or redact first.

There is also the quieter risk of trusting a tool because it is usually right, which the glossary calls automation bias. The cure is the verification habit: two minutes, every draft, every time.

Tools that fit

On Microsoft 365, Copilot is the practical default: Teams recaps, drafting in Word and Outlook, Excel help for the budget tracker, all under commercial data protection. ChatGPT and Claude with the brief stored in a project are strongest for heavier writing and analysis, and Gemini fits Google Workspace teams. Most task tools now include AI for summarizing boards and drafting updates; check what your plan includes before adding a subscription, and let one Zapier flow that posts overdue tasks to the project channel handle the repetitive admin first.

Next steps

• Start with the project managers role page for the 30-day plan, and see how product managers and operations managers use the same methods.
• Copy prompts from planning and productivity and meetings and summaries, or package the brief and prompts into a reusable assistant with how to build a custom GPT.
• Handle the budget tracker with AI for Excel and spreadsheets, and the steering deck with AI for presentations.
• Build the verification habit with how to fact-check AI output, and read the glossary entries on hallucination and human in the loop.