Vendor Core Banking Replacement with Two Change Windows

Run a fit-gap analysis that classifies each requirement into standard fit, configure, process or policy change, custom build, or defer. For each gap, capture value, risk, regulatory obligation, cost, and dependency on the vendor's two change windows.

Decision logic:

• Regulatory customizations are non-negotiable, but challenge whether the vendor's standard feature plus a control can satisfy the regulator; involve compliance early.
• Many gaps may be process changes rather than software. Model the current and target process and test assumptions with operations.
• For custom builds, compare cost of delay and total cost of ownership against a manual workaround for the first release.
• Sequence change requests to the month 6 window only for items with high value and high regulatory risk; hold others for month 12.

Reasoning: not every gap deserves code. The analysis should reduce custom build, protect the regulator's evidence requirements, and respect the vendor's fixed windows. A decision matrix with explicit criteria makes trade-offs visible to business lines.

Analyse stakeholders before designing the engagement. The refusal may reflect unclear purpose, prior experiences of workshops that produced documents rather than decisions, or fear that attendance implies accountability for a vendor-led outcome. Map each head on influence and interest, and identify what outcome they care about.

Then tailor:

• Hold short, decision-focused sessions with a pre-read and a single question, not day-long workshops.
• Use their own data and examples, such as a lending exception, to make the gap concrete.
• Ask them to nominate a subject-matter expert and a decision delegate.
• Meet one-to-one first; use a champion to bring peers.
• Show how their input changes the change-request list and pilot scope.

Reasoning: agile analysis depends on collaboration, but collaboration is a design problem. The goal is not attendance for its own sake; it is timely decisions and validated requirements. Escalation is a last resort because it damages trust.

Treat data lineage and audit as quality attributes with evidence, not as a final document. Build a lineage model from source field to target field to report, and trace each regulatory report to the business rule and test that proves it. Define auditable acceptance criteria (who changed what, when, and why) and add them to the definition of done.

In the cadence:

• At initiative level, agree the evidence the regulator will inspect and the control points.
• In refinement, attach lineage and audit criteria to each data-moving story.
• In every increment, verify lineage with automated checks and retain evidence.
• At the pilot, run a mock audit on one business line to test the evidence chain.

Reasoning: the regulator is asking for assurance that the new system preserves traceability. A late evidence pack is high-risk because gaps may require schema or control changes. Incremental verification gives early warning and makes the pilot a genuine regulatory rehearsal.