On of the most common mistakes in project finance modelling is incorrect coding of delay scenarios. The main reason for this is that it is not implemented as part of the core functionality of the model when it is first constructed, but rather squeezed in by a bank analyst as part of the credit analysis.
Since the person coding the delay functionality is often different from the person who originally constructed the financial model it can be challenging to understand all the implications of changing the model logic in something as complicated as a delay scenario.
Example of delay scenarios
- Delay of start date of construction
- Delay of completion (i.e. construction takes longer than planned)
- Delay of divestment date
- Delay of acquisition date
- Delay of capital raising
- Delay of debt refinancing
How can we quickly estimate the accuracy of a delay scenario?
One quick method of getting an estimate of the accuracy of a delay scenario is to prepare a data table (manual or dynamic using the Excel Data Table functionality) with cashflows from a number of scenarios. If these cashflows are plotted then it is often possible to visually identify big picture problems.
This method can save you hours of work if you are on performing your own credit analysis but are not responsible for the modelling on the transaction. You can simply prepare the outputs as illustrated below and send this back to the modelling bank or the sponsor for clarification.
Preparing a table of cashflows for chosen scenarios
In many cases it makes sense to choose the scenarios that you will be including in the credit or investment analysis. In the example below I have illustrated the concept with CFADS (Cashflow Available for Debt Service) but in your specific case it may be more useful with another metric or a combination of several metrics.
Suggested cashflow metrics
- Operational Expenses
- Debt Repayments
- Cash account movements
Identify problems in financial modelling of scenarios
Generally speaking cashflow movements in scenarios or sensitivities should be smooth and without spikes. In the example in Image 2 there is a big jump in CFADS in periods Ops 1 and Ops 2 which would be a reason to further investigate the correctness of this scenario.
Of course there could still be problems in all the other scenarios too and this method is a top down approach to finding BIG mistakes first (while you can still get someone else to fix them for you!).