My versus Our in Spreadsheet Models

My versus Our in Spreadsheet Models

Every now and then, horror stories are published about massive financial losses at enterprises which resulted from spreadsheet errors.

These stories are often shared by those developing alternatives to spreadsheet modelling and include negative comments together with sly hints about how their product is better. From the opposing side, there are claims that Excel is the best environment for financial modelling and that these errors can be simply eliminated by properly setting the model security or by accurately defining the control and handling processes.

The debate misses the critical, systemic reason for many problems with Excel: These errors take place when software which is fine for the individual gets applied to a much larger situation and is stretched beyond its natural working ability. This is the problem of a “my” versus an “our” approach to spreadsheet models. 

Growing from a “my” to an “our” spreadsheet model

I used to be an addict for spreadsheet modelling. I built models very quickly and hardly ever made mistakes in my spreadsheets, however complex they were. I intimately knew my spreadsheets and could do everything that we needed to advise our clients on M&A transactions.

Some years ago my (transactional) models started to progressively change into our (operational) models. The individual short-term models for ad hoc analysis and advisory evolved into a long-term corporate tool for regular management use and restructuring models.

During this change, the volume of data grew massively and the number of data updates became more frequent. Our models became exceptionally complex and were mutually inter-linked within a group of models. They were used repetitively by a greater number of people, who, despite not being experienced with financial modelling, were required to actively participate.

The model maintenance process became a nightmare. Calculation integrity was jeopardized with each model upgrade and we eventually spent more time fixing errors than effectively working with the data. When a change to our models was required, which was often, I was the only one who could work on it to ensure integrity. In addition, with each new user and every model change, there were more questions to field about the models and data. And I grew tired of this.

Looking for an alternative solution

Looking for an alternative and assessing other products pushed us to a higher level of frustration. No product on the market even remotely met our criteria for a financial modelling tool. The primary feature of “alternative” solutions was that they simply stopped at giving user analysis of past performance via cubes, offering various views on company KPIs. What a thrill! And, what about analysing performance and modelling? For this, we were advised to use spreadsheet and import data into their solution’s budgeting and planning modules (read import into columns labelled budget & plan).

That was when we decided to develop a new modelling tool. Not adopt an existing solution, but to build one completely from scratch.

We knew what “our” ideal model required

All we wanted in a modelling tool was something as versatile and flexible as a spreadsheet that possessed its do-it-yourself quality, was immune to obvious mistakes, could be easily changed or connected to data sources, and, of course, be available to team members for concurrent work. And we thought, just as many other corporate finance people, “Come on guys, it cannot be such a problem!”

We quickly learned that this was easier said than done. Our goals often drove us crazy as we discussed issues with the software development team and caused us to nearly lose patience when we encountered their interim solutions.

Today, we have a solution that exceeds the ‘all we wanted’ when we started the process.

MYGIDE is versatile and flexible, possesses that essential do-it-yourself quality, connects to data sources easily, is workgroup enabled and is significantly immune to the obvious modelling errors.