Procurement prefers a predictive baseline for a contractor-built 311 mobile app, while product owners worry about discovering the wrong features late. Which statement best reflects that trade-off?
Select an answer to reveal the explanation.
Short Explanation
A predictive baseline is a sturdy contract fence for the 311 builder — clear enough to bid and schedule — but you might find the wrong ticket types only after most of the fence is up. That late-discovery risk is the classic trade-off. Skipping baselines or claiming perfect features without learning misreads predictive delivery.
Full Explanation
Procurement often prefers a predictive baseline for a contractor-built 311 mobile app because a stable scope, schedule, and cost baseline supports bidding, contracting, and long-horizon planning. The corresponding trade-off is late discovery risk: if citizen needs for ticket types or workflows diverge from the locked design, wrong features may surface late when change is expensive. Product owners worrying about that discovery lag are highlighting a real predictive limitation, not ignoring the contracting benefit.
Saying predictive never needs a baseline and always maximizes mid-build learning fails conceptually because baselines are central to predictive control and late feedback is a known drawback, not a strength. Saying predictive forbids contractors from ever receiving a scope document fails because contractors typically receive clear scope precisely through predictive planning packages. Saying predictive guarantees every feature will match citizen needs without testing fails because a baseline does not by itself validate user fit.
Exam caveat: Associates should state both sides of the predictive trade-off—contracting stability versus delayed learning—especially on civic apps with contractor delivery. Operational check: if procurement locks a 311 baseline, add explicit validation gates or hybrid feedback increments where possible, and ensure change control is ready when citizen testing reveals misfit features.