Upgrading your actuarial functionality ultimately involves change. A necessary part of that is converting your models to use modern actuarial software.
We’ve been supporting your efforts at such conversion process with our blog series, the 7 Steps to converting actuarial models, which continues below. First, a quick recap:
- Step 1 – Determine you need a new modeling system (part 1) (part 2)
- Step 2 – Build a case for conversion.
- Step 3 – Compare candidates (understand system differences)
- Step 4 – Make sure you’re not making a bad decision.
- Step 5 – Do the work to formally convert your models.
What’s next? Step 6 – Getting some distance from your old models. Or, how to break up and move on.
1. Break the news gently
“Let ‘em down easy.”
At some point in the process you need to let your current vendor know you will not be renewing your contract. (Or that you will be renewing, but on a vastly reduced basis.) Sometimes this can feel like the end of an intimate relationship. [We’re going to come back to this theme a few times in this post. You’ve been warned 😉 ]
There’s good ways and bad ways to do this.
A good way would be the adult, professional method. Straightforward and direct. Hey, it’s not you. It’s us. That is, we have needs that you just aren’t meeting.
If you want, you can say “It’s just business.”
You don’t have to be cruel. Cruelty is often a recipe for future disaster.
You can offer suggestions as to what the old system lacked. But at the same time, remember, this is a small profession. And it’s a small market for commercial actuarial systems.
You don’t want to be known as the person who bad-mouthed the old system, only to find yourself a few years down the road in your next job having to implement that same system, because of decisions that were made above your pay grade.
That’s going to be very awkward for you, your vendor account representative, and the audiences you serve.
Or, if you find that your conversion effort was over-promised and under-delivered, and you need to return to that old vendor at some point, you don’t want to have poisoned the well and created an even worse future for yourself when you need to restart the relationship again. With all the mistrust, fear, and hesitancy that comes with a do-over.
Plus, if you spend a lot of energy bad-mouthing the old system, you can potentially create an unrealistic view of the capabilities of the next one. You run the risk of continuous disappointment, not because the system did anything wrong, but because your expectations for what it could or should do were unrealistic.
If we bring this back to the relationship analogy, at the point of breakup, it’s best to be honest without being cruel. State what your decision is, what the next steps are, ask if there are questions, and move forward with conviction. That way you can be professional about the situation.
2. Plan for historical results storage
When it comes time to “move on”, you may be tempted to just forget everything that was done in the old system and start over.
But just dumping everything into a random pile (some archive folder into your archive directory) isn’t a good way of going about that.
Even though you’re not going to be using your old system for future work, you have a lot that was done using that system in the past.
At some point you may need to access those prior model results. It might be for an audit, or for some future actual-to-expected comparison. Then, you’re going to want some ability to dig in to those old records.
The point is, it’s easy to anticipate questions about work that was done in the past. At that point, you don’t want to just throw up your hands and say, “Sorry! Don’t have that information,” when, in fact, you could easily have that information. Or could easily get it.
Is there anyone who can help?
Of course there is. You may need to consult with your auditors and financial regulators about how long records should be kept. They could give you some ideas as to times to keep data at-the-ready, in a first archive, and a long-term archive.
Also, you need to consider what format you will keep those results in. Excel files? Printed hard-copies? .CSV files? Create a separate warehouse just for old model values?
How you choose to store them is going to be related to various factors. These might include how much data maintenance you’re willing to perform as you go forward, how much actuarial work you want to do, and the likelihood of accessing those results again in the future. [See the following section.]
The good thing is, by this time, data storage has become so cheap and easy to access that you should have many different options for how that’s done, where, and how you get it back again.
Once you know how long and in what format(s) you will need to keep old results, you can design a structure for storing those.
It’s your responsibility in the model conversion to figure out what’s important to keep, and for how long, and then to keep that, and for as long as you need to.
You can purge the rest. And probably should. That way you not only free up disk space (i.e. closet space), you also reduce the mental drag that comes with trying to remember everything about the past.
Again like a relationship, you’ll want to remember the essential parts and let the non-essentials go.
3. Determine whether you may need some kind of reporting license for a period of time or in perpetuity
On top of the results that have been archived, it may be necessary to still pay for a slimmed-down license to be able to access the results.
That’s because some systems create output data in a proprietary format. Which means you are locked into using your vendor’s tools in order to review results.
More often, it’s all of the variable relationships and input table values that, if they have been coded in one of those proprietary formats, require you to use the system in order to be able to validate calculations.
As a result, sometimes you may need to maintain some kind of access going forward. If you’ve got a quality vendor, they’ll offer you something like a read-only license that will allow you access to those historical model results and formulas. You probably won’t have the ability to change or run anything new, but since you don’t need to, it’s not a big deal.
That will be beneficial, then, if you have one of those ad-hoc needs, such as an audit, where you need to dig in to prior model results to satisfy a request.
It may not be fun. But if you have maintained access by keeping the reporting license intact, you can access what you need, when you need it.
Of course, that’s not necessary if you’ve been able to design your own model archives, or have had great documentation such that you could easily reproduce your results upon request.
It may be easier, though, and cheaper to maintain that “reporting-only” license than to constantly distract some other professional to reproduce prior runs in a spreadsheet for those audit requests.
Which suggests that the reporting-only license may be a viable option.
4. Documentation is critical
Document where old results are stored – what format, what time periods, file locations, who has access, etc.
Also document how people can access them – do they need to use that special reporting license? If so, what are the login credentials? What report should they access? What data elements?
Do they need to make a special data pipeline connection? Will they need to request a file, a report, a run, or a process from some other department? Who are the connections in those other departments who know the other end of the process?
And so on.
The more documentation you do now, the easier it will be for anyone else to work through the process when they need to come back and investigate. As often happens, this may even be you yourself two years down the road, asking, “Now what was it I did back then?”
Document the decision process, too.
Writing down the reasons why you chose the new model system will be valuable. Again, it’s like a review at the end of a relationship. You don’t have to go into all the gory details, but reminding yourself of what you want and need out of the new system, and where the old one just didn’t measure up, is going to solidify the decision and allow you to move forward with confidence.
Without good documentation, you continue to run the risk that your conversion projects (and, more likely, your future modeling processes) won’t be as effective as you wished them to be.
This is because habits are hard to change. Your bad modeling practices (learned over time as you adapted to the inadequacies of the systems you inherited) will need to adapt and grow to become better in the future.
“At this stage, it’s important to be clear about your motivation; if necessary, write down your reasons for making the change and read them every day.”–Harvard Health Publishing
Continuously writing down the new advancements you’re seeing and the new ways you’re improving your processes will be very helpful as you build and implement new and improved models.
Plus, this will help you to prove that your case for changing systems was valid. We’ll dig deeper into this as part of the next (and last!) article.
5. Understand why you’re “breaking up” and stay focused on the future
Old habits die hard.
Why do you think something like 45% of relationships have more than one break-up? [You know, you can find evidence on the internet for just about anything… ] You know what you know, and it’s sometimes tempting to quit the hard work of moving on and revert back to what you knew before.
This can cause problems in model conversion efforts because when it starts to get tougher, more nit-picky, more of “doing the work” rather than being excited about the possibility of a better future, you could be tempted to abandon the conversion. The devil on your shoulder whispers in your ear… It would be easier to just keep some in the old system.
Or, much like the “recovery” work that we adults have to do after a relationship ends, you might start looking for the easy way forward. You might think, “well, I can just flip this switch here, and things are closer to what they were before, and I don’t have to justify so much of a deviation.”
Don’t do that! You made good decisions before, don’t make a bad one now.
Continuously remind yourself that the work you’re doing to convert your models is going to pay off in the future. You’ll have more usability, easier understanding of your models, you will eliminate work-arounds, you’ll have less technological overhead, and so on.
The conversion may be difficult, sure. And it may feel like double work, when all you really want to do is just dive in to the new model and start fresh.
But if you don’t remind yourself why you chose to move away from the old models in the first place, you’re likely to make the same mistakes in the new models.
Workarounds. Shortcuts. Poor documentation. Inefficient modeling. Just generally not taking advantage of the new features of your new system. You know, the reasons you actually wanted to change in the first place.
That’s not going to get you the outcomes you want.
Instead, you need to ensure that you stay focused on the future state. You’re going to have good models, good governance, good processes, good results.
You’re going to deliver a better work product. And, as a result, you’ll be a better actuary. That’s healthier for all parties involved.
Communicate to your team members, to the finance professionals, to the IT team, and other what’s happening, what’s going to happen, and what they can expect from you.
This is the community-building that you need to do as you move forward. You don’t want to fall into the same old habits (work-arounds, ungoverned model additions, poor documentation, unexplained results) that led you to the frustration with your old system in the first place. So you’ll need some accountability.
Building a network of support will reinforce your new and better model practices. As well, they’ll be able to give you a heads-up if you’re getting off-track. Or even warn you not to do something stupid.
While that may be intimidating, it can also be empowering.
You will have to communicate frequently about what’s happening with model conversions, where results might be different, if there are any new input or data requirements, if there are any new output requirements, and so on.
That way your network can be informed of issues that could potentially affect them or add requirements they need to account for.
Not communicating can be an issue for some actuaries. We just like to see a problem and solve it and move on.
But that’s not good for ensuring that everyone is up to speed with the new system and the new structures going forward. Documentation of what you want out of your modeling system (step 4 above) and continuous evaluation of what you have against that system, is going to be essential for your success.
As such, you need to continuously communicate within your team and with those around you the wins you’re seeing and how it’s making their work product (and their lives) better.
It’s going to be better for you in the long run, because you’ll have more satisfaction with your models, your output, and the decisions that you’re making as a result of the work you’re doing with those models.
Okay, here’s the TL/DR (too long / didn’t read) version of how to break up with your old system.
- Be professional and courteous.
- Document your thoughts and create a repository of historical results.
- Maintain momentum by building good habits.
- Create a community of support through communication.