Infusing Business Analysis Into the Product Lifecycle the Key to More Effective Insurance Product Development

Home , Business administration, Product lifecycle

RG Perspective

Infusing Business Analysis into the Product Lifecycle The Key to More Effective Insurance Product Development

Infusing Business Analysis in the Product Lifecycle

Common wisdom holds that a company that's six time constraints and the tendency for each months late with a new product stands to lose a constituency to view the problem from only third of its market share. their point of view, make this task a significant challenge. It’s a classic case of “We spend months carefully analyzing the market and the elephant and the blind men. designing our new products. But often, when we make  The inability to predict the impact of the decision to go ahead, we run into a wall – IT tells us the product across the organization. that our existing systems can’t be changed to To be successful and timely, your product accommodate what we need or Claims tells us that development process should work to avoid they can’t have product manuals ready in time for the unexpected. It must account early on launch.” for changes that will need to be made to … Marketing Director in a mid-size insurance company operational processes such as new business and claims, and it must also have a good To ensure an insurance organization’s growth and estimate of the enhancements that will profitability, the ability to bring new products to need to be made to supporting systems. market quickly and accurately must become a key The basic question: are those changes big core competency. In fact, it is the lifeblood of any or small? Will any new roles need to be insurance company, and the single most important created to carry out changed processes? facet in a vibrant process of continuous product Will current systems be adequate? Or will renewal, strategic growth, and robust profitability. you need to make significant enhancements This means creating a product development cycle or even develop something new? whose delivery capabilities are measured in  The inability to leverage knowledge months, not years. But for many this goal seems assets. Most organizations do not like a pipe dream; instead they continually deal comprehensively capture knowledge related with the costs of rework and lost opportunity. to processes, systems, roles, and products from current product development efforts in 1. The Cause a manner that can be leveraged on future While there may be multiple causes for delay, new product development projects. This some of the most significant include: results in less effective management of cost, schedule, and quality risks.  Lack of communication and common vision. The development and rollout of a The Solution product impacts virtually every area of an organization – from home office to We believe the solution is to infuse Business distributors. Constraints imposed by Analysis competency into the product external stakeholders, such as licensing development team on a full-time basis – a requirements or state regulations, and the Business Analyst can help bring order into the need to conduct actuarial analysis sometimes chaotic product development process complicate the product development and can serve as the glue that binds the team process even further. The multiple throughout the entire lifecycle from product stakeholders need to communicate formulation to launch. effectively to build a common vision, but

Infusing Business Analysis in the Product Lifecycle

2. Why is Business Analysis Key? In recent years, the role of Business Analyst has been emerging as a uniquely-skilled individual, Business Analysis, and the role of a Business capable of playing many important roles. But how Analyst, can mean different things at different does this play in the product development organizations. For some, a Business Analyst is process? This process typically consists of five focused specifically on a particular system and its requirements – a very IT-oriented role. For major stages as shown in the figure below. others, a Business Analyst means someone with Business Analysts understand development particular business subject matter expertise, for lifecycles and follow a disciplined lifecycle example, an individual who knows all about claims approach themselves. And Business Analysts are processing. perfectly positioned to communicate with all the For us, a Business Analyst combines many skills – stakeholders in order to build a common vision for spanning business-level knowledge to writing the new product and to develop re-usable and detailed system requirements – into a unique extensible business architecture assets to support capability to capture and to communicate current and future product development projects. knowledge. Business Analysts are skilled at: Business Analysts are increasingly recognized as providing unique value to an organization. As testament to this fact, the International Institute  Eliciting information from all organization of Business Analysis® (IIBA), an organization levels and all stakeholders founded in 2003, has developed a Business  Facilitating information-gathering meetings Analysis Body of Knowledge (known as the across organizational groups and serving as BABOK®), which is continually expanding and the ‘glue’ among those groups being improved. BAs can become certified 1  Facilitating the communication among through this organization as well. The IIBA stakeholders to build consensus and to definition for a Business Analyst is one that we define the solution feasibility and scope completely support, though we would add the word “products” to the end of the sentence.  Documenting, organizing and presenting multiple perspectives of complex “A business analyst works as a liaison among information to enable better, more timely, stakeholders in order to elicit, analyze, decisions communicate, and validate requirements for changes to business processes, policies, and  Analyzing and reconciling requirements – information systems.” for process changes as well as for system changes Finding Opportunities for Improvement  Making information available and easily In our work with improving the product understood development process, here are a few of the specific challenges we’ve found:  Tracking changes and ensuring consistency  The Product Specification document is not  Creating a knowledge repository of assets, always clear. enabling re-use for updates and for subsequent projects

1 See www.theiiba.org

Infusing Business Analysis in the Product Lifecycle

 Priorities are unclear; this becomes Product Formulation Phase especially problematic if the field and the The team worked on two streams in parallel home office have conflicting priorities. during the product formulation phase.  Input from the field is often anecdotal. One: Building Product Understanding  Operational process managers (for example, Every product has certain characteristics that must Claims Processing or the Call Center) are be understood. In the past the company had often caught unaware of the changes they outlined the product rules and riders and benefits need to put in place to support the product. in spreadsheets or paper files. Once implemented  IT realizes too late that system changes will the information was often buried in lines of code be major. To invest time and effort in across multiple systems. product analysis and development, only to This time they decided to take a more systematic be stymied by systems that won’t support approach with a view to building a consolidated the need, is frustrating, to say the least. knowledge repository of product information that would grow over time. They determined that they All can be grouped into a series of risks and then needed to know: traced back to the root causes we identified at the  The product’s components. In most cases, beginning of this article. We believe that using a a product is built from a set of components Business Analyst professional armed with best that can also be used by other products. practice techniques can serve to mitigate these So the product under study might be made risks. up of other products or of riders. In turn, the new product might one day become a 3. One Company’s Story component of a larger product. An insurance company with expertise in individual  The product’s rules. There are typically products sold through employers, decided to many rules for a product and it can be investigate offering a new line of products in the useful to put them into compartments, such group arena. They felt they had a good as underwriting rules or eligibility rules or understanding of their market and solid state exception rules. Because of the expectations that their existing employer groups component structure, rules can apply at the would be good candidates for the new products. lower level or at the top level and it is They ran a number of focus groups to evaluate important to ensure that the rules are the appeal of the new product. Their next step internally consistent. was to formulate the product structure and rules,  The product’s roles. In other words, who and then to develop a strategy for it. They had can participate in the product – Owners? found in the past, however, that their ability to Insured? Payees? predict the magnitude of changes required to support the product – both in systems and  The product’s events. What happens that business processes – was often far off the mark, might affect the product? Do you need to which resulted in being late to market. be able to cancel the plan? Do you need to be able to add a new employer group? Identifying the events that will touch the

Infusing Business Analysis in the Product Lifecycle

product can help you focus on what  Reinsurance – set reinsurance limits and business processes might need to change pay premiums as well as on what systems should be  Call Center – provide support to the policy examined to ensure that they will support holder (for example, change the address on the required processing. the policy) The figure on the next page illustrates relatively  Claims – process claims simple product model architecture for Personal Auto with components, sub-components and rules.  Financial – handle reserves; handle billing; Behind the symbols on the diagram, the Business handle compensation Analyst captured complete documentation of all  At the bottom of the diagram, they showed important product information – eligibility, the systems that were involved. That way, underwriting rules, forms management, pricing, they knew immediately what systems would etc. Together, these were stored in a repository be impacted should a process need to that would become the single source of truth of change. As one product manager put it: product data for different functions across the organization – from marketing to claims to IT “Particularly in the case of products that development. The diagram made it easier for the represent new lines of business, but equally product manager and other stakeholders to assess useful for traditional products, how well the product’s structure and ensure it contained current workflows meet the requirements of a what was required. new business or product are key to the successful introduction and support of those Two: Building Process Understanding products.” Hand-in-hand with building product understanding, the team realized that they needed What were the benefits of using these product to understand what processes came into play architecture modeling and process analysis during the life cycle of a product. So they built a techniques over how the company had previously high-level map that showed all the groups attacked product development? involved and what they did. The following groups were identified: (1) Thinking about the product in a systematic  Product Development –assess market way – its rules, its events, its roles, its requirements and formulate the product calculations – made the process more  Marketing – create collateral and implement focused. The team used a Business Analysis a marketing strategy facilitator both to elicit the required information and then to document it. The  Product Services and Sales Support – facilitator was also responsible for building support the agents and brokers the diagram representing the product  Sales – identify prospects and sell product architecture. Everyone agreed that having the diagram made the product’s construction  New Business Administration – process visible and, therefore, easier to discuss and applications change. It also provided a means for  Underwriting – underwrite applications communication and collaboration among the team members.

Infusing Business Analysis in the Product Lifecycle

Having this information available and trusting the (2) The product – its architecture and the rules it information’s accuracy meant that a better would use – was documented in a repository. decision could be made. This was the most If additional riders, benefits or components important benefit of the new process. needed to be added in the future, there would now be a single source for that Product Implementation Phase information. Once the decision is made to go forward with the new product, the next phase involves actually (3) Focusing on the product life cycle and developing the product and implementing the building the life cycle map clearly showed support it needs – enhancing systems, creating what business processes would need to be marketing materials, hiring agents, changing the examined and what supporting systems might process, and so forth. need to be enhanced. This set the stage for The work that had been done during product the implementation phase of the project. formulation positioned the company in the

following ways: (4) Performing business process analysis on all the operational processes built a base of  The People-Process-Technology maps process flow maps. These could be saved in could be re-drawn to show exactly where a repository and, for any new product changes would affect the process and, by development effort, could be analyzed to extension, whether new or different roles identify areas of change. would be required to support the process. For example, up to this point, all insurance Completion of the Product Formulation applications had been submitted directly Phase from an Agent to the New Business The decision of whether to go ahead with a new Administration area in the company. product was made by a strategic-level group. However, with the new product, there Many considerations of course come into play to would be a need to establish a “Case make such a decision – commission structures, Level Team” that would be responsible financial risk, and so on. But, in addition, this within the company for handling any time the team could answer questions such as: issues with the group.  What kind of an impact will this product  The product architecture models make on our current business processes? contained all the rules that would need to be implemented in the supporting  Will we need to hire internal staff with systems. This meant that much of the different skills to support it? work of specifying what would need to be  Can we use the same agents as we developed in the supporting systems could currently have? be re-used.  What changes will need to be made to our  The business requirements and system systems? enhancements that were identified  How much time and money will these provided the foundation for detailed changes cost us? requirements for technology initiatives.

Infusing Business Analysis in the Product Lifecycle

These more detailed requirements processes, on the product specifications and on consisted of: the intended use of supporting technology.

 System use cases and use case flows The Results  User interfaces Perhaps the most important result of the o Data requirements enhancements to the product development process was the company’s ability to make a o System interfaces better go/no-go decision on whether to bring the o Business rules product to market. In addition to the market With detailed requirements in hand, system research they had always done, they now had enhancements and the acquisition of new software information on the kinds of changes they would to support the product needs could begin. Once need to make to support the product and could the systems were developed, marketing materials factor those costs into their decision. were in place, new hires had been made and the Equally important, the requirements generated for processes redesigned, the product could be rolled the future state formed the basis of the product out. specifications that became the delivery vehicle for Importantly, the Business Analyst was still an IT’s product and systems specifications. Here the integral team member and could carry the company saw how the requirements could serve knowledge gained during product formulation multiple purposes and compress product forward to the implementation phase. Team introduction timeframes. members who joined at this point in the project But another benefit – perhaps not quite so easy to used the Business Analyst as a trusted information quantify, but just as recognizable – was the fact source. The Business Analyst served not only to that the assets from the project now existed in a develop detailed requirements, but also to be the repository. The requirements, workflows and go-to individual when the design and build teams overall process models were documented in an had questions or needed more information. on-going living data and requirements repository, Launch Phase available for use for the next product development All the work that had come before could be re- effort. In a way, these requirements became the used now. For example, the to-be People- reusable code of the business and product Process-Technology maps provided the basis for development process and, as such, the product training materials and for online “coaches” that architecture models, the process models and the would help guide staff in the new processes. And requirements were tangible company assets, the product models, including all the rules, roles, ready to jump-start future process improvement calculations, and components, were used to undertakings. Such models laid the foundation for generate the skeleton for product manuals. This a library and formed a solid basis for product made the completion of these manuals much development optimization through a solid quicker and more accurate. understanding of requirements and business process models. As before, the Business Analyst played a key role during this phase by providing input on business All agreed that without the full-time commitment of a strong, professional Business Analyst, none of

Infusing Business Analysis in the Product Lifecycle

these benefits would have been realized. It was the Business Analyst who, through elicitation, facilitation, documentation and communication skills, was able to bring all the stakeholders together to build a common vision for the product and to move forward with confidence that needed changes to processes, systems and roles were well-understood.