My Experience of Leading a BA Practice of an Insurance Company

In my career at one point when I was working for a global insurance giant in their Sri Lankan entity a very interesting opportunity opened its doors to me. That is when the leadership was planning to work on the largest IT transformation project in the history of the company. And the vision/need for the program was only there when it came to me and my Senior manager. The challenge is that it is open-ended. It's our responsibility to strategize this change.

We had to,

1. Identify the business, their dependencies, and what they want. Even this is at the enterprise scale as this affects all the lines of business in the company's general portfolio.
2. Understand the nature of the change the company and the departments actually need.
3. Align, and evaluate the outcomes of these studies with the vision created.
4. Align senior leadership across the company with a common vision.
5. Create a road map for the program.
6. Understand the resources needed for the change and find the resources gap.
7. Identify technological hurdles and bottlenecks of this scale change.
8. Communicate about the change across business units we are going to work with and align them, get their support, and build trust.
9. Design a proper project/ program management process for the change.
10. Onboard the business analysts, train them, and make them ready to take on this change initiative.
11. Design business analyst practices from the start of the initiative till the very end, which can tackle the complexities of the program, which are of the highest standards in the world.
12. Innovate.

You can see the opportunity I got to lead the BA practice came with this full enterprise-level change initiative, and it was not just to revamp or improve what's there. For this initiative, the leadership is ready to put in the full effort and all the resources that the IT department has or gets from outside. The challenge is new and the context is complex, this needs some thinking and innovation.

Innovation in an Insurance Company

We had to innovate to define the odds and to tackle the complexities with the architecture and the product that we were working on. We became the first financial institution in Sri Lanka to adopt Google-style Design Sprints and expand it into enterprise-scale design thinking. Thinking from the shoes of the customers and the end users not to outshine ourselves but there was the need for the stakeholder. We adopted persona development and empathy maps for our requirement elicitations. Thought about the transition of value from business requirements to end users then transferring them into customers through creating STP (Straight Through Processes) integrated with core platforms to enterprise solutions.

Insurance companies consist of multiple processes according to the products across multiple departments like Underwriting, and Claims which are linked with channels like Banca, Broker, and branch network. Also, there are a lot of dependencies between each unit and process that interlink, and even done by different hierarchy levels. Those are properly discussed, understood, and mapped using BPMN. As we were mapping and understanding the full enterprise for an enterprise-level change initiative.

Worked on the architecture change that's going to happen across the entire application network of the organization with the architects and got things cleared with regional architects. Then when designing the approach and process we adopted agile in a different way that suited our goal and context. Just like agile was being used through the Scrum of Scrums, Nexus Model, or the Spotify Model we innovated a new model and called it the F1 model based on performance, behavior of Formula 1 teams, and the F1 championship. Following is an article I wrote about some features of adopting an F1 model derived from the foundations of Scrum. Later I'm hoping to write a full article about the F1 model for agile development. (Will see!!)

Article - Why we name our scrum teams with Formula 1 names!

Then we approached all these in a way that blends with scaling agile in a model similar to SAFe because if it was not done properly the output from design to development + Quality Engineering + User acceptance + Production flow cannot be created for the complexity at our hand. It would be easy to implement a CI CD pipeline and DevOps on the line. With the correct in place, we will be able to identify funnels in our workflows and remove bottlenecks to value delivery. It will help to work on the value streams and tackle dependencies. This plan was a full upgrade of the SDLC to handle this program in the future.

We improved the tools we used for requirement management and design with state-of-the-art in the process. If someone told me you can't innovate in an insurance company, it can be done, if you understand the need, needed change, solution, context, and your stakeholders properly, and put your mind and thinking into it.

Working with the Business and Strategy

The Business Analyst of the program sat together with the business stakeholders of different lines of businesses across the entire general portfolio according to a stakeholder management plan and understood their business processes. And here the BA worked as a consultant. Mapped the full as-is process and understood node after node for pain points and opportunities in the workflow by following process mapping with user journey maps. Mapped all the departments according to phases of value delivery in Miro and managed business analyst information. Kept the communication moving forward to understand value streams and value that can be generated in a to-be process. Then mapped a to-be-process. Worked on the innovation of the product with Design Thinking activities, getting the business users involved throughout these activities and making them feel this solution that is being designed is one of theirs. After that work with all stakeholders to identify architecture, vendors, and solutions to work on design artifacts with business units and the Program manager.

Before starting all the activities we made sure that we bonded with the stakeholders we were going to work with in the program, and had multiple sessions to communicate about the change initiative and mentally prepare them.

Same with getting the support of the high-level leadership of these departments. When a department is aligned with us, we involve them in our work and get their support in the next session with other departments. Hence make others trust our approach and understand from what we are coming from.

As we worked on strategy and understanding where the business wanted to be in 5 years time with the change we are introducing, we even started working on the change management also at a very early stage. And take the message to everyone in the departments and create a buzz about it.

In my opinion, working inside an insurance company helped me and my team to carry out all this work properly. After getting the heads, and management, to the bottom of the hierarchy aligned, we were able to act the role of a detective at one time and a doctor at another working closely with business stakeholders with direct contact and investigating their processes, pain points, and where to look into to improve.

For these, we had agents, sales managers, underwriters working with different products, claim handlers, and call center users as well as people from Re Insurance and Finance departments working with us. You need these communications and collaboration as we speak about the full product life cycle with all the other functions, and customer triggers that support it coming into the picture (As we had mapped in BPMN). As an example, a simple Fire product will have New business, Policy processing, Renewal, amendments, and inquiry flows that span across different departments and can become inputs to Claims processes when designing a system. All these stakeholders were with us all the way sharing all the excitement in all the activities from process finding to design sprints. And build some very good bonds that would last a lifetime.

Meanwhile understanding the exact root causes, improvement points, a solution, a five-year target, milestones, and an approach to finalize with.

Leading Business Analyst Practices

At the starting point to do these, I didn't have a BA team or BAs, and with the budget for BA resources, I was able to get interns or associates to do this work. And yes by interviewing interns, onboarding them to the program, and getting associates we did all the above, and built a BA unit of close to 20. I made them train with me on all these practices. At the start, I made their work, session heavy but enjoyable for their age. Then give them hands-on little by little, keeping in mind the question "If things go wrong" as we were working on important requirements.

Teach a Practice -> Give Example -> Let them look at me working -> Give hands-on -> Get them into simple tasks -> Let them discuss them and how to use them in the program -> Increase work little by little to an advanced level.

Likewise, build a complete BA unit that works with advanced techniques in very complex change initiatives. We even went into the levels of BABOK and analyzed purpose and tried out techniques whether they would suit us. We started working on our requirements architecture by understanding the viewpoints. Introduce latest tools in the world and did sessions and made them do sessions about them and used for the program.

We used the advanced user stories/requirements writing techniques to get the team used to connextra format, the concepts from extreme programming. They learned to make the viewpoints of requirements architecture rich with data models, ER diagrams, Functional decompositions, Hierarchy models, Ecosystem maps, and many more according to the need. Maintained them and built conversations upon them.

Then using prototyping to bring the solution quickly to the end user to evaluate and start a learning mechanism. As said design thinking had been embedded deep into the practices as there was a need for that according to end user and customer pains.

As you have seen it had been some exciting work that went through and for the chances given to me at that time, but a single article will not be enough to go in-depth and cover the full length of everything that I had the experience of working at my time with the insurer. But my recommendation is that if you had been there working inside a bank, insurance company, or any other business-focussed institution as a BA there is a different array of things that you will learn and understand.

Then if I summarize my experience of working in an insurance company and being a Lead BA there, would be that it helped me to be close to where things really happened, at the core of the domain and people. Gave me the opportunity to build connection with multiple stakeholders directly, to work with their front ends, design solutions to their challenges with the team I had, blend practices to get the highest value for their time, then share laughs in our design sprints, enjoy workshops and chip bags together, building everlasting connections that add to the benefits of becoming a Business Analyst, which made me learn the hidden gems of this profession.