Thinking strategically about technical processes: Part 2 – How much can you really save?

In my previous article, I suggested that thinking strategically about our core technical processes – that is, taking time out to reflect on whether we are doing them in the most cost-effective way – is an idea whose time has arrived. In my experience, most actuarial teams do not do that – they just allow their processes to evolve as needs change; and I made the argument that this ‘normal’ approach leads to serious inefficiencies.

But just how ‘inefficient’ is this ‘normal’ way of operating? How much time and money could we save by thinking more strategically about these things?

A simple example

To illustrate the argument I am making, let me propose a very simple example – one, however, which is typical of the way that many actuarial teams operate today, in my experience. Here is the scenario:

You are the manager of a product pricing team, and you are asked to quote on the pricing of a new product variant. This work involves a certain amount of technical actuarial work to be carried out in an Excel spreadsheet, with the results sent to the intermediary who has asked for the variant.

You pass the spreadsheet setup work onto a senior team member, since it is too complex to pass onto a junior. That side of the work takes 10 days to set up, and you personally spend a further four days reviewing the work and refine the assumptions. Including on-costs, the total cost of the exercise is around $10,000.

An evolving scenario

So far, our example is all plain sailing. The task has been performed by the best available resource and there is no inefficiency. If this were the end of the matter, there would be no cause to complain about the process involved.

However, in my experience this is typically not the end of the scenario. And so, here is stage #2:

The client is so pleased with the piece of work your team has performed that they come back a month or so later for a similar yet different product variant. The new calculation is (a) sufficiently different from the previous piece of work that a new spreadsheet needs to be set up, but (b) sufficiently similar that the original work should be used as a base.

What do you do in these circumstances? The typical response is to ask the same senior resource to also perform the new task, using the previous piece or work as the starting point. What other alternative is there? Because the new task is based on the previous one, there are certain economies to be gained (say, 50%), but the task will still take five days to set up, and a further two days to review, at a cost of $5,000.

Recurrent technical processes

Again, if this was where our example finished, there would be no inefficiency. However, an example like this typically evolves very rapidly into what I call a recurrent technical process (RTP) – that is, a series of processes which repeat on a regular basis, each one slightly different to the previous ones, but all clearly related to each other. In this example, the RTP takes the form of regular requests to produce similar product variants, justified on the grounds that each client deserves to have their individual needs catered for.

We have reached the end of our economies of scale using the current process; each new variant still takes about five days to set up the spreadsheet and a further two days to review, at a cost of $5,000. More to the point, as these requests are coming in every couple of months or so, this particular senior resource is spending a significant amount of their time doing this sort of quote. Resources and budgets are being stretched.

The time for strategic thinking!

The moment you realise that you have evolved an RTP is the time to start thinking strategically. What you really need to do is to develop a generic spreadsheet model that is sufficiently generalised to cater for all the variants that you are likely to encounter. It will be fully parameterised and fully documented (so that your most junior resource can be trained to use it), and subject to audit control and spreadsheet design guidelines. It will be a process that is designed to ‘last the distance’, because it is acknowledged that it will be continually in use.

How much will such a generic spreadsheet model cost? Many actuaries will be surprised to realise that it costs not much more than the original spreadsheet; the surprise, however, is because most of us have no training or experience in designing such models. Our only experience with spreadsheets is of the ‘do it quick and then throw it away’ type. But a well-designed spreadsheet is not hard to construct, once you know how to go about it.

Let’s assume it takes twice as long as the original project – in my experience, this is overly conservative – and therefore costs around $20,000. But what have you gained? On an ongoing basis, each new product variant will be manageable by at most two days’ data entry work for your most junior resource and half a day for review from your more senior analyst. The ongoing cost will be closer to $500 instead of $5,000 each time. Your well-designed generic spreadsheet could be good for at least two years without major re-design – again, I am being conservative here – and, at one new variant every two months, that equates to at least 12 variants at $4,500 savings each time.

Thus, based on conservative assumptions, the investment of $20,000 to build a generic spreadsheet model could save you $54,000 – not a bad return on investment! Not only that, but your systems will be more manageable, more secure, less error prone – and your most senior resources will be spending their time on designing quality software and exercising actuarial judgment rather than ‘grunt’ work, which will do a power of good for both morale and efficiency. Now that’s what I call a good day’s work!

A challenge

Of course, the example I have chosen is very specific, but it is generalisable to most actuarial teams. If you are a valuation team, your RTPs may be those infamous ‘manual reserves’ that started life as a one-off exercise to please the chief actuary, and then evolved into a regular monthly calculation. If you manage a planning or capital management team, they will be something else again. The user-defined application you use may be a SAS procedure or an Access database rather than an Excel spreadsheet. But one thing I am sure of – those pesky RTPs are here to stay, and virtually all actuarial teams seem to be clogged up with them.

Take this simple challenge: do an audit of the workload of your team for the next month, and record how much of their work is taken up with RTPs – jobs that could be made considerably simpler if more generic and robust processes were developed. And then apply a savings factor of 73% ($54,000 / $74,000, applying expectations from the example above) to that proportion of your cost centre budget. What do you stand to gain by learning to think strategically about technical processes? I suspect you will be surprised by the answer.

Of course, the emphasis needs to be on the word ‘learning’. There are powerful reasons why most of our actuarial teams do not realise these sorts of ‘easy wins’ – mostly because they have never been taught how. Over the next few articles, I will teach you some principles that will enable you to start on this learning process. By doing so, I will be doing myself out of some business – after all, most of my consulting practice these days involves doing exactly this sort of thing for my clients – but somehow, I think I would rather spend my time helping others to do it for themselves…

CPD: Actuaries Institute Members can claim two CPD points for every hour of reading articles on Actuaries Digital.