Financial modeling lessons come in three categories. The first and most common are Excel tips and tricks. How do you use the vlookup function to not return a N/A value when it doesn’t find a result. The second are modeling related suggestions, and there are a lot of them – common financial modeling mistakes. The third and final category is where we don’t find as much advise. On the Zen of building models.
Here is a short list from the third category. On the design thinking behind building models. Three minutes to get that modeling edge with seven meta lessons that you should keep in mind before you sit down to build any model.
One. Start with simple models. Simple models are better than complex models.
Easier to explain, easier to debug. More graceful and elegant.
Reduce complexity and parameters. Each parameter you reduce, simplifies your design.
Complexity in language and models is not necessarily a sign of mastery of the arts. It is a manifestation of inexperience and occasionally insecurity.
Two. If you do have to build a complex model, break it down into simpler components.
For example, forecasting revenue may requires you to forecast market size, demand drivers and your market share.
Build a separate model for demand and link it to your revenue forecast. Sub model simplify design and improve clarity. Also, easier to reconcile and trace.
Lego pieces that fit together.
Three. Form follows function.
In old school computer programming when we learnt about modularity and function design, we were taught to limit a function to do one thing only.
The same principles translate to modeling world.
Break your models down into sub models. Let a sub model do one thing well.
Four. Calibrate with the real world.
Whether its demand, market share, growth, profitability, or scale, look around and find benchmarks you can compare your results against.
For instance, look at rental expense. How would you model that?
How many employees? How much sqft of office space per employee? Cost per sqft? Rental inflation every year?
Calibrate the figures with benchmarks in your market. How about estimating expense for an insurance company?
In most markets, Insurance companies tend to be more inefficient and poorly run than banks. Technology companies tend to be more efficient and productive than both.
How does your model compare with your related market benchmarks? Don’t build your models in isolation.
Five. Do a peer review.
Ask a colleague or fellow professional to review your model. Do a model walk through with them. Use them as a sounding board.
Sometime presenting your approach and results out loud is enough to highlight faulty assumptions and weak segments of your model.
You would be surprised how much you can learn once you put on the hat of a student or an apprentice rather than a master.
Six. No dating at work. Do not fall in love with your models.
Be ready to throw out everything you have done.
Sometimes the best approach is to trash everything and start again. It’s easier to rebuild than make adjustment and changes to an existing structure.
To do that you have to be open to critical feedback. Difficult if you are blinded by love.
In consulting there is a strong tendency to reuse existing work on new engagements. That often marries you to outdated analysis and framework. There is nothing wrong with re-using old work as long as its a good fit with your client needs. But don’t fit all engagements on the one framework you know how to use.
Seven. The end goal is not the model.
The end goal is the journey of discovery and exploration you go through when you build a model for the real world.
You understand relationships better. You use the model as a tool to explore what if scenarios. A good model building experience is like a well structured tour. You only get to see a small part of the city your are touring, but it’s enough to give you a feel for what that city stands for and represents.
Use models to explore the structure of the problem you are trying to solve.
Bonus. Eight. A model is only as good as its user.
It takes more than Excel to build a model for the real world. An inexperienced driver can crash expensive racing vehicles on an F1 circuit. An experienced driver doesn’t always need an edge.
Every iteration of the model you build is likely to be better than the previous one because you have spent a bit more time with the problem. As your understanding of the problem improves, your models will also improve.
To be one with your model, in Zen speak, you first need to become one with the problem.