Claude in your reporting workflow
A project manager at a mid-size organisation connects Claude to their project management data. Within an hour, they have a dashboard showing story points, velocity trend, earned value, and blockers — formatted and ready for the steering group meeting tomorrow.
This is real. It works. It is one of the clearest productivity gains available to a PM today.
The question is not whether it is possible. It is who owns the accuracy of that dashboard before it reaches people who make decisions based on it.
What Claude produces well in reporting
Status aggregation. Claude is fast and reliable at pulling data from multiple sources into a coherent summary. If you feed it five team members' updates, it produces a structured team status without missing items. If you give it sprint data, it calculates and formats velocity without arithmetic errors.
Dashboard structure. A well-prompted Claude request produces a logically organised dashboard with the right sections for your audience — executive summary up top, detail below, exceptions flagged. It adapts structure to audience when you specify who is reading.
Trend narratives. Given multiple periods of data, Claude writes a clear narrative of the trend — "velocity has been declining for three weeks, with the main driver being unresolved dependencies in the infrastructure work." This takes a PM ten minutes to write and Claude produces it in seconds.
Blocker summaries. Given a list of blocked items with descriptions, Claude produces a clean summary of what is blocked, why, and what would unblock it — formatted for a steering group that does not want to read ticket details.
What Claude does not know
Claude does not know your project. It knows what you give it.
If the data you provide is incomplete, the report is incomplete — with no indication that anything is missing. If a team member forgot to update their tickets, Claude does not know. If a blocker was resolved verbally in a meeting but not updated in the system, Claude does not know. If the velocity looks slow because the team shifted approach — switching from estimates to no-estimates midway through a sprint — Claude does not know unless you told it.
This is not a limitation that will be fixed in the next version. It is structural. Claude works with the context it has. The PM carries context that is not in any system.
How MCP changes the data layer
When a PM connects Claude to their project management tool via MCP, the reporting workflow changes in a specific way: instead of pasting data into a conversation, Claude reads the current state of the system directly.
This matters for accuracy. A report generated from live data reflects what is actually in the system right now — not what was in it when you last exported a spreadsheet. For steering group meetings, that difference is significant.
For a practical introduction to MCP and how to set up the connection, see MCP Fundamentals Part 2. The technical setup requires connecting a project management MCP server to Claude Code. Once connected, Claude can query ticket status, pull sprint data, and generate the dashboard from the live system rather than from a paste.
The PM's job does not change. The data Claude works with is more current.
The verification checklist before a report reaches a stakeholder
Running this before any AI-assisted report goes to a steering group, a client, or senior leadership:
Is the data complete? Did every team member update their status? Are there known items that are not in the system? Spot-check two or three items against what you know to be true.
Does the velocity/progress number match your read of the sprint? If Claude says the sprint is on track and you have a nagging sense it is not, investigate. Your instinct is domain expertise. The number is arithmetic on the available data.
Are the blockers accurate? For each item Claude flags as blocked, confirm: is it still blocked? Is the blocker description current? Are there items that are effectively blocked but not flagged?
What is missing from the report that the steering group needs? Claude produces what the data shows. You know what the steering group needs to understand. If there is a gap — a risk that is real but not yet in any system, a decision that needs to be made, a context point that changes how the data should be read — add it.
Who is presenting this and can they defend every claim? A dashboard that goes to a steering group needs a person who can answer follow-up questions. That person should have read the report, not just forwarded it.
What this workflow actually looks like
A realistic example of the flow, with no tool names:
- PM opens their project management tool and verifies that the key items are current — updates any that are not.
- PM generates the Claude report using a prompt that specifies the audience, the timeframe, and what to surface.
- PM reads the output against their own knowledge of the sprint. Edits three items that are technically correct but contextually incomplete.
- PM adds a paragraph at the top — the interpretation: what this data means for the project trajectory and what decision the steering group needs to make.
- PM sends.
Step 4 is the step Claude cannot do. Step 4 is the PM's value.
What comes next
Part 3 covers document automation beyond reporting: meeting summaries, project briefs, proposals, and the specific documents where Claude's draft needs more than a light edit before it is ready.
Next in this series: Part 3 — Document automation without losing ownership