Before you automate status reporting, check whether the underlying system captures dependencies, blockers, ownership and workflow reality in a form the model can actually interrogate.
A project board can contain every task and still be a poor source for AI. That sounds counterintuitive because most AI project workflows start from exactly there. Export the tasks. Add the sprint notes. Ask the model to summarize what changed, identify risks, write the status report and tell you whether the project is on track.
The output can look impressive. The problem is that AI can only interrogate the structure you captured. If the real delivery system depends on relationships the tool does not represent well, the model inherits the same blind spots as the team. It may produce a cleaner summary of an incomplete operating picture.
The missing layer is usually not another task
Delivery depends on relationships. A task may exist, but the important question is often somewhere around it. What does it depend on? Who is blocking it? Which team is waiting? Which workflow state is it actually in? What downstream commitment moves if this slips? Who owns the intervention?
If those relationships live in meetings, messages, comments and people's memory, the model has weak evidence for them. That is not an AI limitation in the usual sense. It is an information-architecture problem. The project has not captured the operating model in a form the model can reliably use.
Better prompts do not fix weak structure
Teams often respond to weak AI output by improving the prompt. Sometimes that helps. But there is a point where prompt engineering is solving the wrong problem. If the system contains only a task title, assignee and status, there is no prompt that can reliably reconstruct the delivery relationships that were never captured. That includes unstated dependency chains, hidden handoff delays, ambiguous blocker ownership, undocumented workflow states and decisions that live outside the board.
The model may guess. That is precisely what you do not want in project reporting. A plausible inference is not the same thing as delivery evidence.
The diagnostic: can the system answer the questions before AI arrives?
Before adding an AI reporting layer, I would test the project system itself. Can it answer these questions without relying on someone's memory? Which work is blocked right now? What is each blocked item waiting for? Who owns the unblock? Which dependencies threaten the current sprint or milestone? Which workflow transitions show repeated rework? Which cross-functional handoffs are ageing? Which issues are unresolved after the sprint closes?
If the answer requires manual reconstruction, AI will mostly automate that reconstruction rather than improve the operating model. That is useful up to a point. It is not the same thing as stronger project control.
The exit: diagnose the structure before choosing the AI workflow
This is the part I would automate first. Not the status report. The diagnostic. Take your current project-management setup and ask a model to identify which delivery relationships the system captures explicitly, which ones appear only indirectly, and which ones are missing from the evidence altogether. The output gives you a structured way to decide whether you have an AI problem, a tooling problem, or a process-design problem.
The prompt
Tool: Claude or ChatGPT
Takes: ~10 minutes, plus a human review
Output: A project-information-structure diagnostic
Prompt:
You are reviewing the information structure of an active
software-delivery project.
I will give you exports or screenshots/text from the
project-management system, plus a short description of
the team's delivery process. Do not recommend a new tool yet. Build a diagnostic table with these rows:
- task ownership
- sprint / iteration membership
- workflow state
- blockers
- dependencies
- cross-functional handoffs
- decisions
- risks / issues
- defects / rework
- milestone or release impact
For each row, classify the current project system as: EXPLICIT
The relationship is directly represented in structured
project data. INDIRECT
The relationship appears only in comments, naming
conventions, notes, or another weak proxy. MISSING
The relationship is not visible in the supplied evidence. For every INDIRECT or MISSING item, answer:
1. What management question becomes difficult to answer?
2. What manual coordination is probably compensating?
3. What reporting or AI conclusion would become unsafe
to make from the current data?
4. What minimum additional structure would make the
relationship explicit?
Then finish with three sections: A. SAFE TO AUTOMATE
Project questions the current data can support reliably. B. NEEDS HUMAN VERIFICATION
Questions where the evidence is partial or indirect. C. STRUCTURAL GAPS
Questions the project system cannot currently support
without collecting better evidence. Do not infer missing dependencies, owners, blockers or
decisions. Mark them MISSING instead. Project-system evidence:
[PASTE] Delivery-process description:
[PASTE]
Watch-for: The model will try to be helpful by inferring relationships that are only weakly suggested. Do not let it. The value of this diagnostic is the distinction between explicit evidence, indirect evidence and missing structure. If the model fills the gaps, it destroys the signal you are trying to measure.
What this changes about AI project reporting
Once the operating structure is explicit, AI gets much more useful. Instead of asking:
Summarize the sprint.
you can ask:
Which blocked items threaten the sprint commitment?
Instead of:
Write the status report.
you can ask:
Which dependencies have unresolved owners or required-by dates?
Instead of:
Are we on track?
you can ask:
What evidence supports the current RAG status, and what information is missing?
The model is no longer decorating activity. It is interrogating a delivery system. That is a much stronger use of AI.
The operating sequence I trust more
The sequence I would use is: First: represent the project. Capture the relationships that determine delivery. Second: inspect the evidence. Make sure ownership, blockers, dependencies, workflow and issues are visible enough to reason about. Third: add AI.
Use it for synthesis, contradiction detection, weak-signal analysis and management reporting. If you reverse that sequence, you can end up with very polished output resting on weak project data. AI should make uncertainty easier to see. It should not make incomplete evidence look more authoritative.
This article was published in AI in Plain English on Medium. Read the original on Medium →