A traditional-software project manager new to Meridian's customer-service virtual-assistant initiative insists on committing to a fixed go-live date and an exact accuracy target before any data has been reviewed. What key methodological difference is this PM overlooking?
Select an answer to reveal the explanation.
Short Explanation
You can spec a login form on day one. You can't spec a model's accuracy before you've even looked at the data — that's the whole reason CPMAI front-loads Data Understanding before commitments get made.
Full Explanation
AI projects differ fundamentally from deterministic software because their achievable performance is a function of data that has not yet been examined, not just a function of engineering effort. Committing to an exact accuracy figure or a fixed date before Business Understanding and Data Understanding are complete is a category error — it treats an empirical, data-dependent outcome as if it were a specification that can simply be built to. Option A misdiagnoses the difference as merely more testing time, which understates the issue: it isn't that AI needs longer QA, it's that the achievable outcome itself is unknown until data is explored. Option C is an unfounded generalization; relative cost varies by project and is not the defining methodological distinction being tested here. Option D is simply false — AI projects still require requirements/business-question framing, just adapted (see DIKUW and scoping practices) rather than eliminated. The correct framing is central to why CPMAI recommends an iterative approach: initial estimates are refined as Data Understanding findings come in, and premature fixed commitments are a leading driver of stakeholder disappointment later in the project.