In a Phase III retrospective, Meridian's loyalty-fraud team describes how they spent three weeks reconciling mileage-redemption records across two legacy account systems, resolving conflicting customer-ID formats, and building a single unified feature table before any model training began. Which real-world CPMAI Phase III pattern does this best illustrate?
Select an answer to reveal the explanation.
Short Explanation
Anyone who's actually run an AI project will tell you: reconciling legacy systems and building a clean feature table almost always eats more calendar time than training the model. That's the norm, not a red flag.
Full Explanation
A recurring, well-documented real-world pattern in CPMAI Phase III is that data preparation — reconciling inconsistent legacy systems, resolving conflicting identifiers, and constructing usable feature tables — routinely consumes more project time and effort than the Model Development phase that follows, because messy organizational data is the norm, not the exception, and reconciliation work scales with how many disconnected systems exist. Reclassifying this as Data Understanding misreads the phase boundary: Data Understanding is about assessing what data exists and whether it's usable, while actively reconciling records and building a unified feature table is transformation work, which is Data Preparation by definition. Concluding that Business Understanding was skipped is an unsupported leap — nothing in the scenario suggests the business question was never scoped; heavy data-prep effort is common even on well-scoped projects, precisely because organizational data debt exists independent of how well the business case was defined. Calling three weeks of legacy-system reconciliation "over-investment" misreads what's typical: for a fraud-detection use case spanning two legacy account systems, that level of effort is closer to expected than excessive, and this is exactly the kind of pattern PMI's outline flags for recognizing real-world Phase III implementation examples.