Dangers of Bimodal Budgeting

Published: by

One of the hot words over the last few years has been "Bimodal IT". I won't go into a complete definition - let's leave the people who make much money off of the idea to explain it. The short form is that some technology activities are more traditional, sequential and driven by a focus on safety, while others are more innovative, agile and driven by a focus on new risks.

While there is some truth to the distinction, the world is far more complex than just "Mode 1" and "Mode 2". Further, adopting any oversimplified paradigm can lead to all sorts of unintended negative consequences.

Yesterday, in a Twitter discussion follow-up to an article about (what else?) bimodal IT, Simon Wardley, creator of the famous Wardley maps (if you deal in strategy and future planning and don't know Wardley maps, go learn them now), had the following to say:

The idea that somehow the two groups will work together in a ‘dance’ is fanciful. Brawl would be more like it.

This reminded me of the experience I had as a VP of IT at a very large global financial firm over a decade ago, and the dangers of "bimodal budgeting".

Shortly after I came on board, the CIO and Board brought on a well-known (but not always well-delivering) consulting firm. The consulting firm looked at our financial structures and costs, and suggested we adopt 2 distinct budgets:

  • Run the Business
  • Change the Business

Run the Business

Run the Business, or RTB, is the money set aside to keep operating. If it cost you $5,000 per year per employee, or $50,000 per year per customer, then that was what you spent. If your customer base grew 5%, then your total RTB - or at least the part derived from customer costs - grew 5%. If your employee base shrank 7% (that happened too), your RTB budget - or the part derived from employee costs - shrank 5%. It was straightforward and automatic.

Of course, the actual calculations were far more complex - otherwise there would be no follow-on work for these consultants - but the concept was pretty simple.

At first glance, there is some logic to it. After all, if your cost per customer is $50,000/annum, and you increase your customer base by 10%, then your "keep the lights on" operating budget should increase 10%. End story.

In truth, the real value comes not from tying the budget to the customers per se, but in forcing you to measure what your cost per customer or cost per employee is. Sure, in principle, every business should know these numbers, but few do, and as the business gets larger and more complex, these numbers become harder to tease out.

Change the Business

Change the Business, or CTB, is the money set aside to, well, change the business.

  • If you have a plan to reduce help desk costs by implementing self-service password reset, the budget for that project is CTB.
  • If you want to implement a new system to get derivatives prices to upper-middle-class retail traders, and hence grow the business, that is CTB. And, yes, in some European countries, upper-middle-class people buy and sell options like others do mutual funds, ETFs or equity. I was surprised when the head of options Europe called me and wanted to leverage my notification service to sell options!
  • If you plan to invest in a new cloud Web service that makes application deployment twice as quick, and therefore save on employee cost across all application development groups, that, too is CTB.

Bimodal Budgeting Blindness

The well-intentioned (at least on the bank's part) move to "Bimodal Budgeting" led to two major dangers, both of which, unfortunately, came true:

  1. Beyond the traditional budget tensions between groups, you now get twice the battle: once for your RTB budget, and again for your CTB.
  2. You kill innovation.

The latter was the biggest issue.

You are starting the fiscal year. Your group's budget is a nice round $20MM for staff, capex and opex, half for staff and half for expenditures. Actually, staff was budgeting entirely separately, so maybe we should call it "Bimodal2 Budgeting", but we will leave that for another idea.

Out of your $10MM for expenditures, $7MM is for RTB and $3MM is CTB.

As part of your research, you realize that leveraging a new technology, say containers for higher server density or lower cost of deployment, can reduce your RTB by $1MM per year. Even better, it will only cost you $1MM to implement this year. In other words, this is a dream project, one that returns 100% ROI in the first year. It just doesn't get better than that.

But you have an issue. Sure, you have the money in your budget - after all, you will spend $1MM now and get it back within 12 months - so the net change to your budget this year is 0%, and the numbers just go up after that. But your budget is in 2 parts: RTB and CTB. And your CTB already is spoken for, fully allocated.

Your project dies.

And this, of course, is the ideal project. If your project starts mid-year, so the 100% first-12-months ROI doesn't kick in fully this year? Next, most investments take a few years to return a strong positive ROI. How many of those get killed?

Worst of all, as your innovative employees begin to realize that even the best ROI projects have no chance of being funded, they stop trying.

All of this happened, in real-time, as I watched.

Unsurprisingly, few good people stuck around.

Summary

The road to hell is paved with good intentions. Don't be afraid of change in your business processes, organization, budgeting... but always check for the law of unintended consequences. Most importantly, check for the negative cultural effects it will have on your people.

Conversely, if you find cultural challenges - internecine battle or outright warfare, little innovation, frustrated employees - ask what your structures are doing to suppress your good people.

Better yet, ask us.