Without wishing to bring politics into it, one may wonder whether endorsing Karl Marx might be somewhat career-limiting for a representative of a firm whose raison d’être is to facilitate the efficient allocation of capital. But in one respect, at least, he had a point. One of his many disputes with classical economists concerned division of labour: whilst Adam Smith, famously, saw this as a foundation for economic progress, Marx saw it as a way to achieve bad results (albeit he may have accepted that it would achieve those bad results pretty quickly and effectively). Where we as a firm are out-and-out Marxists is that we do not believe that division of labour leads to good financial models or good financial advice.
First, a bit of context. In the world of energy transition assets or businesses, financial models fall broadly into three categories: appraisal, transaction, or operational. Appraisal models are used to assess investment opportunities and need to be flexible to easily evaluate different financing or revenue structures; transaction models are used to support specific investments and need to be a precise reflection of the underlying asset or business; and operational models are used as a monitoring or reporting tool that need to accommodate actual data (some of which may not have been envisaged in earlier model iterations). These types of models have different and often competing priorities – but the approach to model building and maintenance often fails to reflect this.
A caricature of your average financial modeller in energy and infrastructure teams – whether advisor or principal side – is the (or, possibly, one of the) junior team members who, after a year or two, will graduate from the modelling team and join the ranks of their esteemed colleagues who might occasionally be permitted to talk to a human being that works at a separate organisation. This is equally applicable irrespective of the type of model being developed. This sort of division of labour means that there is correspondingly a split between the individuals who build and operate the model, and those who interpret the results and best understand the broader context.
One can understand the appeal of such a team structure and why it is as common as it is. It might be appropriate for appraisal modelling (where ‘close enough’ may be good enough, and where everyone is working at risk) or for operational modelling (where asset management teams need ‘pure’ modelling support to integrate a new front end to the model which better reflects reality). It is also quite profitable as it involves delegating work that can be done fairly well to cheaper people. However when it comes to transaction modelling, ‘fairly well’ or ‘close enough’ often won’t cut it.
Risks
The big risks associated with the division of labour come from a model giving the wrong answers without anyone being any the wiser. It isn’t hard to see how this might come about: say, a new set of model inputs arrives and there’s a cost missing; or a revenue projection arrives and there is an embedded implicit assumption around asset availability that is inappropriate for your site – but there isn’t the knowledge or experience base to query these inputs. As a result, you end up a few £m out on capex or you overstate your revenues by a few %.
Whilst modelling oversights are best avoided at any stage, there is a greater chance of minimising the impact in appraisal models; significant contingencies are frequently included to manage the unknown risks, and errors may only lead to an opportunity cost based on a misevaluation. But as part of a transaction these mistakes can be fatal: you end up basing an investment decision on a flawed model. Routine due diligence checks don’t always pick up these points; for example, a model audit will check that the model inputs align with documentation, but they won’t tell you if there’s something missing from or inappropriate about said inputs.
Another risk is highlighted by comparing two approaches: do you model the negotiations, or do you negotiate using the model? Division of labour between negotiator and modeller nudges you towards the former, but the latter is clearly preferable – you don’t want to agree principles that when quantified turn out to be unworkable or suboptimal. However, if it is to be delivered then it is necessary for the negotiating team to have a deep understanding of both the model and the market.
An added bonus of negotiating from the model is that principles that are slightly ambiguous can often be firmed up in a manner suiting both borrowers and lenders. Such opportunities are liable to be missed if the person staring at the spreadsheet has only a limited awareness of the broader deal context. We’ve seen this on a few occasions on recent UK BESS deals where we have found ways to meet certain covenants imposed by lenders without making overly large concessions; the alternatives were often high cost (to equity) and low benefit (to everyone).
Value
As well as reducing downside, minimising friction between the deal team and the modelling team (ideally by making them one and the same) has clear ‘base case’ benefits.
We typically find that there is a time saving to be had because modelling can be better integrated into the deal as a whole and it avoids too much back-and-forth between those doing the work and those checking the work. An experienced and informed modeller will have (or will more rapidly develop) a good sense of what analysis is necessary or helpful, thereby improving the quality of output. Instead, a modeller who is divorced from the broader transaction often ends up running scenario after scenario without any great appreciation for the end goal. This is supposed to get to the same point eventually, and perhaps it will – but at best it will take longer.
There is also an opportunity for extracting the most from every pocket of value when modelling can be done by those who know how to get the best out of the model. To give an example of this kind of financial engineering: a typical approach to debt sizing around multiple constraints is to assess the debt (profile and amount) in a lender base case, to assess the debt (profile and amount) in a downside case, and to take the lower of the two. This guarantees meeting one of your two constraints, but tends to leave projects both undergeared and at risk in certain periods (i.e. lower return, higher risk). Instead this should be approached period-by-period, which effectively requires the running of multiple cases concurrently. In order to achieve this, some (but not an enormous amount of) technical modelling skill is required. However, if you are asking the modeller the questions “does this work for lenders?” and “is this fully optimised?”, it will take more than just that modelling skill to give you confidence in their answers – it takes some transaction knowledge and transaction experience.
Conclusion
Financial modelling in support of transactions should not be treated as a standalone workstream. At least one of the individuals responsible for knowing pretty much everything about the broader deal should also know pretty much everything about the model: where the inputs come from, how robust they are, how they are treated in calculations, and where the resulting pinch points may be.
This is (and has always been) our preferred approach at Elgar Middleton where transaction experience and expertise is fully integrated with the financial modelling. Delivery of a transaction is not the same as the sum of the parts – too much division of labour and you will end up with a worse, riskier, deal. Financial modelling is not the only component that is extracted from the broader transaction work, but it is often the most tempting; it is a temptation that should be resisted.
