Skip to content

Project management

AI programs are still projects. They have a scope, a schedule, a budget, stakeholders, risks, and — sooner or later — a phase gate where somebody has to decide whether the model is worth continuing. The two most-cited standards for running that discipline are PMBOK (PMI, US-rooted, principles-and-domains) and PRINCE2 (PeopleCert / formerly AXELOS, UK-rooted, prescriptive processes).

This page presents them as linked method tabs — pick PMBOK once and every tabbed block on the page follows. It also goes deep on CPM (Critical Path Method), because scheduling a mixed data + model + integration + deployment program is where AI projects most often lose weeks nobody planned for.

Sources verified 2026-08-09

The AI-program lens

Three things a general project-management text won't tell you but an AI program manager needs to internalize:

  • The schedule shape has a training-runs-in-parallel notch. Data prep is usually the critical path; training is often parallel with feature-store work; evaluation is a rendezvous where several parallel streams merge and any regression sends work upstream. Naive Gantt-style planning that treats training as one long serial task always overestimates timeline confidence.
  • Uncertainty is model-shaped. The biggest schedule risks are did the eval pass? and did the model hit the KPI? — both binary at gate time, both irreducible until the gate fires. This is why single-point estimates lie; three-point / PERT-style estimates or explicit lognormal-tail modeling (see Ariadne's own approach) match reality better.
  • The kill option is real. The dominant AI-program failure mode is momentum on a model that won't hit the KPI. Both frameworks below provide a formal moment to invoke that option (PMBOK: the Uncertainty performance domain + phase-end review; PRINCE2: "Ensure continued business justification" at every stage boundary). Use them.

The two frameworks

PMBOK Guide 7th Edition (2021) is a principles-and-domains standard, not a prescriptive process — the shift from prior editions (which enumerated 5 process groups × 10 knowledge areas) is deliberate: the standard now describes what a project delivers value through, and leaves how to the team and the tailoring context.

12 Principles + 8 Performance Domains

12 Project-Management Principles 8 Performance Domains
Stewardship Stakeholders
Team Team
Stakeholders Development Approach & Life Cycle
Value Planning
Systems Thinking Project Work
Leadership Delivery
Tailoring Measurement
Quality Uncertainty
Complexity
Risk
Adaptability & Resiliency
Change

The two Domains that matter most for AI programs

  • Uncertainty — the domain most under-invested in on AI programs. It covers volatility, ambiguity, complexity, and risk (positive and negative). For an AI program the irreducible uncertainties are: will the model hit the KPI on the real eval set; will data quality hold; will inference latency fit the budget. The domain's outputs (risk register, contingency reserves, three-point estimates, monte-carlo / PERT planning) are how you convert those uncertainties into schedule and budget bands you can defend.

  • Measurement — the domain that tells you whether the program is actually delivering the value in the business case. For AI programs the "leading indicators" that flow into Measurement are model quality metrics (offline eval on holdout, drift-monitoring signals, canary quality deltas) — the AI-program equivalent of EVM's cost and schedule performance indices.

The classic view still in use

Many practitioners and audit shops still expect the pre-7th edition 5 process groups and 10 knowledge areas as an interoperable vocabulary (especially anywhere a PMO was set up before 2021). Both views coexist — the standard now names them as a models, methods, and artifacts reference behind the principles.

Process groups (pre-7th) Knowledge areas (pre-7th)
Initiating Integration
Planning Scope
Executing Schedule
Monitoring & Controlling Cost
Closing Quality
Resource
Communications
Risk
Procurement
Stakeholder

CPM depth — scheduling an AI program

The Critical Path Method (Kelley & Walker, 1959) is the scheduling technique PMBOK's Planning domain and pre-7th Schedule-knowledge-area both reduce to. Nodes are activities, edges are dependencies, and the critical path is the longest dependency chain — the chain whose slip is the program's slip.

Dependency types (all four legal, all four appear in an AI program):

Type Meaning AI-program example
FS (Finish → Start) B starts after A finishes Feature engineering must finish before training starts
SS (Start → Start) B starts after A starts (offset optional) Ground-truth labeling starts as soon as data ingestion starts
FF (Finish → Finish) B finishes after A finishes Model card must be finished no later than model registration finishes
SF (Start → Finish) B finishes after A starts (rare) Old rules-engine can only be retired after the new model has started serving in production

Here is a minimum-viable AI-program schedule as a CPM network — the red-lit path is the critical path (the chain that determines the go-live date).

flowchart LR
  classDef crit fill:#c62828,stroke:#000,color:#fff,stroke-width:2px
  classDef norm fill:#f4f4f4,stroke:#444,color:#000

  A[Data ingest]:::crit --> B[Data cleaning +<br/>feature engineering]:::crit
  B --> C[Label eval set]:::norm
  B --> D[Train baseline model]:::crit
  C --> E[Evaluate model]:::crit
  D --> E
  E --> F[Integration<br/>inference service]:::crit
  F --> G[Shadow mode<br/>+ backfill]:::crit
  G --> H[Canary + rollout]:::crit
  H --> Z[Go-live]:::crit

  B --> I[Feature-store<br/>hardening]:::norm
  I --> F
  D --> J[Model card +<br/>registration]:::norm
  J --> G
  • The red path — Ingest → Clean+FE → Train → Evaluate → Integrate → Shadow → Canary → Go-live — is the critical path. Every activity on it has zero float.
  • The grey paths (label the eval set; feature-store hardening; model card & registration) have positive float — they can slip somewhat without moving Go-live, as long as they finish by their downstream rendezvous.
  • Blast radius: a one-week slip in "Train baseline model" moves Go-live by one week. A one-week slip in "Model card & registration" moves it by zero — provided it still lands before Shadow-mode-plus-backfill needs it. Float is a resource: use it, don't just measure it.
  • The evaluation node (E) is the classic AI-program landmine. It's the rendezvous where a regression sends work upstream. Estimating its duration honestly (with the three-point / PERT approach the Uncertainty domain recommends) is the single highest-leverage planning move.

PRINCE2 7th Edition (2023) is a prescriptive, tailorable process method organized as 7 Principles + 7 Practices + 7 Processes. The 7th edition renamed Themes → Practices and slightly relabeled two of them (Organization → Organizing, Change → Issues); older material still refers to Themes and the pre-7th names.

7 Principles + 7 Practices + 7 Processes

7 Principles 7 Practices (formerly Themes) 7 Processes
Ensure continued business justification Business Case Starting Up a Project
Learn from experience Organizing (was Organization) Directing a Project
Define roles, responsibilities & relationships Quality Initiating a Project
Manage by stages Plans Controlling a Stage
Manage by exception Risk Managing Product Delivery
Focus on products Issues (was Change) Managing a Stage Boundary
Tailor to suit the project Progress Closing a Project

The PRINCE2 lifecycle as a process flow

flowchart LR
  SU[SU. Starting Up<br/>a Project] --> DP1{DP. Directing<br/>a Project}
  DP1 --> IP[IP. Initiating<br/>a Project]
  IP --> DP2{DP}
  DP2 --> CS1[CS. Controlling<br/>a Stage]
  CS1 <--> MPD[MP. Managing<br/>Product Delivery]
  CS1 --> SB1[SB. Managing a<br/>Stage Boundary]
  SB1 -->|next stage authorized| CS2[CS. Controlling<br/>a Stage — next]
  CS2 <--> MPD
  CS2 --> CP[CP. Closing<br/>a Project]
  DP2 -.-> SB1
  DP2 -.-> CP
  SB1 -.->|kill / re-plan| DP2

  style DP1 fill:#ffe0b2,stroke:#000
  style DP2 fill:#ffe0b2,stroke:#000

The Directing-a-Project process (orange) is where the Project Board makes the go / no-go / re-plan decision at every stage boundary. That decision is where AI-program project managers earn their salary — see below.

The two properties that fit AI programs

  • "Ensure continued business justification" at every stage boundary. Between Controlling-a-Stage and Managing-a-Stage- Boundary, the Project Board must confirm the Business Case is still valid. For an AI program, that's the formal moment to ask "the model isn't hitting the KPI — do we continue?" If the honest answer is no, the framework requires cancellation. This is the single most valuable ceremony PRINCE2 offers an AI programme.

  • Product-based planning. PRINCE2 plans in terms of products delivered, not tasks performed. For an AI program the "products" become the trained model (with its model card as the acceptance criteria), the eval dataset (with its coverage and freshness criteria), the feature store (with its contracts). Every product has a Product Description spelling out what "done" means before work starts — which is exactly the discipline AI programs need to avoid endless "just one more training run."

  • Manage by exception. The Project Board delegates tolerance (time, cost, scope, quality, risk, benefit) to the Project Manager. Only when those tolerances are breached does the Board re-engage. For AI programs this maps cleanly to model quality tolerance: "as long as the offline eval stays above threshold X, the ML team decides which experiments to run; breach X and the Board convenes."

PMBOK vs PRINCE2 — side by side

Dimension PMBOK Guide (7th) PRINCE2 (7th)
Kind of thing Standard: principles + performance domains + models/methods/artifacts Method: prescriptive processes with defined artefacts + roles
Prescriptive or descriptive Descriptive standard, tailorable in every direction Prescriptive process, explicitly tailorable per project
Primary unit The Principle, applied through the 8 Performance Domains The Stage, controlled by the Project Board via the 7 Processes
Where the "kill" decision lives Uncertainty domain + Measurement domain, at phase / life-cycle boundaries The "Continued Business Justification" principle, tested at every Stage Boundary
How it plans Any life-cycle (predictive, iterative, incremental, agile, hybrid) Product-based planning (a Product Breakdown Structure + Product Descriptions before scheduling)
Roles it prescribes None mandatory — the Team domain describes the concept, tailored to the org Explicit: Executive, Senior User, Senior Supplier, Project Manager, Team Manager, Project Assurance, Change Authority, Project Support
Where CPM lives Under the Planning domain (and the classic Schedule knowledge area for pre-7th shops) Under the Plans practice; expressed as a Product Breakdown Structure → Product Flow Diagram → activity network
AI-program fit The vocabulary and structure most enterprise AI programs adopt for their business case, risk register, and measurement plan The governance shell most regulated AI programs adopt (financial services, health, public sector) because the Stage-Boundary review is the model-kill gate
They compose because PMBOK gives the what to plan for (domains) + the how to reason (principles); PRINCE2 gives the how to govern (stages) + the who decides (roles). A common enterprise AI stack is PMBOK vocabulary + PRINCE2 stage gates + agile delivery inside a stage.

The hybrid enterprise-AI stack

A conservative pattern that shows up over and over on regulated AI programmes:

  • PRINCE2 stage boundaries at the outer level, so every Business-Case-review is a formal go/no-go the Board actually runs.
  • PMBOK 7 vocabulary for the risk register, measurement plan, stakeholder analysis, and communications plan — the artefacts audit will ask for.
  • Agile / SAFe / LeSS delivery inside a PRINCE2 stage (see the Scaled agile page) — small iterations, but the stage cannot end until Product Descriptions are met.
  • RUP-style Elaboration + Spiral risk cycling (see the Traditional iterative page) inside the first stage, to retire model-feasibility risk before the Board is asked to approve Construction.
  • TOGAF ADM (see the Architecture method page) providing the architecture repository the stages evolve.

The frameworks are not exclusive — the mature answer is layer them and be explicit about which layer owns which decision.

Ties into the rest of Chiron

  • The Measurement domain's "leading indicators" for an AI program are the offline-eval and drift signals produced by the Observability chapter.
  • The Cost work under the Planning domain sits on top of the Cost chapter's per-token / per-frame unit economics.
  • PRINCE2's "product-based planning" applied to a model treats the model card as an acceptance criterion — the model card itself is generated in the Architecture method page's ADM Phase G governance work.

Where the pillar goes next

  • Scaled agile — scaling AI delivery across many teams (SAFe + LeSS), and how it composes with the plan-driven governance shell above.
  • Roles & archetypes — the capstone matrix.