While assessing data for the ramp computer-vision safety project, Meridian's team discovers that the business question as originally scoped — "detect all ramp safety violations" — is far broader than any available camera footage can support; usable labeled footage only covers baggage-handling zones, not fueling or pushback areas. What should the project team do?
Select an answer to reveal the explanation.
Short Explanation
This is exactly what CPMAI's iterative loop is for. The data just told you the original question was too big — go back, shrink the scope to what the footage actually covers, and come forward again.
Full Explanation
Determining when to iterate back to previous phases is a named Data Understanding competency, and this scenario is the textbook trigger: Data Understanding revealed that the Business Understanding scope doesn't match what data actually exists. The correct move is to iterate back to Business Understanding and re-scope — narrowing the pilot to baggage-handling zones, where labeled footage exists, rather than the full "all ramp violations" ambition. Continuing into Data Preparation on a mismatched scope, hoping camera coverage expands later, is the proof-of-concept-pitfall CPMAI explicitly warns against: building on a foundation the data can't support. Skipping straight to Model Development and letting data scientists informally choose zones based on convenience bypasses the whole point of a structured phase model — scope decisions belong with the business stakeholders in Business Understanding, not as an ad hoc technical shortcut. Canceling the initiative outright overreacts; CPMAI is iterative precisely so that a scope mismatch triggers a phase revisit rather than a project death sentence. This is also a good illustration of why CPMAI is not a strict waterfall: unlike a traditional linear methodology, moving backward between phases is a normal, expected response to what Data Understanding uncovers, not a failure of planning.