Meridian Insurance: 68 days for a claim and a nine-month funding gate
Meridian Insurance's claims app is delivered by five teams working in sequence: intake, adjudication, fraud checks, payments and release. A recent value stream map of one claim type showed 68 days from submission to settlement, with about 26 hours of actual work. Waiting accounted for 62% of elapsed time, and there are eleven handoffs. Funding is project-based: each initiative needs a nine-month business case approval, and teams are disbanded at project end. A separate release team deploys changes every three weeks. Customer satisfaction has fallen for four consecutive quarters and claim rework is high. The CIO has asked for a plan to 'go agile' and has budget for two more Scrum teams, but finance and audit are resistant to changing the funding model, arguing that it protects public accountability.
1. How should the team map and measure the claims value stream, and what should they avoid?
Read the worked answer
Map from a real trigger - claim submitted - to real value: settled, paid and the customer informed, including every handoff and rework loop. Measure total lead time, touch time and flow efficiency. Here 26 hours of work across 68 days is roughly 1.6% flow efficiency, so the target is wait states, not faster typing. Build the map with the people who do the work and sample actual claims; documented process usually differs from reality. Avoid boiling the ocean: one claim type, at a level detailed enough to expose the largest queue, is enough to start. Avoid turning the map into an audit or a blame exercise, which suppresses honesty and produces a fiction. Also quantify where defects are found, because rework may be hidden process time. Re-measure after each change to confirm that flow actually improved rather than merely moved the queue.
2. Recommend changes to structure and funding, and justify them with high-velocity IT and digital product concepts.
Read the worked answer
The nine-month approval is a batch-size problem: it pushes the organization towards large, slow, hard-to-stop projects and discourages learning. Fund persistent, cross-functional product teams against the claims value stream, with rolling budgets and outcome guardrails reviewed quarterly, so scope can start small and change. Merge the five sequential teams and the separate release team into teams that own claims end to end - every handoff is a queue and a loss of context. Treat the claims app as a digital product with a lifecycle and a product manager accountable for outcomes, not a project with an end date. Bring finance and audit into the design early, and replace manual gates with automated controls and evidence they can inspect. Use the flow data to make the case: the current model is expensive and slow, not merely unfashionable.