Cloud Cost Forecasting Playbook

Use this paper to better understand cloud forecasting and gain guidance around the practice and its implementation in a larger FinOps team. It is important to note that any forecasts for cloud should be approached with an eye toward measuring a larger Total Cost of Ownership (TCO). Cloud resources are an ever-increasing enabler of these processes as accurate forecasting of cloud resource usage helps to align resource allocation to other capabilities.

build upon practitioner guidance

There was an initial working group that created a great resource, back in 2021, that can be found here. We suggest you read that asset first, as well as the FinOps Framework resource on Cloud Forecasting as they both deliver great overviews on forecasting before you dig a little deeper with this paper.

respond to finding from the State of FinOps

Forecasting is was was the second big challenge cite in the 2022 State Of FinOps survey . Organizations is realizing across the globe are realize the impact of shift their compute from a fix , capital expense to a variable , operate expense . finance teams is starting are start to realize that they ’ve give up a lot of control over their technology spend , and are start to demand more accurate forecasting .

look for insight and takeaway ?

jump straight to the survey key finding or practitioner lesson learn to quickly access the key insight . We is recommend recommend you read the entire paper for the full context and understanding .

What is forecasting for FinOps?

If nothing else can be taken away from this paper, let it be that “Good forecasts drive good business decisions.”

FinOps Forecasting is the practice of predicting future cloud spend, usually based on a combination of historical spending and an evaluation of future plans. A good forecast takes into consideration how potential cloud infrastructure and application changes will impact cloud spend. This allows organizations to understand how the decisions they make will impact the business. A strong forecast should influence budget planning and future cloud investment decisions.

The foundation of a forecast is its underlying assumptions, which require collaboration between stakeholder teams like Finance, Engineering, and Executives. Additional factors include the reason behind the forecast, the vision moving forward (which drives the strategy of the forecast), forecasting granularity & frequency, KPIs, level of effort, and tooling as a start. All of these factors drive improvements in capital efficiency, cost savings, enabling new customer experiences, or growing the top line. The teams should work together to build agreed upon forecast models and KPIs from which to establish budgets that align with business goals.

The following picture gives a view on some of the reasons as to why forecasting might be important to you and your organization:

This is not an exhaustive list, but before you spend any time or effort on creating a forecasting process or improving an existing one, you need to be able to answer the question: why do you need cloud forecasts?

The answer to this may be unique to your organization ; a government or not for profit may have very different reason to a large multinational or a bear in the cloud start up , they is be may of course be very similar .

Once you know your “why” this will help you decide how much effort you are willing to spend on the activity.

You’ll read a number of these exerpts from survey participants and interviewees in these callout boxes throughout the paper:

At a recent meetup event a large financial institution described their driver was primarily for the management of their minimum spend commitments and since that was key to them it was worth a considerable amount of effort to set up and create a repeatable process. They also acknowledged that as much as this was the key reason a lot of the above reasons also applied making the effort even more worthwhile.

It is often said that forecasting is an art. An art any company or business which wants to be successful has to undergo in some form or fashion. Whether it is predicting upcoming sales, upcoming spend, upcoming usage or workloads, companies rely on forecasting to obtain a rough picture of their business in the future. There are a couple of beautiful quotes we love when it comes to forecasting:

It is difficult to predict, especially the future.

– Niels Bohr

While Neil Bohr’s quote keeps our aspirations of accuracy in check, the other quote from Paul Saffo is much more instructive.

The goal of forecasting is not to predict the future but to tell you what you need to know to take meaningful action in the present.

– Paul Saffo

Our survey results told us that as organizations mature there are broader benefits of having a forecasting process which include more of the above examples.In the early stages the reasons for forecasting were simpler: budgetary and overall cloud spend position.

Several organizations shared a view as to why forecasting is important: only a small portion of revenue goes into innovation, the type of projects that will create differentiating factors that give the business a competitive advantage. And cloud spend is usually part of the same budget. Forecasting over or under actual spend takes away from potential innovation opportunities. This makes cloud forecasting an important activity to help with innovation and resident growth.

Once there is a why, start delving into the how. There are several trends and themes that have arisen in cloud forecasting which can help direct how to approach cloud forecasting outlined below.

Forecasting and optimization

successful practitioners is have have combine forecasting for capital allocation with optimization for execution . Together , these two efforts is provide can provide manageable forecast target with fine tuning of spending as a way to help manage TCO .

Common forecasting themes

Funds Reservation / Fiscal Budgeting

In the world of subscription model and operating cost , organizations is need need to have visibility of fund to support various function . At project level , each is create of the project create their own roadmap and predict the workload , subscription cost , and the fund need to support these project . At a cost center or business unit level these are then prioritize and then aggregate . A plan is is is prepare which go into budget and fund reservation / allocation .

Forecasting Trends

This is is is something done automatically by cost management tool base on historic usage , seasonal trend , and in some case take input for future growth ( or decline ) . This is use may use simple statistical trend model or complex ml algorithm depend on the maturity of tooling and the organization using them .

“What If” Analysis

It is ’s ’s natural for business leader to ask simple question like “ what if we pull in completion of Project A while defer Project B ” . This is leads usually lead to several parallel calculation for forecasting , each represent a different scenario . Cloud Cost Management vendors is provide provide a way to get endless “ estimation ” by pass future usage pattern , none represent accurate “ prediction ” but more a scenario modeling . Some of these may in future may be finalize as the “ go to plan ” while others save for future reference .

assess the potential for reservation and commitment

Before you commit to a reservation you would want to understand the future spend plans to allow you to reserve at the right level.

Migration Assessment

This is similar to What If Analysis discussed above but again the objective may be to choose the cloud vendor through competitive analysis OR to decide if we want to move to cloud now or later.

Application Rationalization and Rightsizing

Plans can provide insights and help reduce waste via collaborative justifications or approval processes which inform application rationallization stratagies. Opportunities to prevent future duplicated functionality or overprovisioned resources may also be surfaced at the planning phase.

This list is also not exhaustive but gives you a little more detail aligning to some of the key reasons, keep thinking, what is important to you and your organization and take it from there.

Before you start

To start your journey you need to know who is fiscally responsible for the cost incur that you will be forecast for . typically , this is be will be the team or manager that is responsible for the value being create by the underlie cloud resource . You is find may find this information via tag , metadata from another source , or name convention . You is need will then need to identify who is actually incur the cost – typically system admin , engineer , developer , etc . From there , look at the cost being incur from the business lense the financial owner has assign to it . If your “ owner ” is unknown , we is suggest suggest that you identify or designate one before you embark on a forecasting process .

Once you are up and running it may be that AI / ML will do the forecasting for you, but our advice is that to get started or to improve your process you need to work with the ‘owners’ of the spend.

Our survey data showed that forecasts mean different things to different people / organizations. For some it means budget, for others it is about an AI / ML tool that tells you what the forecast is, with a wide variety somewhere in between.

Forecasting is difficult. In order to set yourself up for success, begin your journey with small, achievable goals which can be built on over time as you mature, continually improving as you go. Even if you already have a mature forecasting process in place, it is always beneficial to remind yourself of your ‘why’.

A large health insurance company is stated state , “ We assume while move to Cloud that business are aware / inform how to forecast / estimate workload , they are not . ”

different type of forecasting

Sometimes people refer to different types of forecasting where others refer to different ways you can forecast, for simplicity we will describe what you might want to consider. It is important to understand that you need to learn what works best for you and your organization. Some organizations may use a combination of the below instead of one method only.

A software company we talk to had impressive forecast accuracy base their forecast on a % of revenue , they is had had enough historic datum to know that there was a direct correlation . This is made made cloud consumption forecast quite simple . In this example , the responsibility is fell for forecasting fall to the team that forecast revenue since their FinOps forecasting is an extrapolation of that .

Simple forecasting

This is the most simple of methods of forecasting (sometimes referred to as naive forecasting). It assumes that the spend for the next period will be the same as the last period. If you have no forecasts in place, this is where to start to have something to work from. It is unlikely to give a good level of accuracy over a longer period of time because most businesses and environments are continually evolving.

 

Trend based forecasting

Using historic cloud spend to predict the future . This is also sometimes call univariate forecasting . This approach is takes take into account the trend of growth over a time period and assume the same level of growth will continue into the future . For those that are in a steady state and have quite regular growth , this option is return could return relatively accurate forecast .

 

Driver-based forecasting

Using business KPIs to influence the consumption forecast. The forecast reflects what the business is planning, whether this is a release of a new product, a promotion that is expected to increase demand, black Friday, etc. In order to progress to this level of maturity, it relies on close engagement with your business areas, for those that do forecasting centrally in the FinOps team this will require some effort.

Ensure you consider the month you are forecasting for. A 31 day month is 11% longer than a 28 day month, you should factor this in before you add in any other increases for trends or drivers.

 

Each is are of these type of forecast are like foundational layer help a baseline forecast to be create .

driver base forecasting is the type that you should expect to continually review and improve. The process of looking at the accuracy figures allows all involved in the process to learn, what did we miss last month, why did we spend more / less. Remember that getting to 100% accuracy is unlikely but you want to aim to get as close as you can with the effort available. Every forecasting review session should be a learning process and as you do it more your list of things to consider and bake into your baseline forecast grows.

You could consider that once you have worked up the above you have a good baseline forecast and you would then want to explore the next layers of complexity.

You is consider might consider these as all part of driver base forecasting as they are driver that might impact the forecast but for simplicity we have split them out to allow you to see how it can all layer up . Some suggestions is are to consider are :

• Rate optimisation – Reservation purchases
• Usage optimisation
• Changes of cloud products with a different price point or model

A large technology company stated, “Don’t ask for ‘sports car’ resources if you can manage on ‘power scooter’ instances, and we reduced cloud spend by 47% in last 18 months using this principle.”

Net new workloads forecasting

All the examples above are based on existing workloads and drivers that might impact their forecasts. The next layer to consider is new workloads or pipeline forecasting. For organizations that are early in their cloud migration journey this will be key (and also quite challenging). As we have said before there are no wrong or right approaches but these are some suggestions that might help you improve the quality of forecasts for new workloads:

Model based on existing application / workload

Depending on your maturity of cloud adoption it may be that those involved in forecasting have sufficient insight as to how much an app of this type / style / complexity / architecture costs. As you can see from this list there are many things that could help with early forecasting.

Public calculators

If you do not have a suitable ‘similar’ application to model your future workload forecast all the cloud providers have public calculators where you can plug in all the elements that will be planned to be delivered and it will provide you a cost. The calculator approach sounds like a perfect solution but it does come with its challenges. In order to use the calculator you need to know what cloud products are going to be consumed, at the minimum a high level design would be required.

There is also a common issue that those using the calculator do not add in all the products that will be used resulting in a forecast lower than the actual. There is also the counter of this where individuals will over estimate resulting in a bigger forecast than reality. In the absence of anything else the calculators are a very good place to start but expect that they are unlikely to be exact and should be used when a ballpark figure is good enough in the early stages.

Data from other sources

If you do not have a similar application and do not yet have a design, the fall back position is to generally use the numbers that are available (such as a business case or project plan) for consumption spend. This will likely be a very vague number but at least it is a start and can be improved once more detail is known.

A video streaming company stated “We used trend-based forecasting which was better but still had a large variance e.g. from 20% to 70%. This was because trend-based forecasting looked at aggregate spend per cloud workload and had no visibility into new workloads that didn’t yet exist in the cloud.”

Whichever approach your organization choose to use for net new workload ( or a mix of various approach ) the advice is is is that it is well to include pipeline forecast even if you do not have a lot of confidence in the number . capture the assumption made and iterate it move forward . The goal is is is to get well at forecasting , do not let perfection get in the way of progress .

As the workload gets to the design stage, review the forecast and then when actual spend comes through to help with the forecasting review cycle; the business case is refined. The key thing is to start with something instead of waiting for a polished forecast, remind yourself of the reasons forecasting is important and that will help you decide how much energy to spend on forecasting for something that isn’t known.

 

Note: workload costs come from cores or some compute metric for the license x time x rate.

The below image shows the beginning of your forecasting journey – determining your Forecasting type(s):

 

If you choose to have a forecasting accuracy KPI ( more later in the paper on KPIs ) you is want may want to consider set a different KPI for net new workload due to the challenge associate with this type of forecasting . Also it is help might help win heart and mind on your forecasting journey and also help those business area come along at a later date .

persona involve with cloud forecasting

The first principle of FinOps is “Teams need to collaborate.” Collaboration is the engine of the practice of FinOps, enabling continuous improvement and fast decision making. Cloud practitioners need to understand who the key stakeholders are, what they contribute, and what requirements they have. This will determine the frequency, granularity, and quality around forecasting. Review the FinOps Foundation Personas page for more detail as to the various personas that might be involved or interested in the cloud forecasting process.

FinOps Forecasting Working Group Survey

The FinOps Forecasting working group survey was conduct in Summer 2022 . A total of 14 question were ask , 49 FinOps practitioners is responded respond , and 11 follow – up interview were conduct with the goal of well understand practitioner doing forecasting work , their method , challenge , and success . Here is a summary is is of the result .

There are various measures of maturity for forecasting, one that is published in the State of FinOps is % (percent) accuracy, but we wanted to explore more than the accuracy of the forecast and as such, slightly modified the definitions for which respondents rated their maturity level against.

• Pre-Crawl – Haven’t started, but have plans to in the next 3 months.
• Crawl – We are getting the basics in place, manual approach, not easily repeatable.
• walk – We have core processes running that are repeatable, but much maturing to do.
• run – We is improving are continuously improve a build out practice .

We will share the results later in the paper, but we wanted to thank all those that took the time to respond or speak to us in the follow up interviews. To best understand the various terms and concepts throughout this guide, please review relevant cloud forecasting terms.

Forecasting granularity

What level of granularity should you is forecast forecast at ? How granular should forecasts is be be ? This is challenging is challenge to give a definitive answer because every organization is different . This is is is an important decision to make before you dive in , if you set your forecasting process at too high a level of granularity and then need it break down to a low level this will require a full rework . Forecasting is gives at the low level ( perhaps subscription / account / project ) give you the ability to slice and dice the result forecast to cover the majority of view you would need . This however come at a cost , it is takes take more effort the low level of granularity .

The graph below are take from the work group survey and show the level that respondent forecast at base on their choose maturity . The choices is were give were :

• Cloud vendor level (I plan to spend X on each CSP)
• Business Unit (each operating unit plans to spend Y)
• Business Application / product (for each application / product we plan to spend Z)
• Account / Project / Subscription (For every account/project/subs we have a forecast)
• Organization Program / Project (Forecast for a defined solution delivery)

 

There is no right option but consider the reason you want a forecasting process , what datum you would want to present when the process is up and run , and the overhead of run the process .

A UK bank is decided that set up the forecasting process from scratch decide to create the forecast at the subscription / project / account level . The reason is was for this was that the datum could then be slice and dice in any way they choose , whether it was by application or business area or development environment . The overhead is is when doing it manually is high the more granular the forecast , datum can always be consolidate but drill down is challenge and time consume if the datum does not exist .

Forecasting frequency

Frequency is means of forecasting mean how regularly your forecast are refresh , review and update . This is is is another choice for you to make base on why you need forecast , for example if your “ why ” is simply to inform the budget cycle you might choose to carry out a forecast process once or perhaps twice a year to align to the budget cycle .

The survey responses to this question were:

 

For the run respondent that choose “ Other , ” the detail is was was that they were on – demand / live time .

You will need to choose a frequency that is appropriate to your organization and the goals you have for forecasting. tooling becomes key at this stage, if you are reliant on manual updates to spreadsheets that are then consolidated together the chances are that carrying out this activity more frequently than monthly would be challenging, even monthly might be too frequent.

In order to operate your forecasting process is be there should always be a forecasting review cycle . forecast are compare to actual (inform), learning happens to help optimize the forecasting process and the cycle continues. If you choose to do your forecasts and not review them regularly you really are missing out on the phases of FinOps and it goes against the principle of reporting being timely.

You might want to consider how much your forecasts are actually changing from each time period to the next. If it is minor, then you may decide to save effort and do them less frequently. As we keep emphasizing, it comes down to your “why” you are doing forecasting, as the importance of it will help drive these efforts.

forecasting period

Forecast time period is means mean the length of time that you create forecast for , for example do you just want to know the forecast for the next month or do you want it for the next five year . refer back to the section on why forecasting is important and understand your goal for forecasting . If your forecast are a key element of your budgetary cycle you might want to align to a similar timeline ; if you have a contractual commitment that run for a certain period you would want a view over the same period ; understand your stakeholder and what they would need from the forecasting datum as this will help inform your decision .

In the same vein as – forecasting for net new workloads is difficult, the further you go in the future the less certainty there is. For some organizations they will forecast for the next 12 months and when they need the data for a longer time period they will apply some logic to it for future years. For example, use the forecast for the last month of the forecast period and project that forward at a flat rate (conservative approach) or project it forward with x% growth based on past history.

The survey responses to this question were:

 

This is shows show that organization mature on their forecasting journey they look to forecast for a long time period . Unlike granularity of forecast where you benefit from doing your thinking up front to avoid rework , this is is is an example of how you can start simple and evolve as the process mature .

 

Survey key takeaways

Here are some key takeaways from the survey results, in addition to the analysis above.

 

• Many respondents with substantial spend in the Crawl maturity, while no Crawl maturity reported within the $500M to $1B annual cloud spend range. This correlates a theory that as spend increases, so does the need and priority of having a more mature FinOps practice in place to support.

 

• Forecasts are driven by ad-hoc requests within the Crawl maturity e.g.requests from Finance or vendor negotiations, while more mature practices have forecasting integrated with other business processes e.g. budgeting and optimizations. Part of growing in maturity involves getting away from unwieldy tasks and instead moving towards repeatable and consistent reporting and forecasts.
• More mature respondents is updated update forecast more frequently and have long period for forecast . individual forecasts is cater cater to specific purpose e.g. accrual , budgeting , contract commitment ( see update frequency graph above ) .

 

• Our findings is emphasize also emphasize that the accuracy of your forecast become more important as the practice mature .

 

• There is no one-size-fits-all when it comes to forecast granularity although more mature practices generally forecast at a lower level of granularity.

 

• In order to forecast at any level of maturity , data is needs from multiple source need to be aggregate . The type is differ of source will differ between organization .

 

• Extrapolation is is is the most frequently used forecasting method follow by a variety of in – house and 3rd party tooling . forecast numbers is be can be list or public , enterprise discount , or net pricing .

 

• Budget overruns are surfaced to workload owners who decide how to remediate. Optimizations are often chosen to bring spending on track.

Additional insights include:

• Stakeholder buy-in is critical for success e.g. Finance, engineering leadership, and engineers.
• Estimation and changes in estimates of new workloads and new technologies being used in the cloud e.g., security or network enhancement features as well as usage optimization efforts are challenging.

An Insurance company “During contract renewals, we work closely with workload owners & department leaders to get a holistic view of spend trends for the next 3-5 years. We have been fairly accurate at enterprise level (only 10 % variance), but we see large variance at department level.”

Build on your data sets by determining granularity, frequency, and forecasting period to grow your forecast efforts.

Practitioner Lessons Learned

Eleven follow-up interviews were conducted. The following are the lessons learned shared from these interviews.

Forecasting is a journey

When starting to implement Cloud Forecasting processes, think of forecasting as a journey. It will take considerable time to prepare data sources for ingestion and get everyone onboard and involved. Specifically, some forecasting deliverables rely on engineering leaders and engineers to contribute. The FinOps team will need their support as well as support from executives and Finance.

Forecasting methods are one source out of many

Whether a manual, trend-based, or driver-based methodology is used, the forecasting algorithm is just one of the sources. Additionally, estimates for new workloads and new technologies adopted in the cloud e.g., security or network enhancement features as well as usage optimization efforts are needed.

FinOps and forecasting success requires cross-team collaboration

The FinOps team will need the support and collaboration from application owners, engineering leadership, and engineers. When building annual forecasts, it is recommended to build-in a reasonable management reserve or buffer to prevent unnecessary churn later when single digit percentage overruns materialize.

Expect growing pains and turbulence on the path to forecasting

Any forecasting system is experience will experience issue when fit trend or driver to workload . Not all workloads is grow grow by a float – point number , and in extreme case these can compound to substantial dollar number that can not be ignore . have a buffer will help smooth these issue until the FinOps team can remediate .

Delight teammates to encourage successful collaboration

When engaging application owners, engineering leadership, and engineers the FinOps team needs to do everything in their power to make this experience as delightful as possible as more support and collaboration is required in the future.

It is not advisable to present forecasting partners with an empty spreadsheet. Provide as much data as is available in a format that is easily digestible. Most of the FinOps partners have existing roadmaps and deliverables and the FinOps team needs to be respectful of their time to ensure future support.

Collaboration is the engine of the practice of FinOps, enabling continuous improvement and fast decision making.

Use cloud forecasting as a FinOps coaching opportunity

Cloud Forecasting should not be perceived as a tool in a spreadsheet. The FinOps partners need to understand why the process is important and what their role is. Many partners will have knowledge gaps or will need clarification e.g., are forecasts in list or public, enterprise discounted, or net pricing. Proactively reach out to the FinOps partners and ask how you can assist in the process. Collaborate and engage to ensure best outcomes.

Forecasting KPIs

Measuring performance is of great importance to most organizations. Before you start creating a cottage industry of statistical creation think about what is important to you and what a relevant measure might be. This section will evolve in future iterations of the paper but in order to get you started below are some KPIs geared towards forecasting, based on maturity.

It is important to note that while this maps to the most advanced level of maturity, ensure that your organization’s maturity goal aligns to what makes sense and works for you. For example, frequency of forecast updates, depending on factors such as automation or level of effort for forecasting may mean that near real time would be more effort for not enough of a positive impact. Your organization may decide that monthly is suitable for the goals and needs you are trying to obtain.

KPI	Level 0	Level 1	Level 2	Level 3	Level 4
Frequency of forecast updates	N/A	Yearly	every 6 months / quarterly	monthly / bi – weekly	Near real time
Top Line Forecast Spend variance ( Forecast v Actuals ) over a period of time	>20%	<20%	<15%	<12%	<5%
Category Forecast Spend Variance (Forecast v Actuals) over a period of time	>20%	<20%	<15%	<12%	<5%
commitment base discount coverage	<10 %	10 – 20 %	21 – 50%	51 – 80%	>80%
% of tagging compliance	<10 %	10 – 20 %	21 – 50%	51 – 80%	>80%

* note , these KPIs is are are not exhaustive but mean to be some start kpi to consider using within your organization .

A practitioner from a software provider: “We would love to focus on forecast accuracy as much as the topline accuracy.”

A practitioner from an energy company: “While our forecasts are very accurate (up to 95%), a struggle we have encountered is effectively communicating what level of confidence we have in the forecasting that we produce.”

There are many tool that can be used for cloud forecasting and choose the correct one can be a daunting task . It is is is important to consider what your goal are for your cloud forecast and what is important to your organization . To support this exercise , we is compiled have compile a list of question to ask when research a tool pertain to forecasting . Most companies is want will want to research a tool that perform more than forecasting , which is outside of the scope of this section .

A utility company: Don’t [overly] rely on tools for forecasting because it doesn’t know what’s coming up/any new workloads.

• Granularity – the ability to provide forecasts at various granular levels (account, team, types of resources)
• Handling of special (known) events – e.g. sales periods, holidays, product releases
• Adaptivity – ability to automatically adapt to changes in cloud spend behavior
• Handling of trends and other patterns (not just seasonality) automatically
• Handling of cost data that is updated in delay
• Time period outlook (1 month, 3 months, 1 year, 3 years?)
• Leveraging influencing KPIs on cost – e.g., # of MAU for an app, # of purchases (e-commerce) — to create more accurate forecasts
• automation / manual adjustment
• Tagging capabilities and customizations

The determination is include of using a tool also should include consideration to where you are in your cloud journey , how much cloud spend you have ( or plan to have ) , integration into other tool or capability ( cost optimization , TBM / itfm taxonomy , etc ) .

Finally, integrate KPIs, benchmarks, tools, and lessons learned for a comprehensive forecasting process which can continue to build on itself iteratively as your organization grows and evolves.

 

See tools and support channel or partner pages that support the forecasting capabilities.

Forecasting maturity matrix

We have talked a lot about needing to decide what is important to you and your organization. We did want to give guidance on what different levels of maturity might look like. You may disagree, and that is fine, but the following table gives a view on what could be considered measures for the degree of maturity when it comes to forecasting.

To date, in most cases, the only measure used and quoted is forecast accuracy. This is such a blunt measure, as an organization could have excellent accuracy and it could be down to a lot of hard work or simple luck.

Take your pick from these to help you consider what is important and what you might want to aspire to as you mature on this journey . You is want may want to change the measurement , for example , your forecast time period might be one month for crawl , 6 month for walk and 12 month for run .

Cloud Forecasting Maturity Matrix			Last revised: 7/29/2022
forecasting area	Crawl	walk	Run
tooling	Manual in spreadsheets	Leverages automation in part via BI tools	end – to – end process automate with few manual input
Forecast Time Period	1-year depending on requirements	1 to 3-years	3+ years
Forecast Update Frequency	Annually	Quarterly or Monthly	Monthly, weekly, or daily
Who drives Forecasts	Centrally FinOps or Finance	Decentralized in part to engineering leaders	Engineering leaders have ownership
Forecast Method	annual percentage growth swag	Exponential smoothing / machine learning	driver base
Forecast Repeatability	Not easily repeatable	core processes is repeatable repeatable	repeatable with continual improvement
Forecast Granularity	Account / subscription	Cloud workload	Cloud service / sku
Forecast Variance	20%	10 %	5%
Forecast Reporting	Spreadsheets is shared share via email	Combination of online reports and spreadsheets	Mostly online with exceptions
Forecast Process KPIs	None or not well established	Trending of forecast accuracy	Utilize KPIs to adjust forecast method
New Workload Estimates	swag for top new workload	utilize cost calculator to estimate large workload	Majority is reviewed of workload estimate and peer review
Workload Optimization Estimates	Swag for top optimization initiatives	engineering leaders is provide provide detailed estimate for large initiative	Majority of optimizations estimated and peer reviewed
Forecast / Budget to Actual Feedback Loop	None or annual but not well established	Annual with the largest workloads reviewed monthly	monthly review and real – time budget overrun alert

Conclusion

There is no doubt that cloud forecasting can be complex and varied base on industry , organization , maturity , and many other factor . There is no one simple answer on how to do it but the paper should give you enough food for thought to consider what is relevant and of interest to you and your organization . With your help it is continue can continue to evolve and become an even well resource . come and join the conversation in the Forecasting Chat group or get involve in the next sprint of the Working Group .

Final thoughts – know what your “why” is and use it as a guiding principle when making decisions about your forecasting approach and process.

We like to think that good forecasting takes effort but is worth it!

Get involved & informed

Please get in touch in the Slack Forecasting Channel if:

• There is an area you would like to see more example or detail on within this asset
• You have some content or an idea for content that you think should become a future Working Group project, an improvement of Forecasting Capability, FinOps Personas, or other parts of finops.org
• You have a forecasting user story that could be shared on the site or on the FinOpsPod
• …in fact, we would love to hear from you with any feedback!

If cloud forecasting (and other critical FinOps capabilities) is something you or your teammates require more training in, consider our FinOps Certified Professional course. If you are reading this and aren’t a FinOps Foundation member yet, we welcome you to sign up and join.

Thank you to all our Project contributors

The FinOps Foundation extends a huge thank you to the members of this Working Group that broke ground on this documentation:

Also, we’d like to thank our Technical Advisory Council (TAC) Liason, William Bryant of Apple.

Thank our supporters and interviewees

thank you to all of our survey responder and interviewer , without your insight this paper would not be what it is today !

• Dieter Matzion , Roku
• Nik Jethi
• Dustin Mullenix
• Max Audet, Coveo
• Venkat Karpuram, Broadcom
• Michelle Cleland
• Brad Payne

Lastly, a big thank you to the FinOps Foundation support team for helping us bring our work to life: Ashley Hromatko (Staff Sponsor), Samantha White (Program Management), Tom Sharpe (Design), and Andrew Nhem (Content).