Introduction
Jason D. Parrish | PMP · CSM · PMI-CPMAI
I've spent more than twenty years helping enterprise technology programs get from idea to production, and what keeps me in this work is the craft of it: building something that holds together technically, organizationally, and over time. Good governance is a big part of how that happens. Done well, it's not a constraint bolted onto delivery, it's the thing that lets teams move fast with confidence, because everyone trusts the ground they're standing on.
Over that time I've led work at a range of scales, from process improvements with a clear, immediate payoff to multi-year modernization efforts supporting platforms with billions in assets under management. Along the way I've picked up credentials in project management, agile coaching, and most recently AI project management, each one marking a stage of the same underlying thread: taking ambiguous, high-stakes work and turning it into something a team can actually execute, together.
Why "Triple A Program Delivery"
The name isn't a label. It's a claim. Break it apart, and each word carries the weight of a real shift in how delivery work gets done.
AI-Assisted
AI is not replacing program, project, and portfolio management (PPPM). It's accelerating it. Data consumption that used to take days now takes minutes. Artifact production, including status reports, requirements drafts, risk registers, and retrospectives, compresses from hours to seconds. But speed in the parts doesn't eliminate the need for the whole. Someone still has to hold the work effort together: reconcile competing priorities, read the room in a stakeholder meeting, and make the judgment call when the data is incomplete or the team is stuck. That's the human role, and it doesn't shrink as AI gets better. It gets more important, because the volume and velocity of AI-assisted output raises the cost of a missed judgment call.
AI is also introducing something delivery leaders haven't had to account for before: probabilistic systems development and the data-centric needs that come with it. This is where the AI Development Life Cycle, or AIDLC, comes into play, and CPMAI is the methodology that addresses it. Traditional SDLC approaches assume deterministic outcomes: build the thing, test the thing, and the thing behaves the same way every time. AI systems don't work that way. Managing that difference isn't optional anymore; it's a core competency.
Agile
AI is closing the gap between waterfall and scrum, not by making one obsolete, but by removing speed as the deciding factor. For years, teams leaned toward scrum partly because it moved faster than waterfall's upfront planning. AI erodes that advantage on both sides: waterfall teams can now compress requirements documentation and planning cycles just as scrum teams compress sprint velocity. So speed stops being the reason you pick a methodology, and fit becomes the reason instead.
That means methodology selection reverts to what it always should have been: a decision driven by the nature of the work, not the tempo you need.
- Scrum fits complex, highly variable initiatives where the outcome isn't known going in and iterative discovery is how you find it.
- Waterfall fits work where the outcome is locked and requirements are genuinely feasible to define upfront, such as a system migration or technology transformation where the target state can be documented, locked, and built against.
- Kanban fits service-type work and teams operating on a FIFO model, with the flexibility to reprioritize when something genuinely urgent comes through.
- AIDLC is where CPMAI enters the picture, the methodology for developing probabilistic functionality, whether that's an entire AI system or a probabilistic component embedded inside an otherwise deterministic platform.
Program Delivery
This term sits deliberately at the intersection of Portfolio Management and Project Management, because the need for disciplined PPPM has never been higher, and AI is the reason why.
Ungoverned AI development carries a risk profile most organizations haven't reckoned with yet. The closest precedent is one a lot of IT professionals have lived through already: the MS Access phenomenon. A department builds its own database application, off the books, because it solves a real problem faster than waiting on IT. It becomes load-bearing for a critical process. Then it grows too complex to maintain, or hits a technical wall the department can't solve, or the support cost simply becomes prohibitive, sometimes compounded by the original builder leaving, and IT inherits an undocumented, over-customized system it didn't design, can't easily support, and can't cleanly migrate to an enterprise platform, all while the business depends on it running.
Now scale that pattern to AI. The barrier to building something that looks like it works is lower than it's ever been, and the gap between "looks like it works" and "is actually governed, tested, and safe to depend on" is wider than it's ever been. Weak PPPM discipline combined with ungoverned AI development doesn't just repeat the MS Access problem. It accelerates it, at scale, with higher stakes. Governance isn't the obstacle to AI adoption. It's the thing that makes AI adoption survivable.