"AI Project Manager" has started showing up as a job title, a certification, and a marketing phrase — often all three, describing three different things. Some of it means a chatbot bolted onto existing PM software. Some of it means a person who's simply comfortable using AI tools day to day. Neither is what the term originally meant when the AMIGA Framework was built.
The distinction matters, because it's the difference between AI as a feature and AI as a discipline — and the two produce very different transformation outcomes.
Where the framework actually comes from
The AMIGA Framework — Governance, People, Process, Technology, Value, Data — was built from three decades of running large-scale enterprise transformation programs, not designed backward from a product roadmap. The pattern behind it is simple to state and hard to execute: transformations don't fail because of the technology. They fail because these six dimensions get managed as isolated workstreams instead of a connected system, and the industry's roughly 65% failure rate is the accumulated cost of that gap, year after year.
That research became The AI Project Manager — a book and now a certification program built to teach the framework directly to the professionals running these programs: program managers, consultants, and transformation leads who need more than a survey-level understanding of "AI in project management." The certification walks through all fourteen modules of the framework, including over 260 mapped AI use cases across the six pillars, so the people leading a transformation program understand not just what AI can do, but where it actually changes outcomes versus where it's just a feature checkbox.
Why a certification and a platform exist side by side
A framework you can explain isn't the same as a framework you can run. That's the gap between education and execution — and it's why the AMIGA Framework exists in two forms rather than one.
AMIGO is where the framework gets operationalized: governance dashboards, RAID logs, resourcing, change management, data migration validation, and benefits tracking, all built on the same six pillars taught in the certification. Someone can complete the certification and understand exactly why phase gates need enforced decision rights, or why data migration needs row-by-row validation instead of a count check — and then apply that understanding directly in a platform built around the same structure, rather than translating classroom concepts into whatever tools happen to be available on their next engagement.
This is also why the platform's AI features aren't a chatbot layered on top of existing workflows. They're built from the same 260+ use case mapping taught in the certification — automated RAID scoring, predictive schedule analytics, resistance heat-mapping, migration validation — instrumented directly into the tool a program manager already uses daily.
What this means if you're evaluating either one
If the question is "should my team get certified or should we adopt a platform," the honest answer is that they're solving different parts of the same problem. Certification builds the judgment to recognize a governance gap or a data risk before it becomes a program-level failure. A platform gives that judgment somewhere to actually operate — dashboards that surface the risk, workflows that enforce the governance, tracking that ties back to the original business case.
Programs that have one without the other tend to hit a ceiling: trained people working around tools that don't reflect what they learned, or a well-instrumented platform being used by teams who haven't been trained to interpret what it's surfacing.
The gap between a 65% industry failure rate and an 80-85% success rate isn't closed by a better tool alone, or by better-trained people alone. It's closed when the framework taught and the framework run are the same one.