Thinking strategically about technical processes: Part 3 – How management can take the lead

In my two previous articles, 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 – can result in major cost savings.  The most obvious source of inefficiency is what I called recurrent technical processes (RTPs), which are series of processes which repeat on a regular basis, each one slightly different to the previous ones, but all clearly related to each other (for example, spreadsheets used to quote on the pricing of new product variants, or valuation spreadsheets updated monthly).  By maintaining RTPs on an ad-hoc basis rather than developing a more robust solution, many technical teams waste the resource of senior analysts and newly qualified actuaries in performing mundane calculations, rather than the more important work of analysing and interpreting the results.  In the simple example quoted, the more robust solution was 73% cheaper than the ad-hoc approach over the long run – a substantial saving indeed.

But how do we turn this trend around?  How do we realise the significant cost savings that are there for the taking?  In this article, I offer suggestions on how management can take the lead in redressing this problem.

Changing your mindset

As with most things, the key to changing our behaviour is to change our mindset.  In this case, the mindset we need to change is the one where we think of spreadsheet and other user-controlled technical calculations as expenses rather than assets.

If a team has (say) 4 senior analysts spending their day on RTPs, this ranks as an expense, something subject to the annual budgetary process; and we all know how tightly expense budgets are controlled these days.  Expenses are written off as soon as they are incurred, even if the benefit of the expenditure lasts for years.  There is therefore no explicit benefit to spending a bit more on a solution that will last (say) 5 times as long.  And so, under pressure from the management accountants, we often take the line of least resistance and opt for the cheapest solution, even if it is far less efficient.

If the same development were carried out through an IT project, however, the expected cost savings would be identified and justified by a cost-benefit analysis.  Rather than being treated as an expense, the development costs would be set up as an asset and amortised over the expected lifetime of the software.  As a result, the true financial benefit would be reflected in the accounts.

Now, it may not be possible (at least in the short term) to change your company’s accounting treatment; but you at least can start to think in terms of assets to be amortised rather than expenses to be minimised.  Once you make this paradigm shift, you can begin to address the underlying challenge posed by RTPs.

Preparing an audit of RTPs

The next step is simpler than it seems:  you need to conduct an audit of your team’s RTPs.

How do you do this?  Just ask all your senior analysts and newly qualified actuaries what they are spending their time on.  Most of them work on a regular cycle – monthly, half yearly, yearly – and they usually have a fairly good idea how long each process takes.  They will also be able to tell you how much repetition is involved.  In my experience, the people at the coal-face are painfully aware of the problem of RTPs, and will be more than willing to help.

An audit of RTPs is simply a list of all the RTPs that are currently being carried out, along with the person managing the process and the amount of time spent on it per year.  If it takes any staff member more than an hour to compile their share of the list, I will be surprised; but it is surely time well spent.

Start developing a plan

You now need to start developing a plan for how to convert these RTPs into more robust software solutions.  This involves:

(a) prioritising each RTP (based on a combination of time spent on the process, the importance of the process, and the current state of the existing solution), and

(b) estimating how much time would be taken to develop the more robust software solution.

The senior analysts and newly qualified actuaries in charge of the existing processes will know the answer to both questions, and will be more than happy to help.

Knowing how much work there is to do is one thing; however it is another thing entirely to find the resources to do it.  But at least you are now in a position of knowing how much work there is to do, and how urgent it is. You will also have a good idea as to how much cost savings can be derived long-term.  That is why the next step is (practically speaking) the most important.

Freeing up the resources

Ideally, you would like to get a budget allocation to convert the RTPs into more robust solutions; you certainly have the ammunition at this stage to make a submission to senior management based on costs vs benefits.  However, in the real world, this may not be possible.  Let me suggest an alternative that may be more practicable.

In any team, there are a number of tasks that are carried out on a regular basis that are not really adding value to the organisation as a whole – monthly reports that are scarcely read, analyses carried out to a precise level of detail when an approximation would suffice, and so on.  These tasks exist because, having once been commissioned in the past to meet a specific need, no one has had the courage to suggest they stop being performed.  I am sure you know exactly what I am talking about.

I am suggesting you have a quiet conversation with your senior manager along the following lines:

• Explain how much benefit you think you can achieve by removing your RTPs, and how much work it will take
• Ask about the possibility of getting a budget allocation to deal with the problem
• As an alternative, suggest easing up on those “non value-adding” tasks for a period of time to free up resources. For example, you might suggest turning a monthly report into a quarterly one for the next year; or performing an analysis more approximately, rather than precisely.  Ask the question, “which is really more important:  performing these ‘non value-adding’ tasks, or making quantum improvements in the way we do our core technical tasks?”

Since I do not work in your organisation, I do not know how much support you will get for your proposal; however, based on my experience in a number of sites, I believe most senior managers will welcome and respond to your initiative.  If I were a senior manager, I would certainly look favourable on any such innovative proposal to improve the efficiency of your technical team.  So give it a go – you may be pleasantly surprised at the outcome.

Finalising the plan

Once you have freed up some resources, you are now in a position to finalise your plan.  This involves matching the priorities identified earlier against the resources now available.

But what sort of resources do you need for your task of converting the RTPs?  In an ideal world, I would recommend a specialist on your team, a senior analyst or newly qualified actuary with superior excel skills, possibly some specific IT training, certainly with skills in other packages such as Access, Visual Basic, and so on.  If you don’t have such a person, then any senior analyst or newly qualified actuary can fit the bill.  If they can develop the RTPs in the first place, they can certainly design a more robust solution.  But, over the longer term, I would certainly suggest you plan to recruit someone with a more specific IT skill set.

Conclusion

The bottom line is this:  strategic thinking involves you, the manager of your team, thinking pro-actively about what you can do to solve the problem of RTPs.  You can quantify the cost of all those ad-hoc solutions quite easily, and this should provide both the incentive and the ammunition to seek some budgetary allocation to make real savings.  You may need to use some creative strategies, but solutions can always be found if you are prepared to think “outside the box”.

You will notice that I have omitted to mention one very important issue;  that of training.  Clearly, a little training on how to convert RTPs into more robust software solutions will go a long way to making the implementation of the solution practicable.  It will also help you to work pro-actively in the future to preventing the problem occurring in the first place – and we all know that prevention is better than cure.

This omission was deliberate; the topic of training is so important that it merits detailed consideration on its own.  This will be the topic of my next article.

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