AI Governance for Project Managers: What to Check Before You Use It
The governance question about AI usually arrives after the fact. Someone on the team has been pasting meeting notes into a tool for a month, a supplier's proposal mentions an AI-assisted estimating model, or a sponsor asks in a review why the programme is not using any of this yet. By the time anybody sits down to write a position, the practical decision has already been taken several times over by people making reasonable individual choices.
The decision itself is narrower than the debate around it. AI is worth adopting on a project when there is a specific task where it would improve a decision or remove real effort, when the data it needs is data you are permitted to give it, when a wrong output would be caught by somebody before it reached anything that mattered, and when a named person still carries the result. Four conditions, all of which have to hold at the same time. Most arguments about whether to use AI on a project turn out to be arguments about one of them.
Naming the task the tool is for
An adoption question asked at the level of "should we be using AI" cannot be answered, because nobody can act on the answer. The answerable version names a task: assembling the first draft of a status report from the week's data, grouping two thousand free-text consultation responses into themes, searching four years of correspondence for every mention of a contract variation, checking a specification against a standard clause by clause.
Once the task is named, two things come into view that the abstract version hides. The first is what the improvement would actually be worth. A tool that saves an analyst three hours a week on report assembly is worth having and will not change the programme; a tool that makes a badly evidenced recommendation look polished has made the programme worse. The second is whether something lower-risk gets you the same result. Often it does. A good many of the tasks people want AI for are tasks that a better report template, or one query against the system that already holds the data, would settle with no new question about permission, review or accountability attached to them.
The data question you cannot take back
Of the four checks, only the one about data is irreversible. A wrong output can be corrected. An unclear accountability can be assigned on Monday. A review step can be added to a process that has already run twice. Information that has gone into a third-party system has gone, and no policy written afterwards retrieves it.
So it pays to be exact about what the tool will receive. Not the category of data in the abstract, but the specific material: this consultation response, that supplier's commercial submission, the personal details held in this case file, the safety report that names individuals. Then the permission question, which in most organisations has already been answered by somebody. Public bodies have information asset owners and a privacy notice setting out how material collected from the public may be handled. Commercial work carries confidentiality clauses agreed before the project started. Regulated environments have data classifications with rules attached to each one. Very few project managers need to invent an answer here. Most need to find the person who already owns it and put a properly specific question to them.
A district council's programme office wanted an assistant to work through the responses to a planning consultation, several thousand of them in free text, ahead of a committee report. The analyst doing it by hand needed three weeks the programme did not have. Working through the checks took an afternoon. The task was clear, the improvement was real, and the data was material the public had submitted under a privacy notice describing how it would be handled, some of it naming third parties.
The information governance lead did not refuse it. She scoped it. The tool could cluster and index the responses inside the council's own tenancy, the analyst read the clusters and wrote the themes, and the recommendation to committee was drafted by the officer who would stand behind it in the room. The approval went through the route that already existed for any new processing of resident data, took eight working days and left a record. Nobody convened an AI board.
Who catches a wrong answer
The remaining two checks work as a pair. An AI output is a claim, and a claim on a project needs a route by which a wrong one gets found. Sometimes the route is already there: the model's estimate goes into the same challenge session every other estimate goes into, and the people in that session are perfectly capable of asking where a number came from. Sometimes it has to be built. If a summary of two years of correspondence is going to a legal team, somebody with that correspondence in front of them reads the summary against it before it leaves the building.
Accountability is the check people skip, because on paper it looks like a formality. It stops looking like one the first time an AI-assisted forecast turns out to be wrong in front of a steering group. The project manager who put that forecast on the slide owns it the way they would own a spreadsheet error, and the tool is not available as an explanation. Appendix X3.1 of the PMBOK® Guide Eighth Edition places artificial intelligence inside the working context of a project, and the line it holds throughout is that the technology can inform a decision while the answerability for it stays exactly where it was.
For a PMP® candidate, what is worth knowing precisely is how little the current PMP Examination Content Outline says about AI. It names AI among the trends used as inputs to the job task analysis behind the outline, and technology change appears as an example of an external business environment shift a project manager is expected to evaluate. No domain or task in the outline is about AI. The practical consequence is to read a situation involving an AI tool as an ordinary governance, data or accountability situation in unfamiliar dress, and to ask it the same questions: what objective is affected, who holds the authority, what information is missing, and whether a process that already exists applies. A structured PMP exam preparation course gives you the repetitions that make that reading quick, across situations that differ in the details.
Get the four checks into a form somebody can answer in twenty minutes, and run them when a tool is first proposed, which is usually a fortnight before anyone would have thought to ask. Most proposals clear it. The ones that do not tend to fail on data, and they fail early enough to be reshaped into something workable, which is what happened to the council's consultation. A blanket ban gets you the same place as no position at all, because the pasting carries on where nobody can see it and nothing is being checked.
Interested in going further?
An AI adoption decision is mostly ordinary project governance applied to an unfamiliar object, which is easier to see once you have worked through a few of them. Omega's PMP® Exam Preparation covers the data, authority and accountability questions in realistic situations where the technology itself is incidental.
The artificial intelligence material sits in the appendices of the PMBOK® Guide Eighth Edition, alongside procurement and project management offices.
Ad · Amazon affiliate link.
References
A049: Artificial Intelligence in Project Management: Practical Uses, Risks and Limits
A050: AI and the PMP Exam: What Project Managers Need to Know
A053: AI Governance for Project Managers
A054: AI, Ethics and Accountability: Who Owns the Decision?
A055: The Stewardship Lens: Connecting AI, Sustainability and Ethics
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
