AI in Project Management — Where It Helps and Where It Doesn't

The most common question about AI in project management is: which tool should I use? It is the wrong one. Two project managers using the same tool arrive at completely different outcomes, and the difference lies not in the tool but in the task they hand it.

AI does not help equally everywhere in a project. It helps a great deal with one kind of work — and not at all with another, in a way you cannot tell from the output. This overview sorts both cases and names the criterion that separates one from the other, before you invest time or trust.

Where AI genuinely takes work off your hands

Structure and planning. Give it a project description and you get a draft work breakdown structure in a single pass. More valuable than the draft, though, is the reverse direction: having your own finished plan reviewed for what typically goes missing in projects of this kind.

Stakeholders and communication. Which roles get overlooked? How does a stated position translate into an underlying interest? Both are matters of phrasing — and both work without a single name, which is no small point here.

Requirements. Rewriting user stories, adding acceptance criteria, standardising wording. Routine work that follows a clear pattern.

Risks. Not the assessing — the gathering. The question "which risks typically arise in projects of this kind that nobody thinks of at kickoff" yields useful additions to an existing list.

Reports and status updates. Bullet points become readable prose. The time saved is real, the risk is low — provided the bullet points are sound.

Have a look. The account is free.

The pattern: wherever the volume is the problem rather than the judgement, a language model takes work off your hands. Rephrasing, sorting, comparing, supplementing — activities where the result can be checked against something you already know, and where an error shows up the moment you look.

Where it reliably gets things wrong

With anything that requires context nobody has written down. Who in the organisation actually decides, which department will not work with which other, why a particular approach failed last time — none of this appears in the documents, and a model cannot know it. It fills the gap anyway, and does so plausibly.

With decisions that carry accountability. A prioritisation, an escalation, a personnel question. A model will produce an answer, and the answer is often sensible — but the responsibility for it cannot be handed off, so the time saved is only an illusion.

With completeness. This is the costliest case. The output looks complete because it is symmetrical: every level has three to five points, all tidy. But symmetry is no proof of completeness. Anyone producing a work breakdown structure is bound by the 100% rule: the subordinate elements of a level must represent the content of the parent element fully and without overlap — no more and no less. Whether an AI draft satisfies this rule depends on the actual scope of the project, which the model does not know. A neatly symmetrical breakdown can miss the 100% rule entirely without the tree betraying it. Real projects are asymmetrical anyway.

All three cases share one feature: they cannot be spotted from the output. A wrong work breakdown structure looks like a right one. This is precisely why AI in a project is a tool for someone who can judge the result — and not one that replaces that ability.

The pattern behind both

There is one question language models are reliably strong at, and one they are reliably weak at.

Strong: "What's missing here?" Models have seen a great many examples and recognise what usually appears in comparable cases and is absent from your draft.

Weak: "What's correct here?" That presupposes knowledge of your specific case, which they do not have.

Anyone who keeps these two questions apart will get most decisions about where to use AI right without having to think about individual tools at all. The choice between providers is then secondary — it changes the quality of the phrasing, not the boundary between volume and judgement.

AI across the project lifecycle

The split between volume and judgement holds in every phase of a project; only the volume work looks different each time. The phases here are a common simplification (initiation and definition, planning, monitoring and control, closure), with execution folded into monitoring and control. Some tasks come up a second time, now ordered by when they arise.

Initiation and definition. AI drafts the project charter from notes and checks the list of roles for anyone missing. What stays with you: the objective, the scope, and who actually makes the decisions. Further reading: stakeholder analysis, episode 06 of the series.

Planning. AI produces a first draft of the work breakdown structure, collects risks and turns requirements into user stories. What stays with you: whether the plan meets the 100% rule, how much a risk weighs, which estimate and which date apply, and what comes first. Further reading: work breakdown structure, episodes 02, 03 and 05.

Monitoring and control. AI turns bullet points into a status report, prepares metrics for senior management, turns minutes into actions and sets scenarios side by side. What stays with you: the RAG status, the escalation, and which scenario you stand behind in front of the steering committee. Further reading: episodes 01, 04, 07 and 08.

Closure. AI condenses the notes from a retrospective into lessons learned. What stays with you: what actually changes on the next project. Further reading: episode 10.

The episodes belong to the free series “KI im Projektalltag”, recorded in German.

What stays with you changes character from phase to phase. A mistake made while defining the project carries through everything built on it and surfaces late. During monitoring and control it surfaces at once, but by then it sits in a report to senior management. That is why the check in four questions belongs at both points, not just at the end.

Which kind of AI tool for what

Asking which tool is best is still the wrong question. Distinguishing three kinds of tool is worth it all the same, because they know very different amounts about your project.

General-purpose assistants such as Claude or ChatGPT know about your project only what you give them, unless you connect them to your files or calendar. That is a limitation and a safeguard at once: you decide on every piece of context, and so on what stays out. Their strength is volume work across documents: drafting, comparing, rewording.

AI features inside work software, in Jira, Asana or Microsoft 365 for example, mainly know what is already stored there: tasks, dates, comments, documents. They save you the copying, but they can only summarise what has been filed somewhere. Whatever never made it into a ticket or a set of minutes is missing from the summary as well.

Agents that carry out several steps on their own only pay off once a task recurs regularly and its result can be checked. Setting them up, monitoring them and maintaining them all take time, and that cost is ongoing, not a one-off.

Which kind fits is decided less by features than by data: where the input ends up, who processes it, and whether there is a contract covering that.

What may go in and what may not

Two boundaries that are routinely overlooked in day-to-day project work.

Personal data. A stakeholder analysis contains names, functions and assessments of identifiable people. Entering these requires two things: a legal basis under Art. 6 GDPR and — where the provider acts as a processor — a data processing agreement under Art. 28 GDPR. If either is missing, the input is unlawful. The workable division is: roles yes, people no.

AI literacy. Since 2 February 2025, Article 4 of the EU AI Act has obliged providers and deployers to ensure a sufficient level of AI literacy among the people who use such systems on their behalf. This means judging a tool's results, not just operating it — that is, precisely the ability without which the three failure cases above go unnoticed.

How to begin

1. Choose a task where volume is the problem, not judgement. Rephrasing, gathering, comparing — not deciding.
2. Check the result against something you already have. Start with a task you have already done, so you know the right answer. Only then do you notice where the model goes wrong.
3. Use the reverse direction. Don't have it produce; have it review your own work. This is the underrated part and usually the more valuable one.
4. Write down what does not go in. A single page stating which documents are off-limits prevents more trouble than any choice of tool.

The check in four questions

Before any use in a project:

• Is this a question of volume or of judgement?
• Would I be able to tell if the result were wrong?
• Does it contain personal data?
• Is a named person accountable for the result?

Four clean answers do not mean the use will succeed. They mean an error will be noticed before it becomes expensive.

The deep dives

• Creating a work breakdown structure — what a language model takes off your plate
• Stakeholder analysis — why the list can be complete and the analysis still worthless
• The AI Act is not a compliance project. It is a maturity test.
• AI in projects: how far Germany really is
• Free AI readiness check