Introduction
Over the past few articles we’ve been discussing what Software as a Service means for actuaries. Check out How it’s delivered (SaaS versus Productized) here and here; see where it resides here and here. And finally, the most recent discussion is how it’s made. Last time we talked about “agile” versus “waterfall” creation methods for the software tools you use every day.
Traditionally, actuarial work was more of the “waterfall” type, where you set out a bunch of requirements at the start, send the actuaries off to their cubicles to sharpen their pencils and work smarter, not harder, and hope that the end result is useful.
From the general trend in the business world, we believe the future of actuarial work is going to look much different. We see future actuaries primarily using Software as a Service applications and delivering their actuarial work product under an “agile” mindset.
We’re not alone in this thinking. Separately, Tim Fleming, of GuideOne Insurance, and a team at E&Y have recently published ideas in this same vein. In fact, the E&Y paper said the future of actuarial is “strategic, agile, and lean.”
Those agile teams are going to be more cross-functional and strategic, rather than insular and focused on honing precision for the illusion of accuracy. They are going to incorporate decisions about not just insurance reserves but elements of usability, design, and customer service. And, obviously, profitability trade-offs between risks and returns.
You would not be out of line to ask, “How would an ‘agile’ actuarial team work? I’ve only ever worked with other actuaries.”
Smaller actuarial firms have led the way in this arena. Small insurance company actuaries are talking with underwriting, finance, sales, and admin professionals all the time. They’re adept at communicating across borders and working at cross-functions.
But don’t get too full of yourselves, small company actuaries, you’re not off the hook yet. You still have plenty of work to do. You may be good at collaborating with Suzanne from Accounts Receivable, but you’re probably not there yet when it comes to understanding prioritization processes that are necessary when transforming to agile work styles.
Here’s how an “agile” team of actuaries and their output could differ from a traditional “waterfall” or project-based team:
| Waterfall – project-based Actuarial delivery | Agile – Actuarial-as-a-Service | |
| Frequency | As needed / mandated | Regularly-scheduled delivery |
| Project type | Long time frames and fixed set of deliverables | Shorter rounds of development focused on incremental improvement; rapid adaptation to changing end-user needs |
| Team types | Actuaries and their managers | Actuaries, finance, sales, admin, IT, customer service, etc. |
| Work prioritized by | “Project approval group”, evaluating the ROI of the project itself versus other projects available | Working group, evaluating the potential gains of all requested incremental improvements against other options |
| Definition of “done” | “Signed-off completion” of all in-scope items | Doesn’t “finish” |
| Adaptability for new concerns | Create and manage a list of “Day Two” items. Once the main project goes live, address the list with a separate project | Add to the backlog for prioritization. Never lose an item, always working on highest-value opportunities. |
| Incentives | Get an occasional pat on the head for a job well-done | Continuous feedback, perpetual reinforcement of good work |
| Risks | Mistakes (cost overruns or missed deadlines) are often large when they happen due to inability to correct during the project | Shorter decision cycles and quicker feedback means less chance of divergence from ideal deliverables |
This might seem like a big change from the way actuaries have worked in the past. It is. But let’s also recognize that much of what was done in the past was only done that way because the ideal way wasn’t available. Now that we have better options, shouldn’t we be using them?
Let’s put some meat on those bones
There are a lot of articles about “this is where we think it’s going”, but not enough “practical steps to get there”. What might this look like when you’re working in an “agile” workplace?
You will be delivering small batches of improvements regularly rather than big overhauls infrequently
Here are just two examples. We’re sure you can think of more.
Pricing – every two weeks you’ve got a new set of rates that update automatically in the system and on your illustration software. You know everything is in compliance because when you filed your rates you created a wide environment of possibilities that the company would be happy with, and your process is to choose from that environment whichever set of rates now makes the most sense based on current conditions around you: competitor rates, interest rates, recent experience, company priorities, etc.
The UK does this with insurance pricing right now. And general insurers seem to have a handle on changing rates frequently. But life insurance and annuities seem to be stuck in on a three to four-year time scale of pricing and often only when it’s mandated due to new interest guarantees..
There’s a lot of push-back with “Yeah, but it’s a lot of work to change rates.” Which begs the question, Why is that so? And, also, What if it wasn’t a lot of work? Wouldn’t you update rates more frequently? We believe the mindset of Yes, it would better to do that will drive the innovation necessary in order to bring about that future state.
Investment Strategy – Why only look at duration mismatch and asset category weightings every two or three years? “It’s a lot of work to do those calculations.” As above, we believe more frequent looks (quarterly, or even monthly), will give you better information about where the portfolio is, where it’s going to go, and how to correct. Better information leads to better decisions, and thus the need for better systems which will drive you towards that innovation and advancement mindset.
You will incorporate end users early in the process
No longer will you be waiting until you’re completely done to see if what you’ve done plays well with others. You will know whether the finance team needs that reserve number as a separate file or part of the data warehouse on day two of the sprint, rather than after you’ve completed all your output design.
As well, you won’t be forced to wait for other departments to get you the stuff you need “whenever they get to it”, because you’ll be part of their improvement projects from the start. You can point out to them that you want those files on the first of the month, not the fifth, so they can incorporate that change as they redesign their work flows with your benefit in mind.
You will stop thinking of actuarial work as “done”
It’s never done. If you’re moving to agile work ideas, you’ll have a continuous backlog of work to choose improvements from.
You will need to devote a portion of your planning time to address that backlog. This is the “technical debt” that accumulates over time. Agile teams address this regularly and with intentionality. Non-agile teams push those issues to “Day Two” items and never actually get around to solving those problems.
No, actuaries don’t like to stop and plan. We just want to jump in and get it done. So we have to ask, How’s that working? Doesn’t that often lead to the “band-aid solution”?
However, if you make the backlog continuously visible when you’re planning, then you’ll have more incentive to address those problems. It’s like an open wound that never heals, reminding you of the things you haven’t done. You’ll be actually fixing the problem, not just covering it up and hoping it heals itself.
You will think less about “project completion” and more about “continuous improvement”
You don’t get there believing you only have to do cash flow testing once per year.
Why do actuaries have to do CFT sensitivity tests as of 9/30 during a given year? Because there’s so much work involved that to get it all done between 12/31 of that year and the reporting deadline is often impossible. So actuaries do their real testing as of 9/30 and then make an assumption that 12/31 isn’t really that different from 9/30 anyway.
Which leads to duplicating work, working inefficiently, and stale results. Plus you have the implication that since these projects take so long, there’s not enough time to work on improvements that would deliver results faster! What a Catch-22.
The biggest problem that we see in working like this is that the output doesn’t get leveraged for additional uses. Could CFT models be used for financial planning? For investment strategy? For economic capital analysis?
Absolutely they could. If they were built and designed in modular, scalable ways that software engineers have been applying for decades.
If you were mandated to complete CFT every quarter, you would absolutely find ways to get it done faster, with less intervention, such that people (actuaries) are doing people things (weighing risks and rewards) while machines (data pipelines) are doing machine things (automated processes).
Because then you have incentives to develop efficiencies in your processes so that you’re not spending all of your time babysitting the ETL process.
Wouldn’t it also be great if your CFT was automated? I.e. you push a button and you get your economic scenarios created, your asset and liability surveys created, and your model puts everything together for you automatically? Why not? What in all of that is actual human intervention that needs a decision-maker?
None of it. It’s all algorithms anyway, so if you set quarterly processing of CFT as your goal, measure progress against that goal, and see how far away you are each time, you will have additional visibility around how much better you could do your job if you had more time to understand and analyze.
If you did that, you would certainly be able to make a case for performing CFT much more frequently. Just doing it the way it’s always been done leads to getting the same kind of results you’ve always gotten – slow, inefficient processes that don’t add any value to the management of the risks in the portfolio.
So how do you get there?
It can’t be just that easy. It’s going to be work. Of course.
Here are some practical steps you can start taking now to move in that direction.
Incorporate non-actuarial professionals regularly
Create cross-functional teams that regularly work on not just actuarial projects but other departments’ projects as well. Invite others to sit in on your planning and prioritization meetings, so they can take that information back to their teams for their own prioritization and planning meetings. And invite yourself over to those sessions as well.
This will bring other end-users into your projects, and you into other end-users’ projects, much sooner. You might need to talk to administrative teams, finance, underwriting, IT, customer service, marketing and sales, maybe even buildings and grounds.
When you have that earlier integration, you’ll be able to see earlier how what you are doing affects them and vice versa, saving time that later might have been devoted to cleaning up those integration mistakes.
Start small and incrementalize
You aren’t going to be able to make big shifts and changes in the way you (and others) work all at once. Plus, having a top-down mandate to just make it happen rarely works. Neither of those is actually an agile mindset. So start with a small test case, learn from that, and then expand. It’s very similar to the learning that you’ll do when converting an actuarial system – start small and advance from there.
Spend time with other departments on non-project work
Have lunch with them. Go to Happy Hour. Participate in the Corporate Challenge. Stop being so insular. As an actuary, you should have the perspective that you are a business professional with a probability and statistics focus, not a mathematician who happens to be in business. So you need to be seen by those in the other departments as someone they can know, like, and trust. That’s what makes a successful project – when everyone is working together for a common goal. If they don’t know, like, or trust you, they won’t be working as well
Which means you need to do the work to get them to know, like, and trust you. You make that happen when it’s not all about the project plan or the current sprint and they see you as working for the same goals as they have.
Get comfortable asking for meaningful feedback from end-users early on
This will take some getting used to. Because of the examination system set up with big pass/fail opportunities, actuaries are trained to think in large blocks encompassing an “all-or-nothing” approach. But that doesn’t incorporate early feedback allowing for correction if you’re off-course.
If you’re, say, building a new actuarial model for LDTI or IFRS-17, don’t just assume that you can figure out an efficient way to write the formulas that others will be comfortable with later. Write an initial version of it, and ask others in your department and outside of it if they can understand it. If not, and they ask you lots of clarifying questions, use those questions to inform you where your assumptions have failed.
In the same way, ask for and incorporate feedback on your projects much earlier than you are used to. Rather than finishing 100% of your work, throwing it over the wall for peer review, and crossing your fingers they don’t find a silly arithmetic error, you should be incorporating that review earlier in the process. Even as early as the design and architecture of the solution, it’s good to get feedback, because humans are notoriously blind to our own flaws.
Here are a few questions you can ask of yourself and as you build your team to determine whether you’re “agile” or not:
- Do you work in cross-functional teams? By this we mean, actually work in those teams, where you sit at the same conference table and have your bare-knuckle fights about prioritizations, design, and functionality? Or do you mostly work independently in your own silos, and only come together every once in a while to divvy up the next responsibilities, passing “completed” work back and forth for peer review that’s not really review at all? If it’s the latter, you’re not really agile.
- For your current major project, what would be the barest minimum thing you could improve upon? What additional value would you deliver with that improvement? Do that as the first small step.
- For your next new thing, what’s the smallest unit of deliverable you could create? This is also known as a “minimum viable product”. Once you have the “minimum viable product”, what might be the incremental changes you would need to make to that thing to be closer to the end goal?
- Do you have a process for quick, early, and frequent end-user feedback? Just asking “How’s it going?” around the virtual water cooler isn’t going to be enough. You’ll need to not only get it, but incorporate it.
- How will you manage competing requirements and limited timelines? Project management is going to become a more important skill for actuaries than they are used to. You’re going to have to create accountability structures, flex beyond your immediate desire to solve the problem, and spend some time planning and thinking about design and the users two generations after you, too.
We fully believe the future of actuarial work is agile.
Let’s get there together, shall we?
Next time:
We’ll wrap up with some software development practices and how those practices could be implemented in the actuarial workplace for better results. Quick preview of the topics:
- Segregated development environments
- Modularity and reuse
- Peer review
- Testing
- Concurrent Documentation (while it’s happening, not afterwards)