Architecture for Insurance Claim Assessment Software

Architecture for Insurance Claim Assessment Software

My client was a New Zealand Crown Financial Institution (CFI) that provided insurance cover for residential land, contents, and buildings damaged by natural disasters.

Problem – Business Need

We had 587,000 insurance claims to assess. The paper based process,  manual costing for scope of works, and manual claim data input were causing a bottleneck. The business decided to transition to electronic assessments using iPad.

I was asked to design the process architecture and cost calculation database for the new software.

  • The software must be able to assess damage to houses built since the 1800’s.
  • The software must produce accurate damage assessment
  • The software must produce a fully costed scope of works to be used as a basis for claim settlement

Solution

We de-constructed a house into 28 features, 91 attributes, 470 types, 370 materials, 534 damages, 7 measures, 505 repair strategies. We built a database of 25,400 cost calculations. We delivered a software assessment framework that enabled the field work force to accurately assess damage to properties built any time within the past 150-200 years.

Process

I put together a team consisting of one data analyst and two certified builders who had business analysis experience.

  • Identified and analysed stakeholders who would be involved in the analysis and solution delivery process.
  • Conducted various elicitation sessions with field staff, department heads, executive leaders, and the software development team to defined the current and future state business descriptions.
  • Documented preferences list of features that were decomposed into user stories.
  • Elicited, analysed, and specified requirements and designs.
  • Developed the high level framework and gain agreement from all stakeholders on the framework as the foundation for the solution.

I created a Kanban board, refined the backlog items with my team. We agreed on a one week iteration cycle. We had daily stand-ups. On the last day of an iteration key users would review the completed user stories, and I documented their feedback.

Highlights

Business analysis work was carried out throughout the project in collaboration with stakeholders and my team.

Requirements elicitation, analysis and design were performed on just-in-time basis. The solution was evaluated on a continual basis to ensure deliverables meet business and stakeholder needs.

My team led the user acceptance testing. We wrote the software user manual. My team grew to 25, over a four week period we trained 1600 contractors in groups of 100 to use the software.

We followed that training up with 12 weeks of support in the field, one on one training, training for small teams (20 contractors), and we presented Q&A sessions for 200-300 contractors at six different field office locations.