If so many CFOs are saying rolling forecasts are so important, why do most of us still update our forecasts only to year-end? Based on dozens of interviews, here are the top 3 reasons (listed in no particular order) we just don’t quite seem to do rolling forecasts. Or, if we do, we only reforecast the balance of the year.
#1 It’s a culture thing: It’s hard to focus on next year when everyone is hell-bent on making this year’s numbers. Plus, incentives and bonuses are often tied to the fiscal year, so why should anyone really care about next year? Some believe that to implement a rolling forecast, companies must “abandon the budgeting process completely.” Most people in their right mind know better to advise management to kill the budget; that’s just not going to fly.
#2 It’s a process thing: The annual budget is already a pain, why would we want to relive that pain every month or every quarter? Well, one reason budgeting is so painful is that it involves so many people. Most the budgeting software vendors have financial models aimed at selling as many seats as possible which is great in a collaborative budgeting environment. However, more seats does not mean more value when it comes to rolling forecasts. There’s a myth that if you throw more people at the rolling forecast, it will get done faster. According to Rolling Forecast Solutions, the opposite is true! Given rolling forecasts often need to be at a higher level of detail than the annual budget, we need to ask ourselves: “should the rolling forecast even be in the same file as the annual budget model?” When we look at the process for rolling forecasts, it should not be a “re-budget,” it should be completed within a couple days and by only the select few, the proud, the FP&A teams.
#3 It’s a tool thing: The few of us who have a rolling forecast process in place know that it’s not just a culture & process thing. It’s in large part about the software. Spreadsheets, as flexible as we think they are, just aren’t suited for the purpose, nor are most planning software packages that focus on budgeting with lots of users adding in lots of detailed budget information. Many software vendors agree that rolling forecasts are important; most claim that their solution enables rolling forecasts. However, when we interview the users of these software solutions, we find that less than 10% of companies deploying budgeting software have actually made the move to a rolling forecast. If it’s important to your management team to introduce a rolling forecast, what functionality should you look for in a software package? How will you roll time periods as actuals flow in? How will you spread formulas and run rates into new time periods? Will you be able to compare forecasts at any level of detail side by side?
It’s well known that finance professionals are a required part of most company’s labor pool. Many companies lump finance into G&A or Overhead. The impulse is to minimize these overhead expenses as a percent of revenue, to be a "Lean Company." However, this should not be the goal in most cases.
If we’re in a business where we just need finance to create budgets and reports as required by “the city,” then yes, let’s minimize it as much as possible – after all finance does not add value. Instead of FP&A, this sounds more like CY&A. If all you want to do is cut costs, bring in a guy with a saw and tell him to "hack away!"
But what if finance adds value? Well, in this case, we should maximize this value. Now we can shift the conversation from "what is the cost of finance as a percent of revenue" to "how can finance help drive profits and cash flow even more?"
One finance professional I recently interviewed built a model that enabled him to optimize cash management. This supported a decision to restructure debt instruments and led to over $3M in savings. If finance professionals can make impacts like that, we need more of them. Period.
Whether you're looking to cut costs or add value, this article featured in the latest issue of Strategic Finance Magazine is a must-read.
As finance professionals, we like to quantify the value of new sales & marketing initiatives; we all know those folks spend a lot. So, we set up tools to track their effectiveness and we’re pretty good at it. However, in last month’s webinar, we asked about 100 finance professionals to describe their planning software situation. The results are below:
Survey Results
What best describes your Planning Software Situation?
1. Not yet purchased planning software, use Excel - 40%
2. Purchased planning software, HAPPY w/ ROI - 8%
3. Purchased planning software, NOT HAPPY w/ ROI - 8%
4. Purchased planning software, Unsure about ROI - 44%
|
SOURCE: March 28th Webinar: Measuring the ROI of Planning Software
Although Excel is the software default for planning, it is not considered a “dedicated planning software package.” So, let’s throw out the 40% who reported using spreadsheets for planning. This gives us the pie chart below:
73% report “Unsure of ROI” when asked about planning software
Wow! Nearly 3 out of 4 of the attendees who purchased planning software do not know if they made a good or bad decision. Whether you’re considering a dedicated planning package or have deployed planning software, how would you measure the ROI? Whether you’re “sure” or “unsure” about ROI, we’d love to hear your story.
We've already analyzed the following two key themes at great length:
- Basic Budgeting & Reporting is NOT ENOUGH: Planning should add value; it should not be just another activity we want to complete as quickly as possible. We need dynamic, continuous planning; the annual budget becomes obsolete midway through the Fiscal Year.
- Reduce Level of Detail: We need to move our planning up to a higher level. The default approach to planning relies on natural class accounts intersected across departments. Tons of financial data is added up based on the archaic notion that more data in the planning model somehow positively correlates with a better model.
However, there is a third key theme that often emerges at most FP&A events:
- Accountability: We want planning to be more collaborative. We want everyone involved so they “own their number.” We want them to “buy in” to the plan so that everyone in the organization is accountable if they don’t meet plan.
There is a subtle, but very deep problem, with this notion of accountability as summarized above. First of all, what we’re really talking about here is the inherent (and healthy) tension between tops-down and bottoms-up planning. Management mandates the plan. Line managers then negotiate to get “their numbers” in the plan. As a result, neither management nor the line managers feel like they “own the number.” Even if both management and the line manager “buy into the number,” the one thing we know for certain is that the number will change. However, to have a meaningful conversation, we cannot just talk about the symptoms; we need to understand the root cause. Changes in the underlying drivers are the root cause. Therefore, in most cases, the number cannot be "owned" in the first place.
Newsflash: Rather than owning the number, management and line managers should jointly own the driver-based model.
What if we took a couple hours to sit down with our line managers and co-build their driver–based model with them? I bet most line managers already have a driver-based model set up on some Excel worksheet or set of worksheets. If you listen to them explain their model to you, you can then help them refine the model so that you and the line manager agree that this model is set up at the right level of detail and has all the required inputs and outputs to generate “the number” that management mandated based on whatever logic (or lack thereof) management applied.
This is the big moment. Once you get buy-in on the driver-based model, it will be easy to get buy-in on “the number” – but even better, once the number changes - and we know it will – you can have an informed conversation about why the number changed with the line manager. You can even communicate the insight to the management team, thereby creating actionable knowledge. Here are some examples:
- Were there any main “uncontrollable factors” that made the number change? (e.g. fuel price, shipping rates, etc.)
- What “controllable factors” made the number change? (e.g. staffing utilization rates, percent of new leads called within 1 week, etc.)
- What action can we take to get the number back on track? (e.g. modify incentive plans, hire more people, modify pricing of our product, offer a promotion, delay a product launch, etc.)
Everyone in FP&A is talking about driver-based planning. However, Ventana Research indicates that only 6% of companies actually do it. I think this translates to only 6% of us in finance are actually taking time to listen to our line managers and agree on their driver-based models. If I’m right, here’s a simple, 3-step process to build in accountability:
- Step 1 - Driver-Based Model: Work with each key line manager to co-build a driver-based model that reflects their reality. Gather the actuals for the underlying drivers and back-calculate them where necessary.
- Step 2 - Communicate the Model: Tell the story behind driver models focusing on key measures. Change assumptions on-the-fly to view related impacts and financial results to gain better insight into the model. Once management understands the driver-based model with its key inputs and modeled relationships, then the line manager can “feel heard.” Feeling heard facilitates accountability.
- Step 3 - Agree on Key Drivers: Hold a meeting with management and the line manager to agree on the inputs that will feed the driver-based model and result in “the number." Better yet, distinguish between controllable and uncontrollable variables, then hold line managers accountable only to the controllable key drivers. Otherwise, you may find management wasting time arguing with line managers about “the number” when in fact fuel prices or some other uncontrollable variable explained the variance. In a worst-case scenario, management would reward line managers for fluctuations in uncontrollable variables.
I would like to thank Rob Kugel since I think I’ve inadvertently restated his premise from Integrated Business Planning. Jeff Walker also inspired this new type of accountability in his never-before-disclosed Oracle planning techniques. In addition, I’d like to thank John Sanchez who speaks from personal experience on the value of getting executives into the field.
Related use-case: DownEast Enterprises
At last week's Budgeting and Forecasting presentation in Dallas, I took some time to get personal. I reflected on my life as a financial modeler at planetrx.com. I presented two stories illustrating broken financial modeling processes and poor communication that may have contributed to the company’s ultimate demise. Many of the Dallas attendees related to my failures. I am sharing these stories hoping that you, the reader, might learn something so that you do not repeat my mistakes.
Part 1: My life in Spreadsheets. “You are too detailed.” Base Salary $60k
After learning how to build sophisticated spreadsheet models as a management consultant, I was known as “the spreadsheet guy” from my first day at planetrx.com. My most useful financial model – in my opinion - could answer any question that management could ask regarding how to structure reimbursement programs for prescription medications. We all knew that structuring these deals with the insurers properly would be critical to our success at planetrx.com. My model featured a front-end “user screen” with key inputs and outputs all summarized on a single worksheet, ready to run what-if analyses.
The model generated buzz across the business team. Management asked me to make a presentation to summarize the key insights. This was my big chance to show my stuff! I set up break-even scenarios across three sets of key drivers: 1) mix of generic vs brand volume, 2) co-pay amounts, and 3) discounted percentage off Average Wholesale Price (AWP) and Maximum Allowable Cost (MAC) for generics.
I presented the model to management; everyone was nodding their heads, encouraging me to get through the presentation. Midway through, they started asking questions. I answered the first three questions on-the-fly simply by changing input assumptions which updated the output, gross profit in this case, in real time. I was feeling pretty good.
When the CEO asked what would happen if the “co-pay keep” was $10 instead of $5, I also felt good. The Pharmacy team previously told me that the industry standard for the co-pay keep is $5 and need not be set up as a key driver on the User Screen. However, the CEO was the one asking the question. While I didn’t have the ability to modify the co-pay keep on the “User Screen” interface everyone was viewing, I did have it set up as an assumption buried in a formula on a separate worksheet in my Excel model; I quickly tracked it down and modified the formula. I went back to the User Screen and everything seemed to work fine, I was quite pleased with myself. However, when I looked up, I could tell the room dynamic had taken a negative turn. The CEO interrupted me as I was about to answer the question.
CEO: “I’m sure your model is great, but your presentation is too detail oriented.”
Apparently, once I started scrolling around to various tabs in the Excel model, I was doomed. Management wanted to know they could trust the numbers, but they did not want to see the detail behind it. They immediately concluded that my model had errors. I lost credibility simply because I moved off the “User Screen.” I failed.
Part 2: My life in the Excel-Powerpoint Cycle. “A true waste of time” Base Salary $70k
I worked hard to build these Excel models which I thought were pretty cool. I knew they could inform management about where to set standards for negotiating deals with the insurers so that planetrx.com could be profitable over the long haul. After getting told I was “too detail oriented,” my manager took me aside and informed me that it was now time for me to summarize key findings of the Excel model in a Powerpoint slide deck. It wasn’t really “me” who was “too detailed.” It was just the way I presented my model. I also got “the big promotion” which bumped my salary up to $70k. Someone must have felt like my work was important. I summarized the key scenarios including break-even analysis from the Excel model into Powerpoint slides.
It was a Friday when I presented the deck. Management loved it. When they asked me questions, I got out my red pen and marked up the slide deck to capture their feedback. I was good at multi-tasking. I could write down their questions while listening and also trying to keep moving through my slides. I wasn’t too detail-oriented now!
However, there was a big problem with Powerpoint: I was not able to use an interactive model to answer questions during the meeting. The meeting ended on a positive and we agreed to meet for a follow-up Monday afternoon. Everyone seemed eager for me to get back to them with answers. I was the Powerpoint guy now; I had the $70k salary, so I was not about to pull out the Excel model during the meeting. That’s when I entered the Excel-Powerpoint Cycle.
Part 3: The Excel-Powerpoint Cycle
I ended the week feeling good after my big Powerpoint presentation. I had my set of slides along with a bunch of notes I scribbled down trying to capture management’s questions and concerns. I worked all weekend reading my notes and getting ready for the big Monday presentation only to find that management needed to cancel the meeting because “something came up.” I didn't take this as bad news. I would have more time to QA my slides and make them look pretty. So, I spent most of the week preparing for the meeting that was now set for Friday afternoon. When Friday afternoon rolled around, I waited outside the executive conference room for about an hour. Finally, I was told "You have 10 minutes to present the update.” I took the stage and put my slides up on the overhead to begin the presentation.
2 minutes into the presentation, the CEO interrupted.
CEO: “Who asked for this presentation?”
Me: “You did – this analysis is designed to answer the questions you and the management team asked at our last review. I’m now presenting the results.”
CEO: “Oh. Well, none of this matters anymore as we’ve already made the deal with Express Scripts. It's going to be big news.”
Me: “Okay, so should I wrap up now?”
CEO: “Yes, thanks – I’m sure the model’s great, but we just don’t have time to review it now.”
In conclusion, I spent days building the model in Excel, set up slides in Powerpoint, got feedback, updated the Excel model, revised the slide deck, and finally presented the results only to be told it’s not useful. I had failed again.
At the time I presented the model to management, I did not know we were in the process of finalizing a multi-million dollar deal with Express Scripts that would ultimately be a major contributor to the failure of planetrx.com as a company. As a manager of business development and an exceptional financial modeler, I was not part of the management team per se. However, I was close. I was in the room showing the model that had the potential to communicate the drivers and run scenarios. This model could have informed management about the required conditions for doing the deal with Express Scripts. Management ultimately did not leverage insights from the model. We did a deal with Express Scripts that could never possibly be profitable. That said, at least the management team was reaching for what is now called “Agile Planning.” Agile Planning leads to insights, actionable knowledge, and financially-sound decision making.
I thought Excel could be the tool to enable Agile Planning. I was wrong. First of all, in Excel, an input assumption can only be in one place at a time. For this reason, I could not communicate the model to management effectively. I was forced to go to the static Powerpoint interface in order to tell the story. From an Agile Planning perspective, Powerpoint as a presentation tool represented a big step backwards. It was virtually impossible for me to answer questions fast enough to provide insights that could lead to a financially-sound decision regarding how to structure the Express Scripts deal. To be fair, I should note that there were other factors pushing us to sign a deal with Express Scripts. Our main competitor had just announced a partnership with a major insurer. If we didn't partner with Express Scripts fast, we would not be able to go public. Without an IPO, we would be forced to cut staff significantly. However, we all learned the hard way that inking an albatross deal is not a good move. Regardless of the pressures, when senior management makes a significant business decision that is not supported by a financial model, we all fail. It's not just me.
So, how can we avoid this failure in the future?
- What if we could take the underlying power of the spreadsheet model and combine it with the ability to present the model at the level of detail that management wants?
- What if we could mix the inputs and outputs that are buried in the planning model into a single, interactive User Screen that told the story?
- What if we could answer management questions in real time in such a way that we were not "too detail oriented?"
- What if planetrx.com didn’t do the albatross deal with Express Scripts?
There is now an alternative to the Excel-Powerpoint Cycle. This short video from the Alight Planning vault illustates the future of Agile Planning.
I invite you to share your experience with the Excel-Powerpoint Cycle. What decisions will your management team be making in 2012? What can you do to help ensure management makes the right decision? Please share your story here as a comment or call me on my direct line at 415-456-8528. I would love to hear your story.
This massive, not very helpful sign does not reflect Big Data’s ability to make more sense from historical data sets; it reflects what happens if you try to apply Big Data to planning for the future.
When I turned 40 last month, I started reflecting on my past. To oversimplify, let’s suppose there are two parts of me: 1) Ben, the Business Intelligence guy and 2) Ben, the Agile Planning guy.
As Ben, the Business Intelligence guy, I am looking back and creating reports and charts as requested by virtually everyone in the business team. As Ben, the Agile Planning guy, I am looking ahead and helping management (in theory) make better decisions that drive the business forward.
A little more on my life as the BI Guy:
While I’ve used spreadsheets for planning like everyone in FP&A, I was lucky enough to first experience the joy of financial modeling software back when I was managing the Business Intelligence group at PlanetRx.com (a dotcom failure subject for a future blog). Using what was then known as Cognos Transformer/Powerplay/Impromptu, I created reports and graphs out of massive data cubes as requested by seemingly everyone in the company. We spent lots of money for the Cognos software and consulting services, and I got to go to a couple weeks of off-site training. It was fun. I didn’t know it, but I was living in the world of what is now called “Big Data.”
As the BI guy, I was in a perpetual state of “information overload” with lots of people making lots of requests for custom reports. Clearly, if I could have given everyone an iPad and set them up with self-service reporting tools, that would have eased my pain as BI manager. Enter Agile BI which enables everyone to more quickly access and understand historical data.
Even though I was “the BI guy” and could create beautiful reports based on historical data, I also needed to develop what-if models in spreadsheets to inform strategic decision making. I got to build 1-off spreadsheet models that would analyze decisions like:
- Should we partner with a major retailer?
- How should we set up the pricing model when we partner with prescription pad providers?
- What reimbursement rate parameters are profitable for us when we negotiate with insurers?
A little more on my life as the Agile Planning Guy:
Back at PlanetRx.com, I did not use the word “Agile Planning” since I didn’t even know what that meant; however, that’s precisely what I was doing when setting up planning models in spreadsheets. In these models, we did not have to worry about tons and tons of data; though we did develop tons and tons of spreadsheet files that existed in isolation. We also tried to summarize results in Powerpoint – something we now call the “Excel-Powerpoint cycle.”
Let’s look at the role of data in the context of Agile Planning which focuses on the future and is designed to quickly provide management the insight it needs to take actions that drive the business forward. While Big Data is great for analyzing historical data, it may in fact be the exact opposite of what we need to drive the business forward, to plan. To see this, let’s compare and contrast Big Data with “Small Data.”
Here’s the Wikipedia definition of “Big Data”:
“Big data is a term applied to data sets whose size is beyond the ability of commonly used software tools to capture, manage, and process the data within a tolerable elapsed time. Big data sizes are a constantly moving target currently ranging from a few dozen terabytes to many petabytes* of data in a single data set.”
Given I attend FP&A conferences regularly and the take-home point is always: get out of the weeds and reduce the data in your planning model so you can shift toward materiality rather than precision for precision sake, I was getting a headache from the contrary messaging inherent in Big Data messaging. I also realize the “Big Data” vs “Small Data” debate (if there even is one) could boil down to the CIO leading the charge for Big Data and the CFO being left swimming in a pool of data wondering how to dump it into spreadsheet models in order to support financially-sound strategic decision making.
The examples of the benefits of Big Data are big. Here’s one example from a leading group of pundits: “If US healthcare were to use big data creatively and effectively to drive efficiency and quality, the sector could create more than $300 billion in value every year” It is not my intention to bore you with the many, many other examples of Big Data. Just google the term and you’ll have more reading material than you could possibly digest.
The Big Data – Small Data Analogy
Whether we’re dealing with “Big Data” or “Small Data,” any data analysis at its core is designed to support the business. However, if we break data into two size categories and create an oversimplified analogy, we arrive at the premise of the whole blog:
Big Data : Analyzing Historical Data with Business Intelligence as Small Data : Agile Planning.
Big Data’s message is all about MORE: if we get as many people as possible using as many devices to view the most-current data possible, and could better analyze all the data that we gather at the lowest possible level of detail with the most possible meta-data dimension member tags creating massive data cubes with petabytes of raw data, we can then somehow improve our business.
Small Data is characterized by LESS: Less data at the right level of detail to support decision making with the minimal possible dimension members that are material and emphasizes collaborative thinking and analysis with only the right people (not necessarily more people). Small Data focuses on materiality and meaning; Big Data focuses on precision and details. According to the Planning Maturity Curve, the key to getting to Agile Planning is:
- Reduce The Level of Detail
- Implement Driver-Based Planning
- Integrate (don’t just import) Actuals
- Analyze Scenarios (i.e. perform what-if analysis)
So, Big Data and Agile Planning just don’t fit. When it comes to making planning an activity that informs decision making, step 1 is about cutting out the detail and getting to less data, step 2 is about focusing only on a limited set of key drivers and setting up relationships to eliminate the dependence on massive data sets, step 3 is about figuring out which historical data to incorporate into the financial plan, not simply about moving ALL the data from one system to another system.
We all know there’s a place for Big Data, but in today’s emphasis on best-of-breed solutions, let’s not forget the little guy. Small Data is what enables Agile Planning. Big Data fails.
I’d like to thank Rob Kugel of Ventana Research, Craig Schiff of BPM Partners, Nick Castellina of Aberdeen Group, and Barry Wilderman of Constellation Research who provided “analyst” support to inspire this blog. If you’d like to co-author a white paper with me on this topic, please let me know.
I also want to note that others such as Capgemini are writing about Small Data.
Lastly, I want to acknowledge Sid Ghatak who showed me an analysis that actually concluded it takes longer to update a rolling forecast when more people are involved. This supports the notion that with go-forward planning, less people can lead to better results.
*I must admit, I did not even know what a petabyte is, but it sure sounds like a lot!
Budgeting and forecasting models require structure, lots of it — templates for revenue, expense, headcount and capital planning; consolidation and rollups of the detail to financial statements; user security and process controls; importing data from multiple sources; and more.
In Excel you build these structures from scratch using cell-based formulas and macros. The models take weeks to develop. They’re difficult to maintain, especially when importing actuals and rolling over time periods. They break when line managers insert rows or columns in the spreadsheet templates. And we pray that the FP&A guy or gal who built the model doesn’t quit or get promoted.
Savvy finance teams know that spreadsheets no longer do the job for budgets and forecasting. The big question is: what’s the ROI if you move from spreadsheets to a planning application? Or alternatively if you’ve already made the move, are you getting the ROI you should?
A well designed planning application should address the most egregious spreadsheet inefficiencies including eliminating consolidation and rollup errors, providing user security and process controls, and automating the importing of actuals and reporting against plan. Organizations typically see a 20% to 40% efficiency gain for everyone involved. We call such process improvements Type 1 Benefits.
Let’s talk through a typical Type 1 savings scenario. A mid-market company or division of a Fortune 500 might consume 100 hours of analyst, line manager and C-level executive time for each budget version or forecast cycle. If the planning application reduces the level of effort by 40% (40 hours each cycle), that’s a savings of 480 hours across 12 monthly planning/reporting cycles. Monetizing at $100/hour, the annual savings are $48,000, not a bad payback over time depending on how much it costs you to get a new system up and running. Of course, with finance overheads already cut to the bone, one may question whether the savings actually fall to the bottom line.**
The diagram below, called the Planning Maturity Curve, depicts the savings. The Y axis is the cumulative level of effort devoted to planning and reporting activities. The X axis measures Business Value (to be defined below). As shown in the diagram, adopting a planning application (versus staying in Excel) can substantially reduce man hours devoted to planning and reporting with some marginal improvement in business value.
Certainly a first level measure of value from planning (or any business activity for that matter) should be how it contributes to profitability and cash flow. In stakeholder terms, value can also be measured by how an improved process contributes to customer and employee satisfaction, or shareholder value. While such high level measures are important, they miss the mark for finance organizations. Deep down, Finance wants what we call Type 2 Benefits which are described by the terms Insight, Actionable Knowledge and Decision Making.
** At a recent conference sponsored by CFO Magazine, David Axson, a well-known author and speaker on performance management, observed that prior to the current economic crisis, finance functions in large companies accounted for 2% of revenues. He points out that the number today is closer to 1%.
.jpg)
Recently Proformative featured an article with a software solution that claimed to be "asprin for the financial consolidation headache." Let’s have some fun and take the analogy further. For many of us in finance, the annual budget cycle is, in fact, a major headache. So, what if we could go out and buy software that would make that headache go away? If software could make budgeting painless, most of us would have replaced our spreadsheets by now. In fact, most everyone who wants to streamline the annual budgeting process has already replaced spreadsheets with a dedicated budgeting software package. Many in finance have not replaced spreadsheets for budgeting because the pain’s not bad enough to justify the expense of new software. Last time I checked, software cost a lot more than aspirin.*
Let's shift from headaches to mental health. In the old days of psychology, treating depression was all about moving from a negative state to neutral. Way back when Martin Seligman introduced positive psychology, the vision was to achieve "authentic happiness." Life is too short to be content with neutral.
Finance is now looking to replace legacy budgeting-only software solutions (e.g. Pillar, Forecaster, Budget Maestro, Adaptive Planning) with a solution that does more than merely reduce the pain. In other words, they don’t just want to move down, they want to cross the Planning Maturity Curve and introduce value-add planning practices such as rolling forecasts. Finance is now demanding what Seligman might call “Positive Planning.” In today's economy, reducing planning effort is not enough. Eliminating negatives will not move the needle past neutral. Management is mandating that finance adds positives by implementing new planning processes to drive the business forward.
It is no wonder that finance is frustrated because, at best, budgeting software gets them to neutral. It does not enable them to drive their business forward in a positive direction. Ironically, Hyperion Planning replaced Pillar, but Hyperion Planning users are reporting that they do budgeting and consolidations, not "planning." Given the focus on positive planning, it’s not surprising that Centage recently introduced “Planning Maestro” since their flagship product, “Budget Maestro” was only effective for budgeting, not planning.
Let's Put This into Context
The finance community was pretty excited back in the 1980s when spreadsheets moved budgeting onto a computer. As anyone in finance knows by now, spreadsheets were not intended for financial modeling and budgeting per se, so when Pillar came along it was a HUGE SUCCESS. In the Hyperion Pillar heyday, I heard that people actually waited outside in the rain to get into a building in Manhattan just to see the Pillar application demonstrated live. Going to see Pillar was like going to see Springsteen in concert! Although Pillar was the first Enterprise Planning Application and probably the most successful budgeting solution of all time, there are now dozens of vendors competing in the budgeting and planning software space.
Back when Rand Heer created the original Pillar application that started it all, he was inventing aspirin to reduce the headache of budgeting. Now, like Seligman before him, Rand is revealing a path to move planning beyond neutral. In his Planning Maturity Curve, Rand creates a visual representation to illustrate the effects of reducing pain across 5 planning activities and something entirely new, which is becoming the most important planning development for finance in the 21st century. This something new is called Agile PlanningTM.
*You often have to get approval from the management team in order to make the purchase. And, one surefire way to get a headache in this economy is to go to your boss asking for new software spend that only helps you do your existing job more efficiently.
Special Thanks to Martin Seligman for Creating the Positive Psychology movement and Rand Heer for creating the Agile Planning movement.
Several years ago the IE Group established itself as a forum for thought leaders in FP&A. Now, the thirtysomething all-star team at GMI-Solutions has a series of world-class FP&A events in 2012.
At last week's San Francisco event, quality presentations and positive feedback from a savvy FP&A group during cocktail hour impressed me. I am pleased to share the key conclusion from this recent event regarding how best to improve and transform FP&A.
Key Conclusion
Management should analyze the impact of potential benefits generated by introducing new planning processes in addition to analyzing the benefits of streamlining existing processes.
Midway through my presentation, “Financial Planning Innovations: Is it worth it to replace spreadsheets with a planning tool?”, I asked the 50 attendees whether their management is prioritizing “streamlining existing processes to save time” (Type 1) or “introducing new processes that add business value” (Type 2). Earlier in the conference I spoke with one FP&A professional who reported "we’re working on the hard benefits which can be measured by time saved; we’re also interested in soft benefits that cannot be measured such as improving decision making." I’d heard the distinction of “soft” and “hard” benefits, but I also worked on some business cases where you could also have hard benefits be things that increased revenue not just reduced expenses or avoided costs. This inspired me to conduct an informal survey of the audience about what type of benefits are most important to management.
Survey Results... WOW!
Every single attendee reported management prioritizes Type 2 Benefits over Type 1. The Planning Maturity Curve provides a simple visual to distinguish between Type 1 and 2 Benefits:
Plotting Type 1 & 2 Benefits on The Planning Maturity Curve
Let’s look at a couple prioritization examples to sharpen this Type 1 and Type 2 distinction:
Example - Type 1 over Type 2: "While it is important to us to someday integrate the balance sheet and cash flow into our forecasting model, right now, our priority is to reduce the time spent verifying formulas every month when we update the forecast."
In this case, management is expressing Type 1 (streamline existing processes) as more critical than Type 2 (introduce new processes that add business value).
Example - Type 2 over Type 1: "We do not yet have a rolling forecast in place; however, management mandates that it is more important to introduce the rolling forecast than to streamline the existing annual budgeting process."
In this case, management is expressing Type 2 (introduce new processes that add business value) as more critical than Type 1 (streamline existing processes).
Finally, I'd like to share an abbreviated ROI analysis I recently conducted:
Type 1 Benefits: (Streamline existing processes – At most $10,000/Year)
- Streamline man hours put into current budgeting process by 50%. The current process requires 200 hours of support. Based on $100/Hr as a fully-loaded hourly rate, we estimate a hard benefit of $10,000 savings per year.
Type 2 Benefits: (Add new processes to improve decision making – At least $36,000/Year)
- Scenario planning to better manage risk (e.g. better manage purchase decisions to optimize inventory resulting in an estimated recurring hard benefit of $3,000 per month due to 1) reducing holding costs of excess inventory and 2) enhancing cash flow by delivering product on a more timely basis)
- Continuous planning throughout the year would enable better management decisions based on sound data and trends ($ value not estimated)
Type 2 benefits seem difficult to quantify and therefore are often classified as “soft benefits.” However, in the example above, we actually found it quite easy to estimate the minimal dollar value of optimizing inventory. For example, when we interviewed the management team, they believed that the new agile planning approach would optimize inventory by 3-5%. Since inventory holding costs averaged over $100,000/month, it was easy to deduce a minimum impact of $3,000/month.
Back at the FP&A event, where we analyzed case studies such as how Kaiser deployed software to support a type 2 benefit which increased the NPV of a capital planning project by over $100M and how AMEX has benefited by introducing the rolling forecast, it became obvious that type 2 benefits are now the most significant. When the spreadsheet first hit the FP&A community, we embraced the idea of streamlining planning processes with various software packages. Today, it is unanimous: the incremental value of further streamlining planning processes pales in comparison to that of transforming finance and making it a value-add activity.
Special thanks to Sid Ghatak, Rob Kugel, Rand Heer, Blake Humble, Bob Paladino, Chris Vacano, and Colleen Morriseey-Levins for inspiring this Blog Entry.
This month's guest blogger is Anthony Caires. Based on recent experiences selling both public and private cloud performance management solutions, Anthony reacts to my last blog. Best of all, he provides the 2x2 planning in the cloud matrix below to help you analyze how best to move your financial planning models to the cloud.
While I agreed with most every point in Ben's last blog distinguishing how financial models work in the cloud, the issues are not so black and white. Given this is a blog, please allow me to oversimplify by using "public cloud" to mean "browser-based" and "private cloud" to mean "not browser-based." From what I see, finance pros are divided into two camps: those that love the public cloud model and those that hate it. Having sold both private and public cloud performance management solutions, I felt obligated to explore why some finance teams have had such great success in the public cloud and others have had the opposite experience.
To this end, I interviewed dozens of customers and asked them to reflect on their experiences, both positive and negative. The results of my analysis are summarized in a 2x2 matrix (see image on the right). We analyze the primary objective for replacing spreadsheets with a dedicated planning application across technology platforms. When the primary objective is focused on streamlining the annual budget, the technology platform is not a critical factor.
The public cloud often works well for the annual budget; users tend to enter budget data into the system once a year and are happy with a web form. There is little requirement for these users (mostly department managers) to create driver-based models or analyze the impact of changing input assumptions on their area of the business. In many cases, finance teams and department managers love the public cloud for the annual budget. Everyone is happy with web-based tools and the majority of companies are not concerned with security issues*.
However, when the primary objective is Agile Planning, the technology platform becomes a critical factor in predicting success. Unlike the annual budget process which is characterized by lots of managers keying in budget data, Agile Planning focuses on driver-based modeling, integration of actuals, and scenario analysis. Finance personnel attempting Agile Planning in a public cloud environment consistently report failure due to clunky web-based forms and poor performance.
Unfortunately, it's not just Ben who is hearing horror stories about the public cloud's inability to address Agile Planning. I have heard from dozens of finance executives who failed with public cloud solutions and are now back on spreadsheets or exploring a solution that is not browser-based. In each case, the customer reported latency when attempting what-if analysis over the web. Even worse, when entering just a few changes, they reported problems with circular references and odd behaviors; they were never quite sure if the data was “recalculated.” Furthermore, many of the finance users reported a “dependence on the vendor” to make even basic changes such as adding a new business segment to the model.
Conclusion
With the growing emphasis on forecast accuracy and better fact-based decisions that impact the bottom line, the early-stage public cloud solutions are not yet viable.
This cloud computing analysis boils down to whether or not you want a browser-based interface: some will love it, others will hate it. I recently viewed the latest Muppet Movie, and to fit in with the cloud analogy, let me end by riffing on THE RAINBOW CONNECTION made famous by Kermit the Frog:
"Someday we'll find it, the Public-Cloud Connection, The Lovers, The Haters, and Me."
THE LOVERS: Having a web-based report where anyone can login to view the data is a clear winner. Many finance professionals are leveraging the public cloud to streamline budgets. Their users are content keying in simple budget data and viewing reports in their web browsers.
THE HATERS: While web forms inherent in the public cloud are fine for simple calculations and data entry, they fail for forecasting and serious financial modeling. Moreover, most high-powered finance professionals would never move their Excel models to Google Spreadsheets, the comparable public cloud alternative. Finance professionals find it easier to get stuff done and build models they can trust when they are not distracted by funky web form behaviors.
AND ME: Whether you do budgeting in the private or public cloud really makes no difference in most cases. However, when users require more interaction with the planning system, the private cloud is the better choice. If there is anyone out there having a positive experience with Agile Planning in the public cloud, I would welcome learning how you accomplished that.
*I have heard of security issues coming into play with the public cloud model in cases where a company is headquartered outside the United States. Apparently, there is paranoia that the US government can get access at any time to any data hosted on servers in the United States. But these companies can either leverage their private cloud infrastructure or find a public cloud software vendor that offers hosting outside the United States.