Chapter 2. The Finance Bottleneck
Finance likes certainty—forecasts, plans, commitments, and smooth lines. But if you’re working in the chaos of business and software development, you can’t commit to much. Worse, everyone seems to know this:
“A business case for software doesn’t have much truth in it,” one executive said to me recently.
Suggesting some kinder diction, I said, “perhaps you mean ‘accuracy'?”
“No,” they said, “I mean exactly the word ‘truth.’”
The only certainty is that you’ll know something valuable as soon as you get out there and experiment. At first, all you’ll learn is that your idea was wrong. In this process, failure is as valuable as success. Knowing what doesn’t work, a failure, is the path to finding what does work, a success. You keep trying new things until you find success. To finish the absurd truth: failure—pardon me, ahem—learning creates success. And let me step down from my bombast and silly bravado on this point: experimentation builds knowledge, which de-risks the process of innovation and gives you the ability to adapt your software to new customer, competitive, and market demands. With knowledge, you’re given more opportunity to succeed.
Software organizations can reliably deliver this type of learning each week. The same is true for business development. We’ve known this for decades, and many organizations have used it as their core differentiation engine.
But finance doesn’t work in these clever terms. “What the hell do you mean ‘failure creates success'? How do I put that in a spreadsheet? Obviously, I’m only going to fund things that are successful! And, please, think of the poor shareholders,” we can hear the senior vice president of finance saying, “Get the *#&% out of this conference room. You’re insane.”
When you’re developing new businesses and software, it’s impossible to know the most important number: revenue. Without that number, knowing whether costs are good or bad is difficult. You can estimate revenue and, more likely, you can wish-timate it. You can declare that you’re going to have 10% of your total addressable market (TAM). You can just declare—ahem, assume—that you’re chasing a $9 billion market opportunity. Over time, after you’ve discovered and developed your business, you can begin to use models like consumer spending versus GDP growth; or, for example, the effect of weather and political instability on the global reinsurance market. And, sure, that works as a static model so long as nothing ever changes in your industry.
For software development, things are even worse when it comes to building a business case based on revenue. Finance forces IT to focus on costs: the costs of staff, the costs of its tools, and the costs of the datacenters1 to run its software. When IT is asked to make budgets, it’s rarely involved in, nor given, revenue targets.
The problem here, as Mark Schwartz points out in all of his books, is that cost is meaningless if you don’t know the “value” you’re trying to achieve. You might try to do something “cheaply,” but without the context of revenue, you have no idea what cheap is. If the business ends up making 15 million dollars, is 1 million dollars cheap? If it ends up making 180 million dollars, is 5 million dollars cheap? Would it have been better to spend 10 million dollars if it meant 50 million dollars more in revenue?
IT is rarely involved in the strategic conversations that narrow down to a revenue. Nor is it in meetings about the more useful but abstract notion of “business value.” When IT focuses only on costs, it focuses on getting “a good buy” regardless of what’s being bought. Eventually, this just means cutting costs, building up a “debt” of work that should have been done but was “too expensive” at the time. Or, even worse, outsourcing core functions like software development because it seems cheaper than in-house. This creates slow-moving, or completely stalled out IT, throwing day-old porridge into the gears of innovation.
A rental car company can’t introduce hourly rentals because the back-office systems are a mess and take 12 months to modify—but, boy, you sure got a good buy! A reinsurance company can’t integrate daily weather reports into its risk analytics because the connection between simple weather APIs and rock-solid mainframe processing is slow—but, sister, we sure did get a good buy on those MIPS! A bank can’t be the first in its market to add Apple Pay support because its outsourcing company claims that work is out of contract or, at least, will take 6 to 12 months, after the three to four months of putting together project planning documents—but, hoss, we reduced IT costs by $5 million last year. All great buys!
Worse than shooting yourself in the foot is having someone else shoot you in the foot. As one pharmacy executive put it, taking six months to release competitive features isn’t much use if Amazon can release them in two months. But, hey! Our software development processes cost a third less than the industry averages!
The Business Case Is Wrong from the Start
The annual finance cycles drive another set of problems. Modeling the business case a year out makes the predictions, discovery, and certainty sloppy. You learn only once a year, maybe with indicators each quarter, of how it’s going. But, you don’t really adjust the finance numbers: they don’t get smarter or more accurate, as you learn more each week. It’s not like you can go get board approval each week for the new numbers. It takes two weeks just to get the colors and alignment in all those slides right. And then there’s time spent on all that prewiring—an ignored type of Lean waste cost that’s rarely accounted for in the business case.
Each year, the chief information officer (CIO) has to prepare a case for a year’s worth of budget. This task trickles down all the silos of IT, which will need to predict what it will need over the next year. To calculate what’s needed, IT will need to know what it’s building—all those apps, the infrastructure to support it, and the people to develop and run them. This is predicting what your software deliverables will be, and now we’re right back to that misunderstanding of software: that we can predict what the software should be with acceptable accuracy. Indeed, as we saw in the Standish numbers, about 70% of projects have failed at this approach for the past 25 years. I’m sure it will work out for you, though!
I suggest a different approach based on the mechanics and benefits of the small-batch process.
Starting Ignorant Can Be an Asset
A smaller cycle means that you can fail faster, getting smarter each time. For finance, this means frequently adjusting the numbers instead of sticking to the annual estimates. Your numbers get better and more accurate over time. The goal is to make the numbers adjust to reality as you discover it—as you fail your way to success—getting a better idea of what customers want, what they’ll pay, and how you can defend against competition.
In business and software development, each week when you release your software you become smarter. Even though we could tag shipping containers with radio-frequency identification (RFID) tags to track them more accurately, we learn that we can’t actually collect and use that data; instead, it’s more practical to have people just enter the tracking information at each port, which means the software needs to be really good. People don’t actually want to use infotainment screens in cars, they want to use their phones: cars are just really large iPhone accessories. When buying a dishwasher, customers actually want to come to your store to touch and feel them, but first they want to do all their research ahead of time and then buy the dishwasher on an app in the store instead of talking with a clerk.
These kinds of results seem obvious in hindsight, but business development people failed their way to those successes. And, as you can imagine, the iron triangle assumptions made 12 to 18 months ago seem comical in hindsight.
There might be cases for which showing business value actually takes 12 months. However, I would encourage you to question this assumption. You can likely indicate whether you’re going in the correct direction in fewer than 12 months. For example, for 10 years, the US Air Force had been working on modernizing 43 applications used in the Air Operations Center, going through approximately $500 million without deploying a single line of code.2 One of those applications was an air-tanker refueling planner. Doing mid-air plane refueling must be important, complicated stuff, right? After following the kind of dramatically new approach that I’m discussing here, they began delivering new features weekly.
Small-Batch Finance
Some companies are lucky enough to be able to ignore finance and business models. They burn venture capital funding to rocket toward stability and profitability. We rightly complain that shareholders have short-term views and force large enterprises to live quarter to quarter, sacrificing long-term stability. Startups are even worse at that. The business object of most startups is to increase the valuation of the company with an eye on an exit: either an IPO, an acquisition, or hustling up more funding to start the cycles again. For many of the stakeholders in startups, what happens immediately or a few years after an exit is of little consequence. It’s called an “exit,” after all, not a “beginning.”
Although their goals are different, startups have much to teach other companies about developing and running software. Looking at startups for help on the finance bottleneck, though, is a bad idea. If the finance department let you grow at any costs, grab that ring, do that! However, I suggest that IT, finance, and the business settle on a more realistic, helpful set of methods to fund software development. Each of these groups wants to build and operate a system that’s beneficial, they just get stuck using yesterday’s methods for today’s problems.
In these organizations, when arguing for new financial controls over software, I see programs that take advantage of the data thrown off by the small-batch process to improve financial decisions. The German financial services company Allianz, for example, used 100-day cycles to discover and validate new businesses. Instead of one chance every 365 days to get it right, it has three, almost four. As each week goes by, it becomes smarter, there’s less waste and risk, and finance gets more accurate. If the company’s business theory is validated, the new business is graduated from the lab and integrated back into the relevant line of business. The Home Depot, Thales, Allstate, Daimler, the US Air Force, and many others institutionalize similar practices.
These cycles typically follow a 90-day plan—something around two quarters. A review board composed of people from finance, the line of business, and IT reviews projects to create or improve apps. The team working on the software explains the theories it’s exploring, ideas of how it will validate its assumptions, and, importantly, how it will measure success at the end of cycle. This is, essentially, the MVP model.3 Enterprise types get angsty about the word “minimal,” though, so I’d use a different term. I suggest small-batch process, or even proof of concept. Say whatever works in your organization.
If the proposal is good, the board approves the 90-day investment and the team is on its way. “They have three months to bootstrap a new product, to define the technical basis, to initiate the product, to find the customer, and so on and so on, and prove the value of the project,” explains Thales’ Nicolas Dumont.
After 90 days, the team reports back to this board, not only demonstrating the app and telling the story of how it went, but reporting on those original measures of success. Using the real-world data collected from the small-batch loops, they show how the strategic assumptions were validated or invalidated. By doing this, the team shows what it’s learned in the 90-day cycle. This gives the review board more certainty and actual data to make one of three decisions:
-
Keep funding the app: Our original strategy proved out, so now we can proceed with a higher degree of certainty.
-
Kill the app: Our original strategy wasn’t accurate or doesn’t make sense to pursue. We’ll save 275 days’ worth of time and money (365 days minus 90), however, and can pursue other strategies.
-
Pivot: Although we were wrong with our original strategy, we learned something new that might achieve the original business goals. We’d like to fund that thinking for another 90 days to see what happens.
With this approach, you know when to stop throwing good money after bad when you’ve invalidated your business idea. Or, you can change your assumptions and try again: maybe no one really wants to rent cars by the hour, maybe they want scooters, or maybe they just want a bus pass. If you’re lucky and you stumble on a really good idea, you can invest more money to grow the business faster rather than waiting another 12 months to request new budgeting.
Business Cases Focused on Growth, Not Costs
With a steady flow of validated learning, you can begin making business decisions that are more responsible, maybe even more accurate. If you validate that you can track a team of nuclear power plant workers better with RFID badges, thus directing them to new jobs more quickly and reducing costly downtime, you can then increase your confidence that spending millions of dollars to do it at all will pay off. You see similar small experiments leading to massive investments in omnichannel programs at places like Dick’s Sporting Goods and The Home Depot.
In addition to data-driven financial decisions, the company can also begin realizing business value sooner rather than later. “You truly don’t start learning until you deliver something to market,” Liberty Mutual’s Justin Robison says. He continues:
With our more traditional delivery methods in the past, we could spend 9, 12 months, or more defining and then delivering the “perfect” solution before getting it to market. That’s time wasted where we could be learning from our customers and improving the experience for them.
Shorter cycles allow you to make data-driven business decisions and begin getting a return on your investment sooner. This approach also reduces the risk of your project being a bad market fit. As you experiment with each small-batch release, you learn what customers will buy and not, course correcting along the way. Each time you test out your business and software design assumptions by releasing software, you reduce risk as the chart in Figure 2-1 illustrates.
Figure 2-1. Long release cycles carry more risk than shorter ones (based on a chart from the Pivotal Design Guide)
In contrast, longer release cycles mean that you won’t know if the business is a good idea for at least 12 months—a long time to carry an ever-growing pile of risk.
Finance’s Small-Batch Imperative
Creating software products in small batches means carrying less risk, getting faster payouts on investments, and taking advantage of data-driven business development. Finance must support this fail-to-succeed cycle. And it should want to: the rich stream of data makes it more responsible in its investments and provides data to support decisions.
The alternative is to shuffle back to the old model of IT financing that is—as one executive put it—“all bullshiting.” Business and software development will constantly be driven to be the cheapest provider, likely outsourced, handing over the fate of your business to a third party that profits from finding the cheapest way to fulfill its contractual obligations.
In most surveys I see, finance ranks as one of the top three problems holding organizations back from product-centric delivery, followed by business and IT culture. Finance and culture are the top things people ask me about, as well.
As we’ve seen, industrial-era finance is a real, harmful bottleneck for digital transformation programs at many organizations. The bottleneck can be cleared by understanding the true nature of software and changing funding models to take advantage of digital-era finance.
Next, let’s look at finance’s all-too-often goofy sibling. Having done this work, this is a group near and dear to my heart: corporate strategy.
1 Public, private, hybrid, multicloud, on-premises, embedded, edge, or what have you.
2 See the longer case study for this in Monolithic Transformation.
3 For a further—and nicely brief—overview of MVPs, see the Pivotal Design Guide.