My experience of building models for many years is very much in line with what F1F9 have described in their recent ebook 10 Principles of Agile Financial Modelling.
The ‘traditional software development lifecycle’ can work for very small assignments (i.e. where the model build is no more than a few hours). The reality of most of the model builds I've been involved in is that financial modelling is really about much bigger projects, which last weeks, months, or even years.
In the book Kenny states that “the model is usually a testing environment for business hypotheses and these hypotheses evolve over time”. In my experience this is spot on. In addition I can think of a few examples where a spreadsheet solution was initially just meant to be a prototype on which a ‘proper’ software development would later be based – but the spreadsheet prototype then became the system itself.
“Long detailed specification documents don’t get read”
“Long detailed specification documents don’t get read” is true in my experience too. On the few occasions in the past where this was attempted on projects I was involved in, it only got a very brief review, if at all, from the stakeholders required to sign it off. Only the results of a model itself, even if far from complete, prompted proper critical thinking about the business requirements of a model. Perhaps it should be noted that most people struggle to initially visualise a model and how to get started from a blank sheet of paper. A wordy specifications document usually does not help. But give the same people an example output sheet or template and they will be able to much better describe what they are looking for by reference to something tangible that they can already see.
However, we shouldn’t dismiss the value of written documentation relating to a financial model. It is normally considered good practice (and sometimes a requirement) to have a Record of Assumptions to accompany a financial model. Such a document is usually prepared at the end of a model build assignment and therefore may be viewed as not actually adding a great deal of value. From a model builder point of view ‘switching modes’ to write words, rather than numbers and formulae, can often be enlightening. I have experienced a number of times that the process of trying to articulate in plain English what (and why) particular formulae are doing what they are doing, has revealed that they were not quite doing exactly what was intended. But until that point everyone was confident that the formulae were accurate. It seems to me that writing words, rather than numbers and formulae, engages a different part of the brain.
From a model user point of view such documents have probably become like motor vehicle manuals – who reads up about using the radio in a new car before using it? Most people just press buttons and turn dials because certain fundamental functionality is simply expected to be there.
I have often been fortunate enough to have worked in a “split role”-type environment described. It has certainly worked very well when the circumstances permit.
Ongoing “face-to-face conversation” is essential. As much as key modelling assumptions may be written down and documented somewhere, it is dangerous to assume that a Chief Executive has read and remembered all footnotes from a document three weeks before. A 20-second conversation just before a major price negotiation meeting could have changed the finally agreed price by several £ million by reminding the CEO of a key assumption, even though that assumption was already stated on the face of the schedule he was working from.
After all, the model is only ever a means to an end; if it doesn't support better decision making, or a better negotiation outcome, then as modellers we haven't done our job.