Browse by category
You probably know him as "The FP&A Guy." For nearly 15 years, Paul Barnhurst has been a leader, influencer and educator in the FP&A community.
In 2021, it was estimated that we created 2.5 quintillion bytes of data every day. That's 2,500,000,000,000,000,000 bytes of information daily. It was also estimated that this volume will double every two years going forward. Is it any wonder, then, that during my Introduction to Financial Modelling session at Excelerate =SUM(it) 2022, when we polled the audience on which pain points they experienced with their financial models, the top answer at 37% was "too much information."
Learning how to look through data and decide what to include in your model is a financial modelling fundamental skill every finance professional needs to have. In this blog post, I'll take you through five questions you need to ask yourself, when building and designing a financial model, to decide what information to include--and what to exclude:
When preparing to build a model or conduct an analysis, the first question we must ask is: "What is the main question I'm trying to answer?"
Many times, the question we're trying to answer is either known or given to us when we're asked to build a model. However, if we're unsure, we should go back to our stakeholders and ask them: "What are you trying to accomplish with a model? Why do you need it?"
We should keep asking questions until we clearly understand the question that our stakeholders need answered. This is an iterative process that requires us to drill down and continue asking questions until we get to the root cause of the problem that needs to be answered. It's similar to the method we'll use to determine what drivers we should include in our model.
Once we've determined the question we're trying to answer, we need to ask: "What are the key pieces of information or main drivers I need to get that answer?"
When building a model, we'll have a few drivers that are critical to your model. These drivers, if not included, will materially impact the final outcome. Determining which drivers are most important requires applying a structured framework to the problem.
One framework we can use is the root cause analysis. It requires us to ask: "What are the main inputs or activities that will drive the outcome?"
For example, let's say we're building a model to forecast call center expenses. We could start by performing a root cause analysis for the call center model to determine what drives our call center expenses. Notice the tree diagram I've built to map out the main drivers needed for our call center model. This visual analysis can help us better understand the different line items that make up your model.
To build our model for "Headcount" and "Facilities," we can use the lowest level of each section as the driver-based assumptions. In this example, we have seven drivers (five for Headcount and two for Facilities):
After reviewing these seven lowest level, driver-based assumptions, we could break each down further. For example, we could get more complex by breaking down "Payroll Taxes" into "Social Security," "Unemployment" and "Medicare" or "Utilities/Maintenance" into "Telephone" and "Electricity."
Before deciding whether to segment our drivers further, we must ask: "Will the increased complexity of adding more drivers improve the accuracy of the model enough to justify the increased complexity?"
If adding the new level only provides a small incremental improvement in accuracy, but requires a lot of additional effort, then it's probably not worth it. However, if the new level of granularity materially impacts the model outcome, then let's include the lower level in the model.
Learning how far to drill down--and when to stop--takes practice and varies by project.
Let's look at one more example. This time, we're forecasting revenue for a business that sells only one product.
For this simple "Revenue" model, we have two drivers: Volume and Price. For simple models, this may be all we need to get the answer to our main question. However, in some cases, it may require us going down a level and further breaking down "Price" and "Volume"--for example--by different sales channels.
As we analyze, we should stop at every level and ask: "Have I captured the material drivers?"
If yes, we move on to gathering the necessary data to support your assumptions for each driver.
If not, we keep drilling down.
Using a structured framework--and performing a root cause analysis--will help you reduce the time you spend sifting through data to determine what to include in and exclude from your model. It's a financial modelling fundamental skill every finance professional must have.
When you have too much information, start by asking "What is the main question I'm trying to answer?" and finish by capturing all the material drivers.
See how the decisions you make today will affect your bottom line tomorrow, with Vena.
