Forecasting Variability

As I continue my journey to achieve a FinOps Professional Certification, I've just completed reviewing the artifacts for the Forecasting module, including an amazing video recorded by the inimitable Dieter Matzion. The FinOps Foundation has done an amazing job of introducing a blend of voices - all are either members of the FinOps Foundation and/or FinOps Professional Certified.

As I listen to Dieter's guidance, several things critical points to mind.

1. Forecasting variable cost models is significantly more difficult than traditional ITFM costs
2. Forecasting variable costs requires frequent review and updates
3. Finance is not alone in building forecast models - engineering and product leaders will likely also be involved... and it may be their first time, so patience is a virtue!
4. Forecast vs Budget vs Actual in the cloud is very likely to have variance. The goal is still to minimize those variances, but it is important to understand that they will exist, and that is normal.

I recall when I was first asked to help generate a forecast for an application I was supporting. Thankfully for me, I was uneducated on the ways of FinOps at the time, and my application was one that was lifted-and-shifted into the cloud with no optimization having been done to it. While that made it simple for me to forecast the spend at the time, it was costing the organization more than it needed to because I wasn't doing my due diligence. As I began to optimize my systems, variance became very prevalent and I started to sweat a little more with forecasting activities. Today, I prefer to use 3rd party tooling to help with my forecasts as I am no longer watching over only a small handful of EC2s. When I do a forecast today, it is typically while working with a large client, generating several forecasts for each of their application teams.

One question I often receive is, "How often should a team review their forecast?" The answer is not one-size-fits-all. For applications that utilize highly-scalable architectures, the forecast should be reviewed more frequently than an application that has a small handful of systems which has a few that turn off after-hours and on weekends. However, as a general guideline, I typically say it is safe to start with a quarterly review cadence and move it up to monthly frequency if your variance is still higher than you want it to be. And, of course, the forecast should always be reviewed when there is a change to the architecture.

Forecasts are not something to fear. At the end of the day, it's an estimate to help the business to understand how it needs to invest its funds to maximize profitability through its resources. As Henry Ford was once quoted, "Obstacles are frightful things when you've taken your eyes off of your goal." Becoming great at forecasting will make you better at receiving the necessary budget for your needs.