Lessons Learned in Multiple stakeholder projects

Clearer decision rules

•More clarity around decision authority. In production, we had a fairly high incidence of decisions being revisited and overturned.
•Recommendation:  Build RACI chart and establish clearer project milestones and accompanying review sessions

Wing to wing process flows

•Better understand pre and post workflows across Agent, Employee and Customer, no matter who submits the loss.
•Recommendation:  Establish clearer ownership of employee workflow

More effective feedback loop post release

•Multiple avenues for feedback (SVP’s, DSM’s, claims employees, agent portal team, etc. cause confusion)
•Recommendation:  Fully centralized feedback resource for all  questions and commentary, e.g. IT Service Desk; also clear talking points on continuous rapid improvement

Alignment of minimum viable product and continuous improvement

•Initial application design was based on releasing and regularly improving. there was confusion at times around appropriate scope
•Recommendation: Broader discussion around creating a culture where minimum viable is allowable with rapid enhancements based on user feedback? Or do we want to have a larger test audience and longer development cycle to make sure we capture every possible scenario?

Lack of alignment of UAT cycles

•Front and Back End were not on the same UAT test cycles, thereby causing some redundancy and confusion.
•Recommendation:  Aligned UAT cycles

 

Shared priorities

•Lack of clear owner for establishing shared priorities; e.g. front end enhancement needs unavailable backend resources
•Recommendation:  Align work efforts and availability between front end and backend through regular sponsor checkpoint

Minimal feedback received after initial release (during pilot rollout)

•Small agent population during pilot rollout made it difficult to know where improvements could be made.
Recommendation:  More robust group of Agents in higher volume areas for the initial pilot