In the last seven years, the use of agile methodology across the insurance industry has gone from zero to 90 percent. The agile model, a newer software development approach, involves more collaboration throughout the project, flexibility in requirements prioritization, and ongoing coordination between IT, end-users, and business stakeholders. This is more than simply a shift in IT project planning; it’s a broad cultural change.

Embracing a more flexible prioritization process and the willingness to let go of a complete requirements document signed off by several levels of stakeholders is no small sacrifice for many industry leaders.

At the same time, despite the fact that nearly all insurers use agile for some projects, very few use agile for all projects. The strictly-phased waterfall approach still has just as large a presence across the insurance industry. (The waterfall model, the most common software development process at insurers for the last few decades, involves a structured series of distinct phases including requirements, design, implementation, and test.) Though in some cases the large and distributed nature of many insurance companies may be the reason for differing methodologies, this is not simply a sign of insurers being slow to adopt agile throughout their whole organization.

In fact, many insurers have found that some projects work better with varying approaches and intentionally plan accordingly. While there are many “agile purists” out there, rational leaders pick and choose elements that work for their organization. A new portal dependent heavily on end-user feedback is a more obvious target for an agile approach than an upgrade to a COBOL-based legacy core system where all the requirements are known well in advance.

The values of agile have been much discussed in and out of the insurance industry and based on the widespread adoption clearly don’t need to be reiterated. More interesting, however, is how insurers who really embrace an agile approach are finding value and cultural impact that goes beyond the typical story. In fact, insurers are seeing a properly implemented agile strategy create better relationships between IT and other business units, one of the long-standing tensions in the industry. In order to understand this, we need to look at how insurers have been experimenting and struggling with the best way to organize IT within the company for the last two decades.

End user satisfaction and relations between IT and other business units are at the heart of the Centralization v. Federalization Cycle, which Novarica has written about in previous reports.

A federated organizational structure for IT gives each business unit or line of business its own engineering staff focused exclusively on its priorities. This is how the majority of insurers approached IT ten years ago. It resulted in very close relationships between subject matter experts and the engineers building business-specific applications. Tt meant that software developers often became business experts themselves, very closely tied to operations and understanding requirements at a deep level. However, it meant a lot of duplicate effort as many different business units tackled the same kinds of projects (each building their own similar set of agent tools, for example) and it resulted in engineers of varying levels and skill all relearning the same lessons independently.

Over the course of the next decade, in order to get better process, best practices, and cross-company prioritization (not to mention cost savings), some companies centralized IT. While it is no means universal, the majority of insurers today have some form of central IT organization, or, at insurers that sell both L/H/A and P/C lines, two central IT organizations. The upshot, however, is that one IT group supports multiple lines of business and supports multiple functional areas (distribution, underwriting, claims, etc.) rather than independent groups.

From a top-down view, this centralization of IT has had great results. Among other things, it has allowed executive leadership to look at all technology projects across the organization and prioritize (or de-prioritize) them appropriately. If work on one particular project takes precedence over everything else, than the IT organization is prepared to shift the majority of resources to that single major initiative.

But, as one can imagine, this centralization often leads to lower business user satisfaction, because the direct relationships between IT and other business units are diminished. And while it might be the right choice for the company as a whole to make certain priority decisions at the cost of others, that’s no great comfort to a business stakeholder who needs to wait half a year for their small project request to be considered. Over the last decades the amount of work that insurer IT groups are accomplishing has grown tremendously, and the systems in place at insurers today do orders of magnitude more than they did before. The industry has moved just about everything into online portals, created broad digital processes with significant advances in straight through processing, leveraged data warehouses and predictive models, and undertaken countless multi-million dollar core system modernization projects. Yet as the strategic value of IT has rocketed, the relationship and trust between IT and other business units has, at many insurers, gotten worse.

The over dependence on the waterfall methodology is partly to blame. The waterfall phases, in some ways, create an artificial wall between requirements gathering and implementation. In a federated IT model, where software development staff maintain closer relationships to subject matter experts and a deeper understanding of the day-to-day business, the people implementing the requirements know enough to question and push back on problematic requests. But a centralized IT organization often stifles some of the deeper business knowledge making, and that artificial waterfall wall becomes a real wall, where IT implements faulty requirements without even knowing it. When the project is finally released and the business users are unhappy with the results, fingers get pointed and no one wants to take the blame because the blame really lies with the approach.

Enter agile. One of the values that agile brings to an organization is that it formalizes regular stakeholder review and involvement with IT projects, helping to lift the transparency and recapture some of those values from the federated organizational structure. Stakeholders and subject matter experts are devoting the time to review and adjust a project on one or two times a month, involved in the ongoing effort in a way that hasn’t been true for a decade. Agile recognizes that there is no such thing as an “IT project” and readjusts the culture to focus on a business projects that require IT. One doesn’t need the agile methodology to capture this tight integration between IT and other business units–plenty of insurers have found similar success in their own modified waterfall approaches–but agile has helped many insurers by bringing in a formalization of exactly this kind of relationship.

In the end, an agile approach doesn’t make complicated IT initiatives any less complicated or any easier to plan and budget. But this heavy involvement between IT and other business stakeholders means that even if a project has problems or misses a deadline, the overall satisfaction is still often higher. Ask insurance leaders whether they’d prefer (a) a project to be successfully completed on the expected date and on budget but to have little insight into progress up until that final delivery, or (b) a project to run over budget and deadline but with great transparency and communication throughout. They will almost always choose the second option, especially because a major IT initiative finishing on time and on budget is so rare as to be a myth. Instead, the agile methodology recognizes that perfect prediction of time and budget is impossible, and instead treats these initiatives as an ongoing collaboration between IT and business stakeholders, redefining what it means to be a successful project.