A brief introduction to building bad budgets
[Cost of Delay series — Part I]
“No enemy is worse than bad advice.”
(Sophocles)
Over the years, I’ve been involved in many budgeting projects and budget management cycles. I’ve been on the receiving end, working with financial controllers to set and manage the budget for my own organization. And I’ve been on the Finance side of the table too, working with the business to determine their allocation of financial resources for the upcoming fiscal year and then govern their budgets throughout that year. All of this rich experience, built up over a broad range of cases, has recently led me to a sobering insight: I’ve been doing it wrong 100% of the time.
Don’t feel too bad for me. It’s not like I and everyone I worked with on this have destroyed companies or lives. For the most part, everything worked out reasonably OK. And the problems I’m about to describe are pretty universal and can be observed in most budget processes at the majority of companies. But until now I had never really questioned the shortcomings of the process, even though they aren’t very difficult to see. I certainly never put much thought in trying to come with a structurally better approach, like most people just accepting a shitty budgeting process as one of those inevitable rituals in corporate life. Until the last six months or so, when I started wondering what a fundamentally better approach would look like. This series of articles is the result.
The context I’ll discuss involves planning and managing budgets for teams of knowledge workers, where the majority of costs are salaries and ‘production’ is largely intangible. In other words we’re deliberately not thinking of traditional textbook physical manufacturing, with its substantial raw materials, capital equipment or energy costs. The audience I write for are the responsible leaders and managers in charge of such teams and — especially — their financial controllers and other finance staff. These professionals have typically been trained with examples involving physical manufacturing, leaving them with big misconceptions, as we’ll see. I’ll start the series analyzing the various shortcomings in the way budgets are currently run. From there, we’ll systematically build up an alternative methodology which does not suffer from these shortcomings. Almost none of the concepts we’ll encounter are new or original, and I’ll refer to the authors from whom I’ve picked them up, and point to resources to learn more. But even though the concepts are not new, I’ve never seen them structurally brought together under a “build better budgets” heading. Furthermore the literature on how to practically implement these ideas in daily corporate life is rather sparse. What you do find usually describes physical manufacturing, and isn’t obvious to apply to the context I am more interested in: knowledge work. In this series, I want to address both: connect the ideas together in a coherent framework, and come up with practical tools and approaches to implement them in the real world. That is a work in progress and I hope to get lots of feedback and suggestions to improve the methods from other practitioners. But to get going, let’s take a hard look at the trouble with traditional ways of budgeting…
Imagine a reasonably sized organization of knowledge workers, say 100–150 people in total. (I’ll often use software engineering as an example, but feel free to mentally substitute any other type of creative knowledge work.) A typical budget setting cycle works roughly as follows. Once per year, the team leader and financial controller get together to start discussing next year’s budget. The majority of the cost consists of staff salaries, so planning the right level of staffing is usually the biggest part of the exercise. As a result, this year’s staffing — and budget — is often the baseline reference and starting point of discussion. The team leader will have a long list with estimates of all the new features and products to be delivered (which is usually more than the previous year), have ideas for new initiatives or improvement projects, and look for money to spend on promotions and salary increases. The controller will challenge the team leader’s assumptions and stress the need for “efficiency” and “productivity improvements” and “doing more with less”. The debate heats up further when the corporate finance team gets involved, aggregating budget submissions from all departments and more often than not concluding there are more requests and ideas than money to fund them. Company leadership may then decide to apply a “top down stretch target” or “haircut”, or something to that effect. When all is said and done, after a bit more haggling the new budget number is announced and as of that moment, it’s as if it’s carved in stone for the next twelve months.
Does that sound familiar? Although the team leader and controller usually have a lot of data, the entire process isn’t very scientific and it’s problematic in several ways. Problem one, right from the start, is inherent to the kind of discussion controller and team leader initiate. This way of budgeting is approached as a cost exercise. But team staffing and the associated salaries are just an input to a value creation process. Controller and team leader should base their discussion on the output of that process, and the value they expect to create. The reality is that, even if they would want to with all their heart, they usually don’t know how. This is related to an old (and difficult) question in software engineering: how do you define, measure and manage the performance of a team? And it is no different for other types of knowledge work, with highly skilled professionals producing valuable product in a variable and complex work process that doesn’t at all resemble the predictable and repeatable processes of physical manufacturing. The controller and team leader don’t have a framework to build a plan and create a budget in relation to the expected value creation during the planning period. Even though they both understand the Return On Investment concept, they don’t have a good toolbox to reason about the R. As a result, they end up talking mostly about the I.
Speaking of physical manufacturing: finance professionals’ training usually involves mental models and assumptions derived from these environments. Due to their training, many finance people enter the workplace thinking in terms of standardization, economies of scale, maximizing the capacity utilization of assets, and increasing efficiency by eliminating waste. At best, the controller will recognize human beings are a little different than other assets and require a certain amount of slack. But even then, they’ll see less-than-full-capacity-utilization as a matter of creating some buffer for training, the inevitability of illnesses and other absences, etc. Ask any finance person what a reasonable level of capacity utilization is, and they’ll probably say something like 90–95%. That is deeply flawed and physical manufacturing is a terrible mental model for knowledge work. All other things being equal, lower cost is better than higher cost, of course. So it’s not entirely wrong in itself for controllers to worry about cost and look for ways to drive it down. But if they do, they are misled by the manufacturing analogy and solving for the wrong parameters. We’ll revisit this in much more detail in a later article. And by the way: financial controllers can be entirely forgiven, because the majority of team leaders they supportd don’t fully understand optimal capacity utilization either!
A third problem with traditional budgeting is it’s a once-per-year exercise, and the resulting financial parameters are then considered sacred and untouchable for the entire fiscal year. ‘Controlling budget’ means identifying and analyzing deviations from the plan, and ‘managing budget’ means eliminating, correcting or compensating for these deviations. Staying below budget is good, going over budget is bad. Again, this puts all the focus on an input to the value creation process, not the outcome. The outcomes are reviewed as well, of course, typically in some form of operational review tracking KPIs and OKRs and so forth. But even then, staying within budget is a silent constraint applied to any corrective action or managerial intervention. Making budget is sometimes one of the performance metrics determining variable compensation. Small wonder then that more than a few team leaders take professional pride in their managerial ability to meet budget. It is not hard to see why this is flawed thinking. If the internal or external context changes compared to conditions when budget was set, as they inevitably do in the real world, why is everyone still expected to somehow stick to the number? Granted, it is a simple policy and it creates a perception of fairness between different departments. But it can’t be optimal. If the value opportunity increases throughout the year, why wouldn’t you invest more to capture it? Conversely if opportunity or scope are smaller than anticipated, why would teams have free reign to keep spending regardless? And don’t get me started on the sheer madness of last minute year-end spending with suppliers or prepaying costs, just to preserve entitlement to the same or a higher amount of budget next year…
The traditional budget processes also create conflicting interests between the financial controller and team leader, putting them on opposite sides of a negotiation table. This is game theory on full practical display. The team leader knows the controller will scrutinize and challenge assumptions, and anticipates this by padding the estimates and budget proposals. The controller knows team leaders ask more than they need to get what they want, challenges the proposal, and removes budget even in the absence of concrete evidence. Sometimes there’s more gameplay at other parts of the company, e.g. when controller and team leader together need to defend their budget to senior leadership or a corporate team. Even the commonly used term itself — defend— implies an adversarial dynamic between people who are supposed to be working towards a common goal. The CFO is typically not above some tradecraft either, deliberately squeezing every team a little bit “and then we’ll see who screams the loudest”. But some team leaders are much better than others at selling a convincing story and getting their way in budget negotiations. Likewise as the year progresses and the budget gets increasingly outdated, some are very good at getting exceptions approved while their less savvy colleagues continue to toil and suffer in silence on more deserving causes. For any CFO, that should be an unsatisfactory state of affairs. The allocation of scarce resources should be as objective and data-driven as possible, not a charm contest of who haggles and hustles the best.
Summarizing this overview of shortcomings, this is what we’d like to get from a better methodology to build and manage budgets for teams of knowledge workers.
> The methodology has to be driven by financial considerations related to business value — an output — instead of staff salary costs — an input.
> It must give finance professionals and team leaders a better mental model than physical manufacturing, to inform decisions on the appropriate target level of capacity utilization, and how many people to staff.
> It needs to give us metrics to determine if team performance is evolving as expected, or getting better or worse over time.
> It needs to be dynamic, meaning it needs to give us a method to decide on budget increases or decreases throughout the year if that makes sense. This also implies it needs to provide a basis to objectively compare the needs of different teams, and tell us what the best place is to incrementally invest (or take away) marginal funding.
> Building on the objectivity aspect, it needs to align different stakeholders (such as the financial controller and team leader, or a business team and the corporate team) around a common interest to do what’s best for the company.
In the other articles in this series, we’ll construct such a method one building block at a time, starting with Part II in which we examine how knowledge work works.
