A Meridian program office trained in traditional waterfall delivery wants to treat the Model Evaluation Go/No-Go as a single final sign-off, after which the project scope is permanently frozen and no further changes are allowed. Why does this clash with CPMAI methodology?
Select an answer to reveal the explanation.
Short Explanation
Bolting a waterfall-style permanent freeze onto an AI project misses the whole point of CPMAI. Evaluation findings are supposed to be able to send you back a phase — that's a feature, not a process failure.
Full Explanation
CPMAI's foundational Task 1 explicitly frames AI project management as adapting traditional methodologies (including waterfall) for data-centric, iterative projects, and explicitly compares waterfall, lean, and agile approaches for fit. Treating a Go/No-Go as a permanent, unchangeable freeze — classic waterfall thinking — clashes with CPMAI's core premise that evaluation findings (data drift, model drift, missed criteria, changed scope) should be able to trigger iteration, including looping back to earlier phases, both before and after Operationalization. The correct option captures this: CPMAI's Go/No-Go gates are decision points within an iterative lifecycle, not the kind of rigid, irreversible sign-off a strict waterfall model assumes. Saying CPMAI recommends exactly this rigid approach is backwards — the methodology exists partly as a corrective to that mindset for AI-specific projects. Claiming CPMAI has 'no opinion' overstates its neutrality; it explicitly evaluates methodology fit and favors iterative approaches for the reasons AI projects differ from traditional software. And CPMAI does not require restarting the full six phases after every checkpoint — iteration is targeted and findings-driven, returning only as far back as the root cause requires, not a blanket full restart every time. The exam point: CPMAI's iterative philosophy is a direct, intentional contrast to rigid waterfall sign-off culture.