Project Managers
Why this role is needed
An AI initiative almost always sits between several loops: business wants to solve a problem, the AI product owner understands platform capabilities, IT and architecture own integrations and compatibility, security and compliance check risks, data owners own sources, users validate applicability, and the impact owner confirms the result.
Without a project manager, the initiative quickly breaks into separate conversations, expectations, and dependencies.
Typical problems without this role: business formulates an idea but no one brings it to evaluation; an AI product is selected but requirements ownership is unclear; a pilot starts but users are not involved; IT waits for a brief, business waits for results, the AI function waits for data; the solution is technically ready but not adopted; impact is expected but no one agreed how to measure it; the initiative hangs for months without a decision.
The role exists so the initiative always has a movement owner, next step, and clear status.
Who the project manager is in the AI initiative loop
In the AI initiative portfolio, the project manager is not a classic task and deadline administrator.
It is a management role at the intersection of business, AI products, and adjacent functions.
They ensure the idea is structured, the business problem is clear, expected impact is recorded, product route is selected, participants join on time, constraints are found before launch, delivery follows the right track, pilot results are validated, and the initiative closes with a clear outcome.
They do not need to be an expert in every technology. But they must understand which questions to ask and whom to involve at every stage.
What the project manager is not
Not the business sponsor
The business sponsor owns the problem, process, and business value. The project manager helps frame and move the initiative, but should not replace business ownership of why it matters, who will use it, what impact is expected, or how it enters the process.
Not the AI product owner
The AI product owner owns the platform, tool, or service: LLM, RAG, ML platform, code agent, workflow automation, or applied AI service. The project manager connects the initiative to the right product route and organizes interaction with the product owner, but does not own the product roadmap.
Not the technical lead
Technical decisions should be made by architects, developers, ML engineers, data teams, IT, and security. The project manager does not need to design architecture or configure models, but must understand dependencies around data, integrations, access, deployment perimeter, security, model quality, support, and operations.
Not the impact owner
The impact owner confirms that the initiative created value. The project manager organizes impact validation, but should not invent business impact instead of the process owner.
Core responsibilities
1. Formalize the initiative
Help turn a raw request into a manageable initiative: problem, sponsor, users, urgency, expected impact, known constraints, candidate AI products, and next step.
At this stage, the goal is not a large technical specification, but a management-relevant initiative card.
2. Organize evaluation
Bring together the right participants: business sponsor, impact owner, AI product owner, IT, architects, data owners, security, and operations when production use is possible.
Evaluation should answer not only "can we build it," but also "why build it," "through what," and "how will we validate the result."
3. Choose the product route
The project manager does not choose the route alone, but organizes the decision.
| Need type | Possible route |
|---|---|
| Search across documents | RAG |
| Text and analytics preparation | LLM |
| Metric forecasting | ML platform |
| Development acceleration | Code agent |
| Multi-step action automation | Workflow automation |
| User scenario across several capabilities | Applied AI service |
If an existing AI product fits, the initiative goes through it. If not, the project manager records the fork: improve an existing product, build a new applied service, transfer the request to the AI product portfolio, or reject the initiative under current conditions.
4. Manage delivery
The project manager does not perform technical work, but owns controllability of implementation: target solution, participants, work plan, dependencies, constraints, timing, readiness criteria, quality criteria, user launch conditions, and operations risks.
Delivery differs by AI product: LLM may need scenario setup and answer quality checks; RAG needs documents, knowledge base loading, answer testing, and support rules; ML needs data, training, validation, integration, and monitoring; code agent needs team, scenarios, environment, and safe-use rules; applied AI service needs requirements, UI, integrations, testing, and operations model.
5. Prepare gate decisions
The project manager prepares the initiative for stage gates. They may not be the final decision maker, but must ensure status, completed work, required decisions, risks, blockers, artifacts, proposed next step, and success criteria for the next stage are clear.
The goal is not to push the initiative through at any cost, but to prepare a high-quality management decision.
6. Work with risks and dependencies
AI initiatives are often blocked not by development, but by missing data access, low data quality, no source owner, security constraints, architectural changes, unavailable users, unclear impact validation, unsupported operations, or complex integrations.
The project manager should not only record risks, but bring them to decision early enough to manage them.
7. Organize pilot and adoption
A pilot is not just a demo. It should test a specific hypothesis: whether the solution solves the original problem, is usable, has enough quality, creates impact, can scale, and has no blocking constraints for production use.
The project manager organizes participants, scenarios, duration, feedback, metrics, decision owner, and what happens after the pilot.
8. Move to impact
A key AI initiative mistake is treating technical launch as the end. The project manager must bring the initiative to impact validation: usage facts, user feedback, comparison with the original hypothesis, qualitative or quantitative result, impact owner confirmation, and decision to scale, operate, improve, or close.
Unconfirmed impact is also a result, as long as the reason is recorded and the initiative does not remain suspended.
Working group around the initiative lead
The old page described this as a cross-functional working group. This is worth preserving: the project manager does not work alone, but assembles a temporary team for a specific initiative.
Typical members include business sponsor / initiative owner, AI product owner, business analyst or process expert, data scientist / ML engineer for ML tasks, data engineer for data-heavy tasks, solution architect, and security, data owner, UX, DevOps/MLOps, or operations when needed.
Principles:
- small size — usually 3-7 people, otherwise speed drops and accountability blurs;
- limited duration — the group exists for evaluation, delivery, pilot, or handover;
- clear deliverables — every stage has artifacts sufficient for a gate decision;
- one movement owner — the initiative lead coordinates, but does not replace business decisions or technical expertise;
- transparency — status is visible to the AI function and stakeholders through the initiative card, artifacts, and gate decisions.
After closure, the working group dissolves and support moves to the AI product owner, operations, or another stable loop.
Responsibility by lifecycle stage
| Stage | Project manager role |
|---|---|
| Idea | Record the request, clarify context, define next step |
| Evaluation | Organize analysis of problem, impact, constraints, and product route |
| Delivery | Manage implementation, dependencies, participants, and artifacts |
| Awaiting impact | Organize validation of usage, quality, and benefit |
| Closure | Record outcome, decision, and further actions |
Artifacts maintained by the project manager
The project manager should not create documents for the sake of documents. But every initiative needs minimum artifacts for managed movement.
At idea stage: idea card, request source, initial problem description, expected sponsor, next step.
At evaluation: initiative card, business problem, impact hypothesis, preliminary product route, feasibility assessment, constraints list, gate decision.
At delivery: implementation plan, participant list, dependencies and risks, target scenario or requirements, testing artifacts, security/architecture/data/operations approvals, pilot plan.
At awaiting impact: usage metrics, user feedback, pilot results, impact calculation or qualitative confirmation, decision to scale, improve, operate, or close.
At closure: final status, confirmed or unconfirmed impact, reason for closure/rejection, operations decision, reusable learnings.
Key skills
1. Translate business language into a managed initiative
Business often says "we want a chatbot," "we need AI," "let's try RAG," "can this process be automated," or "we want what another team has." The project manager translates that into problem, user, current pain, desired result, success measure, and possible AI product.
2. Understand AI products at management level
The project manager does not need to be an ML engineer or developer, but must understand when LLM is enough, when RAG is needed, when ML is needed, when code agent or workflow automation fits, when an applied AI service is required, and when the task does not require AI at all.
3. Manage uncertainty
AI initiatives often start with incomplete information: missing data, unknown model quality, uncertain adoption, unclear impact, security or architecture constraints. The project manager should move the initiative through small checks rather than require full certainty on day one.
4. Work with adjacent functions
The project manager synchronizes business, AI function, product owners, IT, architecture, security, data owners, legal, compliance, operations, and users. Their job is not just to schedule meetings, but to align business, product, technical, risk, and operations logic.
5. Stay oriented toward impact
The main value is not closing tasks, but bringing the initiative to outcome. The project manager keeps asking: why are we doing this, what impact do we expect, how will we validate benefit, who confirms it, what happens after the pilot, and should we continue?
Typical mistakes
1. Dragging an initiative without a business sponsor
Without a problem owner, the initiative almost always becomes an experiment for its own sake.
2. Entering delivery without impact evaluation
If expected value is unclear at the start, it will be hard to prove that the solution worked.
3. Replacing the AI product owner
The project manager can organize product route selection, but should not own the product roadmap.
4. Treating pilot as the finish line
A pilot is a hypothesis test, not the outcome of the initiative.
5. Not recording stop reasons
If an initiative stops, the reason must be clear: no data, no impact, no sponsor, high risk, low priority, or wrong product route.
Metrics for project manager work
| Metric | What it shows |
|---|---|
| Share of initiatives with a clear next step | How manageable the portfolio is |
| Evaluation cycle time | How quickly ideas turn into decisions |
| Share of initiatives with selected product route | How well routing works |
| Share of initiatives reaching impact validation | Whether initiatives stop at pilots |
| Share of closed initiatives with clear reason | Whether closure discipline exists |
| Share of initiatives with confirmed impact | Whether the portfolio creates value |
| Number of stuck initiatives | Where management or resource issues exist |
The project manager should not own all business impact alone. But they are responsible for ensuring impact is defined, checked, and recorded.
Interaction with other roles
| Role | Interaction |
|---|---|
| Business sponsor | Clarifies problem, value, users, and adoption |
| Impact owner | Aligns result confirmation method |
| AI product owner | Defines product route and product constraints |
| Users / working group | Organizes solution validation and feedback |
| IT and architecture | Aligns integrations, perimeter, and technical constraints |
| Security / compliance | Identifies risks and safe-use requirements |
| Operations / support | Prepares handover into stable use |
| AI function | Synchronizes initiative with portfolio, rules, and stage gates |
Criteria of a good AI initiative lead
A good project manager in the AI initiative portfolio starts with the problem, not technology; does not drag initiatives without a business owner; understands the difference between LLM, RAG, ML, agents, and applied services; chooses the right participants; raises data/security/architecture/operations questions early; does not treat pilot as the end; brings initiatives to impact validation; closes weak initiatives; records decisions, risks, and stop reasons; and helps the portfolio become more transparent.
Core idea
The project manager in the AI initiative portfolio is the owner of initiative movement.
They do not replace business, product, IT, or security. They connect them into one managed process.
Their job is to ensure every AI initiative follows not "discussed → tried → forgot," but a managed logic: "recorded problem → evaluated → selected product route → implemented → validated impact → made final decision."
That is how the project manager turns AI initiatives from conversations and pilots into a managed flow of business change.