Managing AI Implementation: How PMI-CPMAI Adapts Standard Project Plans

Key Takeaways

• Phased framework: six CPMAI phases that build on existing PM practice
• Problem before model: business problem and success measure defined first
• Data as a gate: readiness and the right team confirmed before development
• Evidence-based commitments: milestones tied to what testing proves
• Ownership after launch: a named owner for monitoring and accountability
• Two different jobs: different skills for delivering AI and for using it

A project manager receives an AI initiative, and the sponsor wants the usual within days: a charter and plan with a go-live date. Everything fits the template, though two questions haven’t come up yet: where the data lives and how anyone will know the output is good.

Questions like these separate two jobs that can look alike. Using AI to draft a status report is one skill. Managing a project that delivers an AI-enabled solution is another, and it draws on teams from across the organization, including data and governance owners. Both require discipline, but they involve different decisions.

The difference starts at launch. A traditional plan can show what the team tested and approved by then. However, an AI system’s reliability for its intended use can drift afterward, because the data and conditions it meets can change, even when nobody touches the deployed system.

Managing that difference takes more evidence at four points in a familiar plan, and PMI-CPMAI gives each one a practical structure.

PMI-CPMAI: The Framework Built for AI Projects

Traditional project management gives AI projects a solid foundation in clear scoping and risk management. AI work calls for an added layer of structure, since results depend on data quality and on variables that shift from training data to model behavior in production. CPMAI co-creator Ron Schmelzer says teams that tried agile or even the scientific method to manage AI projects found quickly that the approach wasn’t working. His explanation: AI projects center on getting the right data and understanding how it drives outcomes, as much as on building software.

PMI-CPMAI, short for PMI Certified Professional in Managing AI, builds on that foundation. It’s the credential for the Cognitive Project Management for AI (CPMAI) framework, a clear process for data-heavy, iterative projects. Its six structured phases complement traditional project practices. The framework is tool-agnostic and doesn’t require coding.

The six phases, in order:

• Business Understanding: define the problem and decide whether AI fits
• Data Understanding: assess what data exists and whether the team can use it
• Data Preparation: clean and standardize the data for modeling
• Model Development: select and train or tune the model against measurable goals
• Model Evaluation: test the model against business and technical criteria
• Model Operationalization: integrate the model into workflows and set up monitoring

In practice, the six phases run as a loop: teams revisit earlier ones as data shifts or models behave unexpectedly. Through every loop, model development stays tied to the measurable goals set in the earlier phases, so the work begins with the problem.

Start With the Problem, Not the Model

Whatever AI systems the project implements, the first job is to define the business problem and a way to measure success. In CPMAI, this is Business Understanding, the first phase, and it includes deciding whether AI is the right solution.

RAND’s independent research supports the concern: leaders sometimes ask for AI for problems that don’t require it. One RAND interviewee described getting instructions to apply AI to data that a few if-then rules could have handled.

The decision to pursue AI often starts with leadership, and RAND’s 2024 report shows how much that matters. Of the 50 industry practitioners interviewed, 84% cited leadership-driven causes, such as unclear direction on the problem to solve, as the primary reason AI projects fail.

Most interviewees were nonmanagerial engineers, and RAND acknowledges the sample may skew toward leadership failures. The study also centered on teams that build and train models, so its findings map most directly to that kind of project.

With a sponsor’s deadline to meet, PMs can deliver a plan that marks which commitments are firm today and which depend on evidence still to come. AI output is probabilistic, so “done” has to mean an acceptable level of performance. Scoping is also the moment to surface AI-specific risks, well before any late-stage review.

Before anyone signs the charter, settle these questions:

• Problem: What business outcome are we after, and who owns it?
• Fit: Would a simpler, non-AI fix meet the need?
• Success measure: How will we judge the output good enough for its intended use?
• Risk: Which AI-specific risks, such as privacy and bias, apply to this use case?

Once these questions have answers, the team knows what problem it’s solving and what the project needs from its data.

Treat Data Readiness as a Gate, Not an Assumption

Defining the problem is half the groundwork, and finding out whether the data can support it is the other half. CPMAI devotes two of its six phases, Data Understanding and Data Preparation, to that half, and both come before anyone builds a model.

Schmelzer puts the reason in five words: “AI projects are data projects.” RAND’s research echoes the premise: data-driven failures ranked as the second most common root cause, and legacy datasets built for compliance or logging often fall short of what a model needs.

Gartner connects data to outcomes: in February 2025, it predicted that through 2026, organizations would abandon 60% of AI projects unsupported by AI-ready data.

Given that link, treat readiness as a checkpoint where a named decision-maker weighs enough evidence to authorize the next stage of work. Data issues can still resurface later in the project, including after launch, so the checkpoint works best as an ongoing practice.

In practice, the checkpoint rests on the questions CPMAI’s Data Understanding phase asks: whether the data is accessible and reflects the problem’s real-world context. PMI also advises strengthening data governance early.

Before the sponsor funds the next stage, require this evidence:

• Suitability: the data reflects the real use case and its edge cases
• Access: the team can legally and technically reach it
• Quality: the team has measured known gaps and has a plan to close them
• Ownership: a named person answers for the data from here on

Producing that evidence takes the right people. Add a data engineer who knows the pipelines and a subject-matter expert who can explain what the fields mean, and log any missing capability as a schedule risk to resolve with the sponsor before the next gate.

Evidence also shapes the sponsor’s deadline. A provisional target works while data dependencies remain open. Still, a firm delivery commitment must account for what’s unresolved and the evidence needed to clear it.

Once data clears the gate, the team has more evidence behind its schedule, and the plan meets its next test: what happens when results come back.

Plan for What Testing Reveals

With the data in place, the team moves into Model Development and Model Evaluation, the CPMAI phases where the team develops the solution and tests whether it performs reliably and aligns with project goals. The planning question is what a PM can commit to when testing might reshape the plan. A workable answer builds milestones around the evidence the team must produce, alongside the activities it expects to finish.

Two statements belong in the plan side by side. A team can commit to completing a defined evaluation by an agreed date, assuming its dependencies arrive on time. The results themselves are the evidence, and the plan leaves room for what they show.

RAND’s interviewees support the case for flexibility. Some reported that leaders often underestimate the time AI work takes, and several said rigid readings of agile fit AI poorly. However, RAND notes agile itself was never meant to be rigid.

Before testing starts, agree on who decides whether results meet the intended business use and risk tolerance, and tie acceptance criteria to the use case. The PM coordinates and documents the decision without certifying technical adequacy.

Once testing produces results, they drive a decision, and the options run wider than go or no-go:

• Proceed: results meet the thresholds for the intended use
• Repeat: results are close, and a specific data or tuning change is likely to move them
• Change approach: results point to a different model, data source, or workflow
• Reconsider feasibility: the gap points to a need for different data or technology
• Stop: the use case can’t meet its thresholds or risk limits, so effort moves elsewhere

Whichever option applies, report an experiment that lands short of its objective as a finding that informs the next decision. Its value depends on whether it produced useful evidence within the agreed constraints.

Passing acceptance is a milestone, and maintaining acceptable performance in production is an ongoing responsibility.

Assign an Owner Before Go-Live

The last CPMAI phase, Model Operationalization, carries that responsibility into production: the team moves the solution into business workflows and sets up monitoring. RAND’s report backs this up: organizations that quickly move from one prototype to the next are often blind to failures after deployment, while teams with monitoring infrastructure can tell when a deployed model needs maintenance.

Monitoring only helps if someone acts on what it shows, which is why closure and ownership need separate answers. Once the team meets agreed transition criteria, the project can close: the PM completes the transition, and ongoing operational accountability passes to a named owner. Handing off an AI system resembles onboarding a new hire, because the work continues after day one.

A solid handoff to operations covers:

• Named owner: one accountable person or team
• Monitoring plan: what the team watches, and who sees the results
• Governance responsibilities: who answers for fit and risk over time
• Change approval: who signs off on updates
• Review cadence: how often the owner revisits performance

Every responsibility in the left column already sits on a PM’s plate. The right column lists the added evidence and accountability AI delivery calls for.

Familiar PM Responsibility	Added AI Delivery Consideration
Define scope and success	Test whether AI is appropriate and whether the team can measure success
Confirm dependencies	Establish data suitability and access, with accountable owners
Plan milestones	Include evidence checkpoints and criteria for revisiting assumptions
Approve results	Verify performance and risk against intended use
Close and transition	Transfer monitoring and change control, with ongoing accountability

Each row adds evidence or accountability to a responsibility PMs already hold, from defining success to transferring ownership. Together, the additions make delivering AI a different job from using it.

Which Job Are You Doing: Delivering AI or Using It?

Using AI and delivering AI call for different skills, and PMI observes that many PMs use AI tools without yet managing AI projects. Both are worth developing. AI delivery includes configuring or integrating an existing model and adopting a purchased AI service.

Check which job is primary for your current initiative:

• AI use: you use an approved tool to improve your personal or team workflows
• AI delivery: you coordinate the implementation of an AI-enabled business solution
• Both: you manage the implementation while improving your own AI-assisted work

Whichever job is primary, the difference comes down to what you answer for. Using AI in your own work carries responsibility for the results. Delivering an AI solution adds responsibility for the project’s commitments and for how the system performs in the organization’s operations. Delivery requires evidence before commitments, and the first thing to settle is what that evidence must show.

What to Prove Before You Accept the Date

Schedule and budget commitments still matter to the sponsor, and a plan still has to state them. In an AI project, a commitment is only as dependable as the evidence behind it. A go-live date holds up only if the team can answer two questions: whether the data can support the intended use, and what results will count as done.

Before accepting the go-live date, ask what the team must prove: that AI fits the business problem, and that the data and system meet the intended use. With that answer in hand, the PM can give the sponsor a plan that separates the commitments the team can make now from those that depend on evidence still to come.

With CPMAI’s six phases as a guide, gathering that evidence becomes a repeatable practice.

Project Management Academy partners with project managers who want to extend the discipline they already have to AI delivery.

If you’re leading an AI initiative, which part of your plan would you want a structured framework behind?

Explore PMI-CPMAI certification training and bring the six-phase framework to your next charter.