What Public Companies Typically Get Wrong About FP&A
Recently McKinsey’s “Inside the Strategy Room” Podcast discussed “Seven CEO Insights from Private Equity”. I am writing a series of brief articles highlighting key insights from this podcast linked to my own experience that relate to #TBM, #Innovation, #TechnologyFinance and #CostManagement. My discussion is focused on large enterprise technology functions and the presence or absence of these types of private equity best practices.
Typical Issues in Financial Planning and Analysis (FP&A) Per The Podcast
Private equity financial professionals are surprised by a lack of rigor in FP&A forecasting as follows:
1. Macro assumptions like inflation are overly simplified and often from a third party or are generic, rather than being tailored specific to the company’s exact situation (for example, 3% / year). The assumptions are often also inconsistent between departments or functions. There may be a “single number” instead of being matched to specific revenue and expense line items. For example, some commodity items may be decreasing in price(like standard PC’s) while other services like SAAS subscriptions may be increasing at a double digit rate. In my experience, increases are not well modeled or consistent and then they are often dwarfed by the “plug” that is inserted by Enterprise Technology finance departments in order to meet target (an offset to expense). For instance - I may budget for a software solution like SAP to go up 3% / year and pay for 10% more licenses, but then all these increases are offset with a 5% cut to the total software budget that finance puts in our total division plan
2. The forecasts are not parameterized - they don’t have probabilities. There should be multiple forecasts with different parameters and assumptions (tied to business growth, competition and changes to expense mix). Many companies don’t model a “downside” case with any rigor. In my experience there was a “single” forecast and perhaps a “downside” case that had little detail. Note that using a tool such as Apptio for IT Planning (forecasting) makes developing multiple forecasts much easier to do, and you can also easily see the differences between each model by comparing the plans against one another in the standard reporting module. In 25+ years of financial planning and modeling I’ve never seen multiple forecasts for expenses with any degree of discipline so I can safely say that this best practice is not employed
3. The entire model isn’t backtested weekly or monthly; you aren’t testing to see how close not only your final result is (your “net” P&L forecast) but how close each of the line items are that comprise your forecast. Teams do attempt to improve their forecast accuracy and often take “actions” to get back in line with the forecast. For instance, if we are tracking above forecast, they will delay hiring consultants or freeze travel and incremental expenses. This isn’t really in the “spirit” of what private equity is doing, because they logically wouldn’t have budgeted for unneeded costs in the first place. But I think enterprise technology finance departments do bend over backwards to attempt to meet their financial targets and take aggressive action where needed, whether or not these actions are ultimately beneficial to the enterprise (for instance cutting consultants delays key programs which may have a revenue upside)
4. Dashboards are not “cascaded” - meaning from the top (ties out to the annual budget or the latest forecast) and then each of the layers down below are tied to the same model and don’t veer off or lose granularity. In private equity, the same dashboards that are used to control the business are the same ones that they present (regularly) to their board. In my experience EVERY single report that goes to the board is a “bespoke” report where the numbers are curated and often substantially different than what is reported in the official system (unless you are tying out to total expenses or revenues). See below for many of the reasons why the official financials are not usually relevant to each sub-function and are not viewed as “accurate”.
5. Within dashboards, they have a “causal flow”. It starts with
In my experience the dashboards are made up of narrative elements that support the strategy of the top executives that are doing the presentation. There is not a hierarchy or consistent model from the top down.
Why These Concepts are Typically Not Present in Enterprise Technology Financial Reports
1. In my experience, reports to top executives are always “bespoke” and not generated from systematic dashboards nor from the actual reporting systems (such as SAP or Anaplan). They also do not link directly to the original budget at any level of detail (they might agree on the final total for revenue, expense, or capital expenditures).
2. Most reporting in companies is “split” into cost reporting (budget vs. actual expenditures or capital spending vs. plan) which is done by “function” (such as Global Technology, Operations, Finance, HR) or a revenue view by line item / product / service (the “top line” which may be tied to specific revenue offsetting lines). The plan is disassembled and then each group kind of takes their plans off and goals and builds independent models and views.
3. The (wasted) one-off effort that goes into these bespoke views is very large, detail is lost, and drill-down capabilities built into tools such as Apptio or Anaplan are ignored. A separate “narrative” is built on a few power point slides and detailed talking points are reviewed up and down the chain of command. Each month, this entire process of desiccating your purpose built tools and simplifying down the content so that it can be consumed in short sound bites occurs and becomes the most important part of the process, instead of being embedded in the data and consumed as part of the final product.
4. The most successful FP&A efforts I’ve been involved with incorporated the “narrative” right into the plan itself with fields that described “why” projects were being funded and had detail of the specific spend by SAAS vendor or third party consultant. As projects were deferred or accelerated, this narrative was also captured in the tool and consumed directly by executives. These efforts are usually very rare and only make up a small part of the total plan, and are then impacted by all the negative items listed on this page (re-organizations, staff turnover, “plugs” in the budget, and budget not equalling forecast and not being re-planned in detail)
5. Budget Detail is Usually “Broken” by Top Line Adjustments and “Plugs” Often the budget is done with a lot of detail including specific vendor detail and labor costs by person with funding for specific open positions by position number. The teams spend months preparing all of this detail, along with justifications for each line item. This is called a “bottoms up” plan. In parallel, the company develops an overall financial model and cascades down “targets” for each group. This is called a “top down” plan. For example, a technology function may have a “target” of $500M, when the “bottoms up” model comes to $550M. The “right” way to solve this problem is to have a discussion about what projects to kill or changes to make to remove the $50M or 10% gap per above. However, this is long and time-consuming and involves trade offs between all the functions in technology (for example between required security hardening efforts and growth in the core business such as new store openings). These cuts also “imply” cost reduction strategies which may be complicated or take years to execute (for example outsource or re-bid a major support contract) and which would in turn likely displace or deprioritize other projects to do correctly. The way I’ve typically seen this done is to put a “plug” in the budget to account for this 10% reduction. The plug is usually a credit (a negative amount) in an account that would otherwise never go negative. Sometimes the “plug” is put in one department (for the whole division) or it can be further “pushed down” usually based on the size of the spend in each area (the bigger your spend, the larger the percent of the total cut that you receive). In summary, the plug invalidates most of the effort you put into a bottom up budget, because you don’t know how those cuts impact the individual projects that you’ve carefully planned out.
6. Budget Usually Doesn’t Equal Forecast. There usually is only one budget (not multiple scenarios) and then the forecast is created in parallel, usually only at the “top down” level. Then the forecast is adjusted for 1) what happens in the actual spend for the months-to-date 2) changes in required spend for the rest of the year. For example, in the description above, we created a “bottom up” budget of $550M and then put a plug (credits, not specific project cancelations) of ($50M) to get to a new budget of $500M. Then due to running under budget (projects were delayed) in the first half of the year and increasing competition, the company might say that the new forecast has been reduced by $100M for the company as a whole. The “right way” to do this is to re plan the rest of the year in the budget, push it to forecasting, and develop a bottoms up plan that takes all this into account. However, the way it is really done is to push out this gap into the major functions on the top line which only further compounds the challenges of leaving the $50M “plug” in for the original budget.
7. Each Year The Budget Starts Over. Given that there is a huge difference from the bottom up budget and the top down plan, especially during the year as the forecast starts to diverge from the budget and the impact of actual spend plays out, teams usually just start the next years’ budget over “from scratch”. The process starts over, with some teams “dusting off” the detail to create the bottom up budget and others just recreating it (often with new team members who have to re-learn what is going on in their area from square one). The lack of re-use and consistency in this process causes re-work and makes it much harder to to “learn” and “improve” each year.
Conclusion
I think that the HBR podcast was very good and I agree with the 5 points that they make in their discussion of FP&A. Any company would be better served if they put these suggestions into practice. However, for the reasons I list in my second section, it is a daunting task. Note that this is only the first section of the podcast; I intend to write additional articles on each element in the future.