Where AI Fits in Project Management, and Where It Does Not

The case for AI in project management depends on what you think the job is, and there are two views.

One view holds that project management is administration: schedules, status reports, meeting notes, chasing updates, maintaining a plan. On that view the function is largely automatable and the tooling is a substantial threat to it.

The other holds that the artefacts are a byproduct, and the job is judgement: deciding what matters, noticing when something is wrong before it is visible in a status field, and getting people to do things they are not obliged to do for you. On that view the artefacts can be automated and the job is untouched.

The honest answer is that both describe real project management jobs, and the mix differs enormously. A project manager whose week is genuinely dominated by producing documents faces a different situation from one whose week is dominated by conversations.

What is uncontroversial is that the administrative load is real and disliked, and it displaces the judgement work. Most project managers report spending substantial time on status collection and reporting, and it is time not spent on the risks nobody has noticed.

So the useful framing for this cursus: AI addresses the administrative layer well, and that matters mainly because of what it frees up, not because the administration itself was the value.

Sorting project management work by how well AI handles it.

Strong fit: meeting notes and action extraction, status report drafting from source systems, translating between audiences, drafting routine communications, summarising long threads, and producing the documentation nobody wants to write.

Partial fit: risk identification, where a model can surface categories from similar projects but cannot know your organisation's specific fragilities. Planning, where it can decompose a known type of work and cannot judge what your team can actually absorb. And retrospective analysis, where it clusters input usefully and does not know what people left unsaid.

No fit: estimation, covered below. Stakeholder judgement. Negotiating priorities. Deciding what to escalate and to whom. Reading a room. And the political work of getting a dependency delivered by a team that does not report to you.

The pattern is the same one that runs through the profession cursus generally. Where the input exists in writing and the output is a transformation of it, the fit is strong. Where the input is unwritten context and the output is a judgement, there is nothing to work with.

Asking a model how long something will take is the most requested capability and the one that most reliably disappoints. The reasons are worth understanding because they generalise.

A model has no access to your team. Estimation depends on who is doing the work, what else they are carrying, how well they know this codebase or this client, and how the last three similar tasks actually went. None of that is in the prompt, and a plausible-sounding number produced without it is a guess wearing a suit.

Software and project estimates are famously poor even from experienced humans with full context. A model producing a confident number is reproducing the shape of estimates in its training data, which are themselves optimistic, so it inherits the bias rather than correcting it.

And the confident presentation is actively harmful here. An estimate from a colleague arrives with hedging, visible uncertainty and a caveat about assumptions. A generated one arrives clean, and cleanliness reads as confidence in an artefact where uncertainty is the most important information.

What does work in this territory. Decomposing a piece of work into tasks, which is a structural exercise the model does well and which improves human estimation by making the work visible. Surfacing what similar projects typically include that this plan omits. And prompting for the assumptions an estimate depends on, so the human estimating knows what they are assuming.

Use it to structure the estimation, not to produce the number.

Status reporting is the clearest target and the case worth examining closely, because automating it badly makes an existing problem worse.

The existing problem. Status reports are frequently written to be read rather than to be accurate. A report saying amber, on track with mitigation is doing social work as much as informational work, and everyone involved knows the convention. The report is a negotiated artefact.

What AI does well. Assembling the factual layer from source systems: what moved, what did not, what is blocked, what changed since last time. This is genuine drudgery and the model has the data.

What it cannot do, and should not be asked to. Decide what to escalate. That judgement depends on knowing which stakeholder needs to hear what, when a problem is real versus noisy, and what the political consequence of raising it is. A model has none of that.

The risk of automating badly. If a model generates the whole report including the assessment, you get a fluent, confident, plausible status that nobody thought about. And because it reads well, it is less likely to prompt the question that a hesitant human report would.

So the design that works: the model assembles the facts and the project manager writes the assessment. That split preserves the part where the value is and removes the part that was consuming the time. And it keeps the report honest, because a human is still putting their name to the judgement.

Transcription and note-taking is the most widely adopted use in this function, and it is genuinely valuable with two specific cautions.

What it delivers. The project manager stops taking notes and starts participating, which is a real change in what they can contribute. Actions are extracted rather than reconstructed. A searchable record exists. And people who missed the meeting can catch up without a summary someone had to write.

The first caution is about compression. A summary omits things, and what it omits is a choice the model made. Disagreement is frequently compressed away, because a summary optimises for the settled outcome rather than the contested path to it. A meeting where two people strongly disagreed and one conceded produces a summary recording the decision, which loses exactly the information a reader six months later would need.

So the practical instruction: summarise against a structure that names what to preserve, including decisions, open questions, disagreements and their basis, and actions with owners. A general summarise this loses the disagreements first.

The second caution is about behaviour. People speak differently when recorded, and the effect is largest for the conversations that matter most: the candid assessment, the admission that a date will slip, the early signal that something is wrong. A project manager who records everything may find they hear less.

So record by default and keep an explicitly unrecorded channel, because the informal signal is frequently the earliest one you get.

Risk work is where AI is more useful than expected and less useful than claimed, and the split is instructive.

What it does well. Prompting from a broad base. Asked what typically goes wrong in a project of this shape, a model produces a list drawn from a great deal of written project experience, and it will include categories your team did not think of. That is genuinely valuable, because the risks that hurt are usually the ones nobody raised rather than the ones on the register.

It is also good at checking a plan for omissions. Comparing your plan against what similar plans usually contain surfaces the missing dependency, the absent rollback, the unstaffed support period after launch.

What it cannot do. Know that this particular vendor is unreliable, that the integration team is carrying three other projects, that the sponsor is leaving, or that the last time you tried this the security review took nine weeks. Your specific fragilities are unwritten and local, and they are where the real risk concentrates.

And it cannot assess probability or impact for your context, so a generated register with generated scores is a document rather than an analysis.

The workable pattern: use it to expand the candidate list, and have humans assess and prioritise. The value is in the recall of categories, not in the judgement about them. A risk register that is generated in full will be comprehensive, generic, and ignored, which is worse than a short one people believe.

An underrated use that maps directly onto a task project managers do constantly and find tedious.

The same project state has to be described to an engineering team, a steering committee, a customer and a finance partner, and each needs different framing, different detail and different vocabulary. A project manager spends real time rewriting the same information four ways.

A model does this well because it is a transformation of existing content rather than a generation of new claims, which is the condition under which these systems are most reliable. Supply the underlying facts and the audience, and the reframing is competent.

Three cautions.

The substance must not change between versions. It is easy to produce an executive summary that is more optimistic than the engineering version, not through dishonesty but because summarising toward an executive audience tends to smooth detail, and the detail was the caveat. Check that the versions agree on the facts.

Sensitive detail must not leak across audiences. A customer-facing version generated from an internal source may include information that was never meant to leave, which is a specific instance of the permission problem the company brain cursus describes.

And the project manager still owns the message. The model reframes; the decision about what a stakeholder needs to know is judgement, and it is precisely the judgement that makes the role valuable.

Done well this is one of the largest time recoveries available in the function.

An order for a project manager or a PMO, by value delivered against effort.

First, meeting transcription with structured summarisation. Immediate, widely available, and it returns attention to the meeting itself. Use a summary structure that preserves disagreements and open questions rather than a general summary, and keep an unrecorded channel.

Second, status report assembly, with the model producing the factual layer and the project manager writing the assessment. This is the largest recurring time cost in most PM roles.

Third, audience translation. Once the facts are assembled, generating the four versions is nearly free and it was previously a real cost.

Fourth, plan decomposition and risk prompting, used to expand what humans consider rather than to produce the artefact.

And deliberately not: generated estimates, generated risk scores, and any report where the model writes the assessment rather than the facts.

The honest framing for the profession. None of this replaces the judgement that makes a project manager effective, and all of it removes work that was crowding that judgement out. A project manager who recovers a day a week from administration and spends it on the conversations that surface problems early has gained considerably more than the time suggests, because those conversations are where projects are actually saved.