Excel Is Not the Culprit

How actuaries use technology has had unintended consequences Bryon Robidoux July 2021

There has been a lot of talk about whether Microsoft Excel is the most effective tool for actuaries. This was on full display during the Society of Actuaries (SOA) webcast, “The Great Excel Debate,” when I argued against its use. I have also written many articles discouraging the use of Excel by actuaries.

But as I reflect, I think focusing on a particular tool is way of underestimating the real arguments and problems at hand. This article will show how Excel is a massive signal of a problem, but Excel itself is not to blame. Rather, the problems are with how actuaries use technology.

The insurance business is data-centric and, therefore, technology is a big part of our business. In fact, we were among the first major industries to use technology. Other industries have since emerged, and many Big Tech companies (e.g., Facebook, Twitter, Netflix and Google) used innovative technology as their foundation, which was key to their success. While the insurance industry could have gone down a similar path and maximized the use of technology, it instead was bogged down by legacy systems.

Technical articles have long pointed out the problems with Excel, including significant financial issues that it has caused. Yet many insurance organizations still have Excel as the backbone of their major actuarial processes. Regulations such as International Financial Reporting Standard (IFRS) 17 will make using Excel for reporting processes virtually impossible. The history and drivers of how we work can provide a clearer understanding of how to move forward and best take on the challenge of IFRS 17.

A History of Actuaries and Technology

To understand today’s realities, we need to go back to the late 1970s and early 1980s. Insurance organizations have always had lots of data processing at their core. In the late 1970s, most of the insurance industry’s major calculations were done on large mainframes, which actuaries had to schedule a time to use. The valuation process was painful, time-consuming and required a lot of communication between information technology (IT) and actuaries—especially when things went wrong. Both departments were dependent upon each other by necessity.

According to a Center for Insurance Policy and Research (CIPR) study,1 due to competitive pressures and market forces in the 1980s, there was an explosion of insurance products, such as interest-sensitive whole life and variable universal life. The products became more complex, and annuity sales were quickly on the rise. By the end of the 1980s, life insurance companies were equally balanced between life insurance and annuities.

Also in the early 1980s, a revolution happened when personal computers (PCs) became popular. Actuaries, who at one time were extremely reliant on IT, could now do a lot of the calculations themselves using a brand-new software called VisiCalc. It was the first spreadsheet application ever made. Eventually, Microsoft dominated the market with Excel and Office, and the rest is history!

Let’s look at the current actuarial software programs and when they appeared: ARCVAL, Prophet, GGY Axis, PolySystems and others started in the mid-80s. This was all due to the PC becoming available for individual actuaries to use.

This self-service option provided great empowerment to actuaries and allowed the insurance industry to gain many new insights much more quickly than before. It allowed them to keep pace with competitors and quickly design innovative new products. Using spreadsheets was feasible because the accounting, regulations and products were much simpler back then—they were in their first generation. Spreadsheets also helped hedge departments from keyman risk, because they were easier to understand and pass to new employees and junior staff than convoluted code written in C\C++, which was the rage at that time. The learning curve for a spreadsheet process is almost always less than the equivalent amount of programming code.

While valuable at the time, using spreadsheets had a massive, unintended consequence: Actuaries as a profession splintered off from IT and never learned to effectively communicate or collaborate with their IT counterparts. This also meant actuaries developed significantly different patterns of working. As actuaries, the unspoken rule became to stay as self-sufficient as possible to avoid the friction of working with IT (or create the infamous shadow IT).

As accounting rules, regulations and products have become increasingly complex over many decades of innovation, actuaries had to create more elaborate and complicated processes and homegrown systems using Excel, which is the only application that would meet most of their needs. This allowed them to stay out of IT territory.

In the 1980s, computer software engineering was less mature than it is today. The internet wasn’t mainstream until 1996. Cell phones were the size and shape of large bricks. Computers had 64 kilobytes of RAM. The Word document in which I wrote this article would cripple that computer! It was not until 1993 that Excel introduced Visual Basic for Applications (VBA) macro support.2 The problem with the splintering from IT is that actuaries learned to develop processes and automate tasks in isolation.

As technology quickly evolved, so did IT—they created better and better development methods, and they innovated as their systems became remarkably more complex. Actuaries did not evolve with them. In contrast, actuaries felt these technological advances were outside of their domain and did not pay attention.

The Big Question

The DevOps Handbook had an interview with the vice president of Information Technology at Nationwide Insurance, who set up a program for the IT department to create a culture in which IT professionals could spend a certain percentage of their time learning anything and everything they wanted about current computing trends. They would attend lunches and presentations to teach each other about what they were learning. Ever since I read this passage from The DevOps Handbook, I have been dying to know:

  • How much did the actuaries of Nationwide get involved in those meetings?
  • Were they allowed to participate?
  • Did actuaries initiate a similar program themselves around technology?
  • Did they feel compelled to participate?
  • Were actuaries even aware it was going on?
  • How much of those learnings spilled over to the actuarial side?

I have never worked at Nationwide, so I do not know the answers to these questions. But if the answers to all of these questions indicate actuaries were involved, then I think these actuaries were ahead of their time. It could have created an awesome competitive advantage and should be celebrated by our profession. My concern, however, due to the natural divide that has evolved between actuaries and IT, is that the possibility of including actuaries in these developmental conversations may have been ignored. Being involved in strategic IT discussions has not generally been looked upon as a valuable contribution from actuaries in the insurance industry—a lost opportunity, in my opinion. I hate to be this pessimistic, but I have worked for several companies, and I think the latter scenario is most likely. Please prove me wrong!

The Relationship Between Actuaries and IT

Excel is not the culprit. It is the symptom of much bigger problems and should not be considered a crutch for actuaries. These challenges include the reality that actuaries:

  1. Have not learned to effectively work and communicate with IT
  2. Have a strong desire to stay self-sufficient
  3. Try to do everything themselves
  4. Want to avoid the perceived sluggishness of working with IT

There is a huge problem on the horizon, which includes long-term disability insurance (LTDI) and IFRS 17. Using Excel will not continue to work. Organizations small and large will get crushed under the weight if they use these manual methods of daisy-chained spreadsheets.

If actuaries were taught software engineering, these problems could go away—or so I initially posited. But upon deeper analysis of this problem, I realize this perspective was a naïve understanding of the problem and its multiple angles. It reinforces the same problems I just mentioned about Excel, and it diminishes the skills and contributions of the software architects who have spent years learning and practicing their skills to develop robust and secure processes. By underestimating the difficulty of software engineering and expecting actuaries to manage their own business and build their own processes, it is not fair to the actuary or IT. What is the opportunity cost if the actuary is so focused on automating the process that they lose sight of the business?

IFRS 17 has a large technology component to it that requires us to clean up our processes. The problem is that our business processes require detailed knowledge of business, actuarial requirements and regulations, which takes a long time to learn. Given the complexity of actuarial products and new regulations, it is nearly impossible to separate the business logic from the technology. It becomes a tug-of-war of who does which tasks.

We need to promote as much communication, collaboration and empathy between the two different disciplines—actuaries and IT—as possible. It is impossible for actuaries to improve their processes without technology partners and the ability to communicate with them. The crux of creating an effective IFRS 17 implementation is more about changing internal culture than updating technology. Custom software is required to meet the IFRS requirements, and this cannot be accomplished by actuaries alone. Actuaries are ideally suited to identify the specific needs, so the IT departments can create the solutions to meet them.

Room for Collaboration and Communication

It is easy to blame technology—or to come up with our own technology solutions—to solve actuarial problems because they avoid the much harder problem of dealing with culture and politics. Most actuaries would rather hide in their cubes and offices, in spreadsheets, than communicate and collaborate with IT. But at the end of the day, the complexity of the technological problem—which forces multiple domains to come together—should be a driving force for companies to solve the human communication problem between the actuarial and IT departments. There is a tendency to treat IT as if they are a pure expense, just like the hardware they maintain. I think we need to elevate their status within insurance organizations to better partner with them and help us lead the charge into the future. We all have a crucial role to play.

Focusing on the people and culture first will create a better solution and more competitive organization as a result. Get the culture right, and the technology will fall into place—but the converse is nowhere near true! Focusing on the technology first is trying to take the easy way out and will cause the implementation to be clunky at best. The clunky parts will exist exactly where the communication breaks down, which is known as Conway’s law.

Ponder this: The organization does not design the systems and processes; the systems and processes design the organization. If the communication breaks down, then the systems and processes get clunky. To adapt to the inefficient processes, the organization will hire more people. This requires more coordination, which leads to division and frustration. The division and frustration then lead to less communication and more isolation, which eventually leads to turnover because everyone is exhausted and demotivated.

Actuaries and IT both need to shift from a “me” mentality to an “us” mentality. This will require that both departments “bury the hatchet” that has existed for decades.

According to Dr. Susanne Cohen of Conscious Activation: “Communication is a function of the way people think. Thoughts drive all communication and behavior. Actuaries and IT professionals each have their own belief systems that guide their thinking and help determine their willingness to improve communication and collaboration with each other. A first step to improving communication is to address the way each individual thinks, automatically and reactively. Conscious activation is the process of shifting people’s automatic, negative and destructive subconscious thinking to more powerful and productive conscious thoughts. This will support all future communication and collaboration to achieve more productive and prosperous results.”

To handle the difficulties of IFRS 17, the two vastly different disciplines of actuarial and IT need to learn to work together and communicate effectively. I encourage all actuaries to read Domain Driven Design, which is a highly technical book written for software architects, but in the first 50 pages it spells out a uniform way to model problems and to learn to speak each other’s languages. It would help actuaries walk a mile in IT’s shoes, so to speak, to improve communication and build better projects together.

It will be valuable to utilize people that specialize in bridging the communication between actuaries and IT, so the two parties can more effectively work together. I think some of the most undervalued people are those who started taking three or four actuarial exams, worked in the actuarial department for three or four years, and then ultimately decided to work in IT for whatever reason. These are people who are smart, technically inclined and most important, can effectively communicate with both groups.

Conclusion

Actuaries have relied on Excel to do a lot of heavy lifting way beyond its intended use, which has resulted in heated debates. But to blame the current state of our processes on Excel is underestimating the problem. To think that actuaries must do it all themselves and learn software engineering is at a huge opportunity cost. It devalues software engineers and architects, and it devalues actuaries as well.

Actuaries and IT should be focused on complementing each other’s strengths and filling in each other’s weaknesses. Actuaries are at a crossroads because either we learn a bunch of new technology or we learn to communicate with our technology partners. Both require a lot of effort. But ask yourself, which one will have the biggest long-term benefit?

To focus on the technology is to duck behind the deeper and harder problem to solve. It is to cower away from the awkward conversations that need to be had. The complexity of IFRS 17 is forcing companies to address the divergent nature of actuaries and IT. To be productive, it may require more communication than technology.

Implementing IFRS 17 will be hard, but it will leave organizations in a far more competitive position on the backend. But as President Kennedy so famously said in his address at Rice University on Sept. 12, 1962, “We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard.”

To remain competitive and set ourselves up for future success, actuaries must learn how to communicate better with technology specialists. This will lead to the creation of new software processes that resolve issues for actuaries, and it will result in success for insurance companies. Let’s shoot for the moon!

Bryon Robidoux is actuary for The Standard. He is also a contributing editor for The Actuary.

Statements of fact and opinions expressed herein are those of the individual authors and are not necessarily those of the Society of Actuaries or the respective authors’ employers.

Copyright © 2021 by the Society of Actuaries, Chicago, Illinois.