A city is replacing a CRM that failed after go-live because payment workflows and case statuses were poorly defined. Before drafting new requirements, what should the business analysis effort do with lessons from that failure?

When a city replaces a CRM that failed after go-live because payment workflows and case statuses were poorly defined, business analysis should mine prior lessons learned as elicitation inputs before drafting new requirements. Those lessons turn expensive history into concrete failure modes—ambiguous status models, payment-path gaps, unclear handoffs—that the replacement must address. Civic IT replacements that ignore prior postmortems tend to repurchase the same defects under a new logo.

Archiving the prior project folder and starting elicitation with a blank template fails conceptually because “avoiding bias” by erasing history discards validated knowledge about what broke resident-facing payments and case handling. Converting every complaint into a mandatory nonfunctional requirement without triage fails because unfiltered complaints mix noise, duplicates, and preferences with true must-haves and inflate scope without analysis. Waiting until the new vendor is selected to ask which lessons still matter fails because vendors optimize delivery; the city owns residual risk and must shape requirements from its own failure evidence first.

Exam caveat: Lessons learned are elicitation inputs for CAPM-aligned analysis, not optional reading after requirements are already frozen. Operational check: extract payment-workflow and case-status failure themes from the prior CRM lessons register, turn them into candidate requirements and acceptance checks, and review them with sponsors and clerks before vendor configuration workshops.