Artificial Intelligence in Project Management: Practical Uses, Risks and Limits

Ask a model for a project status summary, a risk shortlist and a requirement rewritten for a supplier audience, and you will have all three inside two minutes. Each one will read like something a competent colleague produced. That fluency is what makes these tools genuinely useful on a busy project, and it is also what makes them easy to misuse, because a well-written paragraph gives you no signal at all about whether the facts underneath it are right.

Responsible use is narrower than most corporate policy documents make it sound, and more permissive than the nervous version practised in a lot of organisations. Use AI where checking the output is cheap, on information you are permitted to put into the system, for decisions you were always going to own. When one of those three conditions is missing, the useful response is to slow down, not to write a better prompt.

Where AI earns its place on a project

Drafting and reshaping material you already understand is the safest and most immediately valuable use. A status narrative you could have written yourself, meeting notes turned into actions, a technical requirement restated for a commercial reader, a long update condensed for a sponsor who will read four sentences. You know the content, so an error is visible to you the moment you read it back.

Reducing volume is the second obvious use. Sixty supplier responses, three hundred free-text comments from user testing, a two-year issue log that nobody has looked at as a whole. A model will cluster all of that into themes in minutes, and the themes are usually reasonable. Treat them as a starting hypothesis to be checked against the source, in the same way you would treat a colleague's first read of a document they had never seen before.

Pattern work across historical data is more valuable and more conditional. Estimate ranges drawn from comparable past work, defect clusters, the type of change request that keeps arriving late in delivery. This is worth doing where your organisation's historical records are reasonably complete and reasonably honest. Where past projects were recorded to look well managed, the patterns you get back will describe the reporting culture more accurately than the delivery.

Challenge and option generation is the use that experienced project managers tend to underrate. Asking for the arguments against your own plan, for failure modes you have not listed, for three approaches to a sequencing problem, costs very little and risks almost nothing, because you evaluate every suggestion before it goes anywhere. Nobody is accepting the output, so the accuracy question barely arises.

What links the strong uses is that a cheap check exists. The weak ones are those where verifying the output would take as long as doing the work, or where, in practice, nobody verifies it and it flows straight into something that matters.

The risk is rarely the model itself

Most AI incidents on projects are data incidents. Commercially sensitive supplier pricing pasted into a consumer tool during an evaluation. Personal data in a workshop transcript uploaded for summarising. Client intellectual property used under a contract that says quite clearly where that material may be processed. None of these require the model to malfunction. They only require someone in a hurry to treat a chat window as a private notepad.

The second cluster concerns confidence. Output that is plausible, specific, well structured and wrong is considerably more dangerous than output that is obviously poor, because it survives a quick read by a busy reviewer and then enters a governance paper, a supplier response or a board summary carrying the authority of whoever passed it on. Bias sits close by. A model trained or prompted on your own historical records will reproduce the assumptions in those records, including the ones about which teams are slow, which estimates get inflated and which risks were quietly never written down.

Appendix X3 of the PMBOK® Guide Eighth Edition treats artificial intelligence as a project-management consideration that raises questions of data quality, privacy, security, bias, transparency, human oversight and accountability, rather than as a capability that removes the need for project-manager judgement. That framing is useful, because it puts AI in the same category as any other information source you would assess before acting on it. It also means the organisational position matters. Find out what your organisation actually permits, in writing, before you need to know. If your intended use falls outside it, that is an exception someone with authority has to grant, and asking for it is a normal project conversation.

What the model cannot see

Everything a model knows about your project has been written down and handed to it. That sounds obvious until you count how much of what you know is not written anywhere: the integration lead is already committed to another release in the same quarter, the sponsor's stated concern is about cost and the real one is about a previous failed programme, the supplier has been reliable on delivery and difficult on change control for four years.

Consider a delivery manager running a supplier evaluation with nine responses, using a model to summarise them and to draft a risk shortlist. The summaries are accurate, the shortlist is sensible and it saves most of a week. What it does not contain is the risk that decides the procurement. Two of the three shortlisted suppliers name the same integration subcontractor, and that subcontractor is already delivering a separate programme for the same organisation, peaking in the same quarter. Nothing in the nine documents says so. The concentration risk is visible only to someone who can see across the portfolio, and it is the sort of finding that changes a recommendation.

A model also cannot notice that something is missing. It will summarise the risk register you gave it without observing that no supplier risk appears anywhere in it, because absence is not in the text. And it carries no consequence. It has never had to explain a slipped date to a steering group, which is precisely why it produces recommendations with such even confidence.

A test worth running before you paste anything in

Three questions cover most situations. What would it cost me to check this, honestly, and will I actually do it? Am I permitted to put this information into this system? If the output is wrong and nobody notices, what does it affect and who is exposed? A use that passes all three is usually fine. A use that fails the third one deserves a different method, even when the first two are comfortable.

Beyond that, keep the working visible. Where AI-assisted material feeds a decision, keep the source alongside the output so the check can be repeated by someone else, and say plainly in the paper which parts were drafted with assistance and which were verified. Accountability does not move when a tool drafts something. The person who puts a figure in front of a steering group owns that figure, and "the model produced it" has never been an answer to a governance question.

For a PMP candidate, it is worth being precise about where AI sits in the current exam, because a fair amount of confident misinformation circulates. The 2026 Examination Content Outline names artificial intelligence in its introduction as one of the emerging trends used as an input to the job task analysis behind the exam. No task or enabler in the three domains names AI, and technology appears as an example of an external business-environment change to be monitored and assessed. There is no AI domain, no AI task and no stated share of AI questions. What the exam does assess is the judgement underneath: data quality, compliance, governance, risk and who is accountable for a decision, presented in realistic project situations.

That same judgement decides whether these tools help you on a live project or quietly degrade the quality of your information. Being deliberate about what you check, what you may share and what you sign your name to is one of the practical disciplines that structured PMP® preparation tends to sharpen, because it keeps returning to the question of what evidence supports a decision and who owns it. Used with that discipline, AI removes a real amount of low-value work from a project manager's week. Used without it, it produces more material, faster, that nobody has checked.

Andre Malowney

Interested in going further?

Deciding what to automate, what to verify and what to keep in human hands is a governance and accountability judgement before it is a technology one, and it is the sort of decision that becomes much easier when the underlying framework is solid. Omega's PMP® Exam Preparation works through exactly that kind of applied reasoning.

Appendix X3 of the PMBOK® Guide Eighth Edition sets out the considerations behind responsible AI use in a project context, and is the natural next read on this topic.

Ad · Amazon affiliate link.

References

A050: AI and the PMP Exam: What Project Managers Need to Know
A051: Do You Need to Know Specific AI Tools for PMP?
A052: AI Governance for Project Managers: What to Check Before You Use It
A053: AI Governance for Project Managers
A054: AI, Ethics and Accountability: Who Owns the Decision?

PMP and PMBOK are registered marks of the Project Management Institute, Inc.