This quote is from a paper by British statistician George E. P. Box published in 1976 called “Science and Statistics”. Although primarily made in reference to the fields of statistics and analytical models, it can also be applied to financial and other models created in spreadsheets.
A model is a simplified representation of reality. The act of simplification means that all models are wrong because they do not reflect all elements of reality. To have complete accuracy would require e.g., a map on the scale of 1:1. This may well be accurate, but it would not be useful as you could not do any sensible route planning with it – it would be simply far too big and unwieldy.
On the other hand, if we accept a loss of some accuracy, we can have a model which is “wrong” but useful. In physics, for example, the Bohr model of the atom is “wrong” but can nevertheless be very useful in predicting and explaining events in the real world.
The same principle can be applied to spreadsheet models. The key is finding the “sweet spot of usefulness” between accuracy and complexity on the one hand and simplicity and ease of use on the other.
This is not always easy but, as with most skills, you can get better with experience.
Here is my advice to help you:
|
1. |
Think about the level of detail you need in your model before you start work on it. |
If appropriate, discuss with colleagues, model sponsors or users before starting. Always bear in mind: (i) the model purpose – what content and functionality is relevant and useful? (ii) the users – what functionality will they understand and be able to use reliably and efficiently (possibly after training)? |
|
2. |
Focus on the essentials and use the 80:20 rule. |
Often, 80% of the results can be explained by the 20% most significant factors, so focus on these. Minor costs (for example) should not be planned individually but in aggregate as part of an “Other costs” position. If appropriate, focus on the top 10% of factors first to get a working model up and running which can be used for early decision-making and expanded later. |
|
3. |
Before adding more complexity, think about how significant the effects could be on results or usability. |
If the increase in complexity would bring only a minimal increase in accuracy or functionality, then maybe you should not make the change. Or perhaps a simplified version would suffice. For example, planning sales at individual product level may be too detailed. Planning at brand or business area level may be more suitable. |
Once you have made your decisions, be ready and able to explain them.
I will conclude with another quote from George Box which summarises the situation very well.
“All models are approximations. Assumptions, whether implied or clearly stated, are never exactly true. … So, the question you need to ask is not "Is the model true?" (it never is) but "Is the model good enough for this particular application?"
