Right now it seems as if every single insurance company on the planet is in the middle of, or about to start, an actuarial modernization (or “transformation”, or “acceleration”) project. Most of them will fail. At the very least not deliver on-time, on-budget, and up to specification. The problem is, projects like this begin with wrong premises, leading to wrong questions and wrong solution selection and design. These compound into inefficient work paths, insufficient models, and Day Two projects that are larger and more expensive than believed when initiating the transformation. Asking the right questions at the outset can significantly improve the likelihood of a successful implementation.
If you start with the wrong question, you are bound to end up with the wrong answer, and fail.
Vincent Granville, Data Science Central
Modernize or die
In the past five years, we’ve seen more wholesale change to the actuarial landscape than in the prior two decades combined. We have principles based reserves in the US, requiring new stochastic models of life insurance to complement stochastic modeling for annuity reserves and capital requirements. GAAP Long-Duration Targeted Improvements is a thing now, requiring significant updates to actuarial models to accommodate more frequent assumption management, results cohorting, vastly increased data storage and analysis requirements, and more. Around the world actuaries, finance professionals, and hordes of IT gurus are working on IFRS-17 standards, requiring yet another plethora of projections and including yet another gaggle of cohorts and corresponding roll-forwards.
Combine voluminous new requirements with the availability of massive processing power through cloud computing, and many insurance companies are seeing the writing on the walls: the old way just won’t cut it. The analysis, reporting, and data storage needs of these new structures have made it abundantly clear that insurers need to upgrade or replace their actuarial models all along the policy lifetime, from pricing to valuation to risk management. As a result, legacy systems have begun giving way to modern actuarial software, which often requires a model conversion project.
However, if these software projects are anything like a “typical” IT project, there’s a better than 50/50 chance they will fail. The Standish Group reports that only about 1 in 3 IT projects is considered “successful”, meaning that they deliver on-time, within budget, and up to specifications.
There’s a good chance that your first deliverables won’t be ready by your first milestone dates dates, unless you are extra diligent to ask the right questions during the planning phases.
There’s an old saying that goes, “There’s no such thing as a stupid question,” but we think that’s wrong. There are some distracting and “old mindset” questions, especially when it comes to evaluating modern software systems. Asking bad questions and assuming they are sufficient is just begging for more time-wasting, money-wasting, headache-inducing delays and rework that actuaries, and their project sponsors, find so infuriating.
Photo by Sara Kurfeß on Unsplash
What kind of “wrong” questions are actuaries asking?
The problem is, most actuaries have superglue-like ties to their current systems. The questions that emerge when evaluating new systems are limited by assuming that the current system is the standard. They ask things like, “Okay, how would we download that data to Excel for analysis?” Or, “How fast is the run time?”
These questions can be distractions and damage the process, because they are anchored in the old way of doing things. You might ask the first question because the old system just didn’t have a robust reporting tool. Therefore, the prior practice was to download a set of data and only then analyze within Excel. But modern actuarial systems have more flexibility and more options than before, because they are designed to take advantage of modern developments like data visualization tool integration.
And the second question is obviously critical to getting answers quickly, because it’s in reference to things like a fixed bank of computing power. That might be a private server or a fixed allocation from a public cloud. So getting answers faster means finding ways to calculate faster.
In contrast, modern actuarial software can be flexibly designed so as to essentially make computing power infinite, rendering the question of “How fast does it run?” almost nonsensical. For example, with distributed calculations across 100 machines, assume it takes 3 minutes up front to distribute the work and another 3 minutes to collect results. Those 100 machines churn for 1 hour, which is a total of 100 machine hours and 66 minutes between [RUN] and results. Now suppose you could access 10,000 machines (or 100,000, or 500,000). In this scenario, your 100 machine hours takes less than a minute on the clock. If it takes an additional 2 minutes on each end for distribution across that many machines, (for a paltry 11 minutes between [RUN] and results), would you really bother to care how fast calculations were running on each of those machines?
These are just two types of improvements that actuaries and their risk committees are actually trying to achieve with modernization projects. If you don’t think to ask questions that expose these advantages, your evaluation will be flawed, leading to a lower-quality decision. So if you’re not careful, asking the wrong questions during selection of new hardware and software can end up perpetuating bad practices held over from prior structures.
Ask Better Questions, Get Better Results
In order to increase the likelihood that actuarial modernization efforts are successful, actuaries, project managers, IT professionals, and consultants should be asking different, better questions. Those questions should be more focused on the desired future state and how transformation projects enable that transition than simple comparisons to the prior setup. As such, the following are suggestions for the practice of either selecting new software and hardware vendors or during planning for the actual work:
1) Plan harder Spend more time up-front in the planning phase of a project, before executing. This is hard for actuaries, who are prone to just jump in and start building a spreadsheet. [Frankly, that’s often not a great idea.] And it’s also parallel to the example above of doing more up-front work to distribute calculations more broadly. Doubling the planning work to cut the execution by half or more, and significantly reducing the chance of overrun, is always a wise investment.
2) Ask better questions Don’t stop at “how can we replicate what we did before?” That’s a limiting perspective. Think about what you want to do – what you’ve always wanted to do, but were hindered before by technological limitations. Design for the ideal case, and then only compromise when you must. It’s like the difference between trying to jump slightly higher than last time, or training to set the world record. Striving for that top will bring you much better results than just trying to get beyond the bare minimum.
3) Consider all use cases If you build to narrow specifications, you will have narrow implementation. Which ultimately is inefficient, as you will eventually need additional functionality and will be forced through the whole process again. Look for ways to design for maximum coverage the first time.
4) Challenge assumptions First, define what they are and ensure that everyone agrees that those are the assumptions. Don’t leave elements unstated, just because you think it’s obvious that everyone knows it. This is a good place for uninformed outsiders (say a new consultant to the team) to be the bad guy and ask everyone to repeat the assumptions, so that everyone can make sure they’re re-aligned.
5) Incorporate a broad spectrum of stakeholders in your conversations Don’t just ask the end users what they do now. Ask their suppliers (upstream), their audience (downstream), and their managers, what kinds of questions get asked, what could be done differently, what’s important, what’s superfluous, and what’s a wildly exciting outcome.
6) Document, document, document! Again, it may seem anathema to actuaries who leave documentation to last, but it’s critically important. Documentation incorporates not only what was decided, but the process by which it was decided, who agreed, when, and so on. More documentation about what wasn’t done can circumvent repetition of wasteful detours down the road.
7) Plan for future upgrades Don’t expect that you will have it exactly right the first time. As such, you’ll want to be able to plan for the future. [Is anyone willing to bet that that PBR, LDTI, and IFRS-17 are the final say in insurance reserving? We didn’t think so.] Incorporate the ideas of adaptability, transferability, and scalability when building, so that the models will long outlive you and your peers.
8) Manage expectations This requires knowing the audience, what they need, keeping them informed of project developments/roadblocks/accelerations, soliciting consensus. In a sense, satisfying emotional, not just technical, requirements.
9) Get Agile It feels intuitive that agile teams (smaller, more incremental deliverables, flexible to changes of requirements as developments emerge, incorporation of end-user feedback early on in the process) will produce a better outcome. In fact, this is how we drive – we don’t point the car at our final destination on the horizon 20 miles away, lock the steering wheel and accelerator in place, and hope to get there in one piece. We start in a general direction and make as many small corrections as we need to along the way to arrive at the right place. We adapt for road closures, congested traffic, even if a friend calls us on the way to ask us to stop and grab a cup of coffee for them too. And it’s been proven: agile projects have almost four times the success rate as waterfall projects, and waterfall projects have three times the failure rate as agile projects. So embrace agile development – not just for actuarial transformation projects, but for actuarial work of the future as well.
Be the actuary you want to be
The challenge question out of everyone’s mouth, when evaluating either new systems or designing procedures in their new systems, should be, “Okay, that’s what we used to do. But what is it we really want to do?”
If you can answer that question adequately (and you will, by planning harder, asking better questions, challenging assumptions, and so on), you’ll be in a much better position for actuarial modernization success.