All change!
I have blogged previously about the risks in reinventing software that has already been built. As usual, I declare my complete and utter lack of independence in the opening paragraph - I run a business providing software services to actuaries. And while this blog might be self-interested(!), that doesn't make the point here any less true.
Let's say that you have managed to build your in-house software system. Let's also say that you picked up some project-management tips from Flyvbjerg & Gardner (2023) and the system was delivered on-time, on-budget and to-specification. You have delivered what you promised, so you have succeeded. What could be better!
But what happens if business requirements suddenly change? Since you have self-built, there is only one thing you can do: plan another project, make the costings and seek the resources to make the necessary changes. However, if the need for change is industry-wide, you might find that suitable resources are hard to come by. In contrast, if you had bought in an external software solution then you might not have to do anything at all. More specifically, if the new requirements are industry-wide, your supplier will likely already be planning a change project because all the clients have the same shared need.
As it happens, we had an example of this with the covid-19 pandemic, which caused two problems for actuaries:
Spikes in portfolio mortality, thus distorting experience analysis, and
Spikes in population mortality, thus distorting stochastic projection models used in setting capital requirements.
These problems are industry-wide, so every insurer needs solutions for (1) and (2) above. If you built your own software, you need to find actuarial and IT resource to make changes. In contrast, our customers - the lucky things! - didn't have to lift a finger:
For portfolio experience analysis we developed methodologies that allow for rapidly fluctuating mortality levels.
For stochastic mortality projections we implemented robust methods in all the major classes of forecasting model.
We designed, built and tested the above solutions, then rolled them out to clients with peer-reviewed public documentation in Richards (2022) and Richards (2024). The only thing better than a perfectly-delivered IT project is one that you didn't have to do at all.
References:
Flyvbjerg, B. and Gardner, D. (2023) How Big Things Get Done, Macmillan, ISBN: 978-1-0350-1893 HB.
Richards, S. J. (2022) Allowing for Shocks in Portfolio Mortality Models, British Actuarial Journal, 27 (2022): e17, doi: 10.1017/S1357321722000125.
Richards, S. J. (2024) Robust mortality forecasting in the presence of outliers, British Actuarial Journal (to appear), doi 10.1017/S1357321724000175.
Previous posts
Software projects - the sting in the tail
In an earlier blog I looked at the arguments in favour of buying in specialist software, rather than trying to build it yourself. Of course, as someone whose business is providing software services for mortality and longevity work, I am somewhat partisan. To balance things out, I wrote a follow-up blog on when it makes sense - even for us - to source external sof
Add new comment