Project finance modelling skills in other sectors
Since the early 1990’s I have watched a number of companies around the world attempt to unify spreadsheet modelling practices within their own teams, companies as well as sell into other organisations. As yet there is no unified approach to financial modelling, this shouldn’t be hard so lets take a look at what has happened.
My companies continued success is critically dependent on my team’s ability and reputation to produce consistently well presented, flexible, adaptable and accurate financial models generally under high pressure situations. My opinion is that the best path to improving an organisation, indeed a markets, financial modelling habits is to use a set of guidelines which could be written down as simply as possible - even maybe a single page of A4 ?! This might sound ridiculously simple but such an approach would be..
This is the direction that Navigator’s standards are evolving; less is as usual more. In fact my aim is less than one page - wouldn’t that make life easier. Approaches I have seen so far externally to Navigator are akin to writing novel and starting by defining the letter A to Z before starting.
The spreadsheet programming market is undoubtedly fragmented, never more so than these days with lots of unemployed bankers on the market working as ‘independent consultants’. Its participants have a wide range of backgrounds and commercial drivers in sectors which historically tend not to embrace efficient communication but more generally focus on the detail and pro-formas- i.e: Engineering, Accounting, Actuaries, Bankers, Financiers and Project Developers
One reason why I think there is not a unified approach is because at its heart ‘spreadsheet programming’ is inherently quite simple - it is in fact only ill-constructed logic applied without guidelines that make it ‘complex’ - so bringing anything more than common sense and some simple guidelines is in my view over engineering the situation.
In a previous career I was modelling the diffusion of plasma’s in stellar atmospheres where the mathematics certainly was challenging and therefore the tools were sophisticated custom built algorithms in C++ or Fortan 90 running on super computers at NASA’s Jet Propulsion Labs. The point here is that the strength of the solution was appropriate for the problem at hand. Interestingly I recently read that the UN Rules of Engagement actually make provision for this too - in a slightly different context but the principle is the same.
Maybe surprisingly, in cashflow based financial modelling the user very rarely requires more than +,-,x,/ - and the occasional “^”. Even the most complex power supply contracts can generally be distilled to nothing more than elementary school mathematics - so given the problems are generally straightforward, the tools used to solve are nothing more than basic maths - lets not over complicate the guidelines
Well I don’t think they are - but I do believe the challenge is in having the discipline to communicate and apply them. From what I can see the more detailed you make the documentation the less useful it becomes because it leads to
Maybe some of the reason that this might have occurred
In recent times BPM Global have prepared one of the best approaches by forming the Spreadsheet Standards Review Board, although a recent meetings of modelling minds in London have reminded me that this document needed to be wire bound in order to work through it. Its content good and admirable but in my view it is too long and that alone stops the people that actually need to read this stuff from accessing it.
The popular acronym, K.I.S.S. is never so true than in spreadsheets programming and becomes critical in Project Finance transaction modelling.
You will go into the draw to WIN a FREE training course.
Instantly unsubscribe at any time. We value your privacy.
We provide leading project finance professionals with in-house and public training in Asia, Australia, US, Canada, the Middle East and South Africa.
FAST standard