The question I hear most in AI projects is “which model?”. Yet most of these projects stall on an unclear goal, unclear data and unclear ownership long before the model’s capability matters. Closing those gaps is exactly the project manager’s job. Below is how I describe the role. This is not a case study or a measured result; it is a summary of how I work.
The project manager does not pick the model, they build the decision frame
As a project manager with a software engineering background, here is what I see: in an AI project the technical team looks at “what is possible”, the business side looks at “what is it good for”. If nobody owns the question in between — “which decision or process will improve, measured by which indicator?” — the project gets stuck at the demo stage. The project manager’s first contribution is to put that question in writing and to list what is out of scope in the same document.
In AI agent projects: authority limits and human approval
An AI agent is a process that can call tools and move forward step by step. So the management question is not “how smart is it?” but “what can it touch?”. At the start of a project I pin down:
- Which tools and data can the agent reach; what can it only read, and what can it change?
- At which steps is human approval mandatory?
- What happens when the agent gets stuck or gets it wrong; what is the rollback and takeover path?
- Where are the run logs kept, and who reviews them?
In LLM RAG projects: sources, freshness and authorization
RAG lets a model answer from an organization’s documents, and its success often depends more on the state of those documents than on the model. Which documents are sources, who keeps them current, how are old versions removed, and does a user only get answers from documents they are authorized to see? These look like technical details, but they are business decisions that must be settled in the first weeks of the plan. I also write traceability into the acceptance criteria: when a user asks “where did you get that?”, the source document must be traceable.
In fine-tuning projects: is it needed at all?
Fine-tuning is often the first idea that comes to mind, but it should not always be the first solution. If prompt design or RAG meets the need, fine-tuning adds cost and maintenance. If the decision is made, the project manager asks for: the source and usage rights of the training data, whether it contains personal data, a separate evaluation set, and a fallback plan if the expected result is not reached.
The common spine: pilot, measure, decide
In all three kinds of project I follow the same order: write the goal and the success criterion, build a pilot in a small scope, measure the result with real examples, and record the decision to expand, stop or change direction in writing. The point of a pilot is not to say “it worked” but to make the next decision with evidence. A decision to stop can also be a successful pilot outcome: you learned without investing in the wrong product.
What the project manager delivers
- Scope and acceptance criteria document: the business question, the user, the data, what is out of scope.
- Data, access and risk register: every risk with an owner and a mitigation.
- Pilot result summary: with real examples and an expansion recommendation.
- Decision records: who decided what, and on what grounds.
- Handover: usage and maintenance knowledge so the team can run the system without me.
In short
In an AI project the project manager is not a stand-in for the model; they define the work, the data, the authority and the decision the model will operate within. You can see how I apply this in my own work on the AI Projects and Project Management pages.