3 Common Building Errors FP&A Professionals Make in Financial and Business Modeling (And What To Do About It)
There are a lot of avoidable problems in the finance field and I’d like to address just a few within the context of financial and business modeling. Maybe you can relate and my bringing attention to them will alleviate or eliminate some of your frustrations. I approach this topic with optimism because I think with small, easy-to-implement changes in conscious thinking - and a level of awareness - planners can change the way they go about their building, ultimately changing the inefficiency of the work they do.
If you’ve attended any of my programs, you know I make an ongoing point about crafting a plan and being intentional. When professionals set out to build financial models or forecasts, they’re often simply jumping in without much thought about where they’re going. They don’t take the time to create a clear vision of where they want to go or identify the ultimate objective of the model.
It’s like having a stack of blocks and just starting to build a tower without knowing what’s being made….will it be a skyscraper, a castle, or something else? The thought process might be, “I’ve built plenty of these, I know how to get started and I’ll figure out the rest later.” For my imaginative 4-year-old boys, that’s great, but for the rest of us that doesn’t work. Planners are often guilty of habitual building that results in doing things the tiresome way they’ve always been done. Instead, there needs to be a more thoughtful plan.
My 2-cents? This is the wrong way to build and we can do better. There is a more productive way and we owe it to our organizations to build with intention and flexibility.
Error 1: Believing that the business model itself is the goal.
Several years ago, I was working with a major supplier of printer ink cartridges in Kansas City. When I outlined the objective of our mandate, a sharp young woman on the finance team eagerly blurted out “I’ll build the model!” While I celebrated her enthusiasm, I always caution companies and their professionals not to get too excited about model-building before we know what we’re doing. The model is not the goal -- the goal is greater data visibility, confidence and risk-management in achieving our business objectives.
Solution: Recognizing that the model is not the goal, but rather a tool, is the first step. Ultimately, the goal is to create a tool that will grow and evolve over time, with the objective always being to facilitate future conversations and allow for better decision-making. Better decision-making takes place when there’s greater data visibility, confidence and risk-management. Think “big picture” and imagine a healthier company, with more supportive financial management, and a tool that can help manage that reality. We are building a tool that will flow within that environment.
I’ll often hear someone say, “Carl, if only I’d known then -- when I built this model -- what I know now, I would have done things totally different.” That’s the problem! We can’t predict the future, so we need to build with the mindset that we’ll evolve and grow. We won’t know everything at the outset of a mandate, so building a tool that is flexible for a multitude of future permutations, is a wise move.
Error 2: Keeping control of the tool within the financial professional’s wheelhouse.
It’s common to assume all financial planning & analysis (FP&A) processes should fall within the finance function. But this isn’t always the case. A few years ago, I was working with one of the largest telecom companies in Canada on their business planning and forecasting. Interestingly enough, in this planning group of around 30 people, only about 10% of them were part of the FP&A team; the other 90% of the people were in non-financial planning groups including operations. Because non-financial operators are often the closest to the activities behind the numbers, it makes the most sense to include them.
Solution: I feel that allowing the financial team to take the lead on everything planning related is a big mistake. Build with the idea that other departments and divisions (HR, marketing, sales, etc) have skin in the game. It’s better to build a tool that THEY buy into, can utilize, appreciate, and grow with. They should be the teams contributing data and assumptions to the model with FP&A’s assistance, not necessarily the other way around.
Going the traditional route of having the financial team control everything going into the business model leads to a lot of inefficiencies -- inefficiencies that can be avoided, thus saving loads of time and rework. Imagine this...rather than finance diving into each group’s forecasts and doing the planning for them, what if finance was responsible for working alongside each department leader and executive team, teaching them a financial mindset that can better serve the organization in the long run? Too often department heads defer to finance when they’d be better served learning the small handful of financial implications they have control over.
Who can blame these leaders who dread the budgeting and planning process because it’s been poorly-designed, micro-managed and fails to keep everyone accountable? If it’s merely an annual exercise that doesn’t meet the needs of the team, I’d check out of the process too. I like to think of the financial planners as the facilitators, or financial stewards, but they’re not necessarily the captains. Leadership of each functional division is exactly that....leadership, whose responsibility is to use the tools at their disposal intelligently. Flip the planning process from what most companies have been doing -- finance-driven to operating partner-driven -- and we’ll have a successful undertaking that both sides are committed to, are eager to report on, and -- ultimately -- yields better results.
Error 3: Skimping and shortcutting best practices
“But Carl, we just don’t have the time,” is the common rebuttal I get from FP&A practitioners who take shortcuts. But after I go through the framework of standards we should be using across the whole function, I challenge their thinking by asking, “Is there any standard I’ve outlined that would take you any longer to implement? Is there anything you’re giving up by doing your work more thoughtfully?”
The answer is usually -- no -- and acknowledging that it doesn’t take more time to work smarter; it just takes more thoughtfulness. It also takes an understanding that investing just a little bit more effort on the front-end will save an immense amount of time and frustration on the back end. It’s not a this-or-that consideration. You can have both more time and better modeling practices and fundamentals.
Solution: In relation to the last solution, one of the most important best practices I can drive home is to think about the tool outside of yourself. While you might be the builder, the builder is quite often not the ongoing user. Over a decade ago, when I was a young consultant, I’d built an extremely sophisticated and complex financial model driven by a company’s sales forecast. This company was doing over $300 in revenue annually and this model was used to drive much of the planning function. Because I’d built the model from my own point of view, I had to write an instruction manual to guide the Director of FP&A through the process of using it. Not only that, I had to spend days teaming him side by side. While he eventually got the hang of it, he was always worried about adding or deleting elements out of fear that it would break the model.
I share this example because it’s something many of you can likely relate to. We like our own work but sometimes we fret about inheriting someone else’s. If a model is going to be an effective tool, it’s not just a tool built for a single person; it is a tool built for the people who need to use it and derive benefit in an array of applications. Keep this in mind when building a simple, logical tool that -- while capable of complexities -- can be used by multiple parties for collaboration. There is no benefit to anyone else if they can’t navigate the tool that you created.
Creating a useful and agile financial model is a lot like sitting down to create a business plan. You stretch your mind to build a tangible vision, mission, and goal for the future. You know that all sorts of trouble will be thrown your way at different points down the road. Will it be perfect? No. Will it be for everyone? Probably not. Instead, you will build a service or a product that serves an audience you have taken the time to really understand. And, will they change? Sure. Will the market? Absolutely. And so, your vision and tools need to be malleable, allowing for new users, changing figures, and expanding possibilities.
What are the Best Standards and Modeling Approaches?
I’ve met many people who subscribe to a set doctrine of standards, but I tend to believe the standards you choose should be arrived at by your best interest, not their universal applicability. Just because certain standards work for one company doesn’t mean they’ll work for yours. And just because a handful of modeling gurus believe in one approach, doesn’t mean it’s the way all companies should follow suit:
Below are the fundamental principles I discuss in my FP&A Mastery and Modeling Best Practices Programs that I believe most companies should follow. Which of the following do you think are the most important? Which would you challenge?
Start with the end in mind and work backwards
Consider the end-user, the end-use, and the business decision or mandate
Use font colors intentionally (black for formulas, blue for inputs or hard-coded numbers, and green for external links)
Label and document assumptions and data sources thoroughly and consistently
Define names and variables for key inputs, assumptions, and drivers
Use good modeling hygiene including consistent references, row heights, and column widths
Avoid hard-coding numbers into formulas
Minimize the use of overly-complicated links
Avoid hiding active formulas being used in calculations
Avoid using excessive colors, comments, and links
Minimize overly-complicated links and formulas
Link to outside workbooks and data sources deliberately and only when absolutely necessary
Use standard naming data linking and extraction approaches
Rename data files and folders consistently and only when necessary
Conduct sanity checks regularly
Run sensitivities to ensure business models make economic sense and reflect the tangible realities of the business
Test work and have others test the assumptions
Review the end results with end-users prior to completion and roll-out
Simplify outputs and summaries whenever possible using data visualizations such as graphs, charts, graphics, and tables