The Problem

The development of a project Financial Model incurs huge sunk cost with untapped return on investment. Building a fin model costs a significant amount of money. It inherently models knowns and unknowns to portray an outcome, or numerous possible outcomes. This portrayed outcome is deemed to be substantive enough to execute a contract transaction, but beyond this point all that lovely data, and forecast outcomes, are generally put down, and all that value the model contains, reflecting that huge investment, is simply not harnessed.

Project Financial Models are designed and built as dynamic models but are not managed or utilised that way. Project financial models are built to reflect the commercial principles of the transaction. With so many moving parts, the model has to be built dynamically, to accommodate variables such as indexation, reviewable services, benchmarks services and contract modifications. Built this way enables the fin model to present the changing outcome(s) as these dynamic variables are realised. But it is not used this way which is another invested value forgone from the fin model.

Lack of dynamic management results in costly reactive requirements – audit/ variations etc. Just because it is not actively managed this way does not mean that it is not needed in this manner. When the project is audited, or refinanced, or undergoes a major modification, the model is required to be made current. Unfortunately retrospective action is more costly than proactive action. Modelling firms build the fin models in a way so complex that these retrospective actions are a significant, and costly, piece of work, and the urgency usually related with the requirement presents them with all the leverage.

Ad-hoc systems, bespoke and costly tools, and inefficient, time consuming human interaction is unnecessarily depended upon for financial management. The project fin model is usually for a project spanning upwards of 20 years. During this time multiple generations of stakeholders come and go, each with its own way of doing things and, in the absence of a defined set of project protocols, each with their own tools, methodologies and interpretations of rules – some of which (e.g. rounding) can skew figures by a material amount. Additional issues relate to concentration of knowledge and training – as such a subjective way of doing things will tend to result in one or two individuals have exclusive understanding of tool functionality.

No single source of truth results in risk of errors and inconsistent data/ reporting. Similarly, where multiple individuals are utilising multiple tools to report on multiple projects, there runs a risk of human error and a reliance on multiple data sources.

No mechanism to link the financial model to contract. The contract and project fin model combine to reflect the true parameters and intentions of the transaction. Without the other, one does not tell the complete picture and vital information is lost. For example, the fin model provides unequivocal information on what has been paid for, and what has not – i.e. what is included in core services and what might be seen as a modification. Additionally, the contract does not give clarity on how some commercial principles have been applied to the transaction, which can only be clarified by the fin model.

No synergy across project portfolio financial models. While multiple projects may be reported upon in common metrics, the mechanism by which it is done relies on all the resources and tools observed, and presents all the issues in point 4, along with those in point 5. It also presents operational aspects that could be improved from an efficiency basis. Multiple sources, undergoing multiple and subjective analysis, to synthesis data into a common format for portfolio purposes.