Evolving the IT Funding Model

Traditional IT and project funding models pose a critical business risk and, if not changed, threaten the survival of technology-based organizations.

This excerpt of the Evolving the Funding Process whitepaper by Keanen Wold, Levi Geinert, Shaun Norris, Charles Betz, Beth Dumke, Sam Guckenheimer, Troy Magennis, outlines the conflict between how traditional funding processes handle fiduciary risks and what Agile and DevOps teams need to perform well. 

Balancing the high-risk investment of innovation (research and development) with traditional business-as-usual tasks has always been tricky for corporations. Too much risk could, in the event of a sudden failure, lead to a company’s dissolution; too little innovation and the company may eventually be overtaken and lose market share to competitors and new upstarts.

Understanding the criticality of funding both innovation and business-as-usual efforts means organizations also need to use the right investment selection process, establish guardrails to avoid misuse, and meet fiduciary responsibility requirements. Organizations must fund the right investments with the right allocations under uncertain conditions, while fulfilling internal and external financial reporting responsibilities.

With the speed of change today, organizations can no longer afford to leave innovation and technology R&D to others. Instead, they must make it an integral element of their business funding model and ensure every person in the organization is responsible and accountable for innovation.

The Failure of Traditional IT Funding

So, how do organizations that have historically left innovation to outside parties adapt their culture to test and learn fast? How do they learn to accept failures and integrate innovation into their day-to-day operations?

This post outlines three fundamental problems organizations encounter when using traditional funding models for IT innovation developed, delivered, and operated by Lean, Agile, and DevOps teams:

• The one-size-fits-all model: A bank might use the same business case for funding a new branch and for funding a new mobile application that incorporates AI order recommendation features. The size and cost of the first project are easy to estimate; the size and cost for the second are nearly impossible to estimate.
• The project model: Indiscriminately funding and staffing every initiative as a “project” causes otherwise knowledgeable, capable, and productive teams to be needlessly disbanded.
• The zero-risk model: Increasing innovation requires acceptance that some ideas will fail. Traditional funding is rooted in the assumption that failure is not an option, which inevitably promotes a risk-averse culture.

The Pitfalls of Traditional IT Funding Models

Traditional funding models typically include one or many of the following traits:

• annual, large-batch budget cycles
• heavy reliance on up-front requirements and business case documentation
• equally applied to all investment risk types (from small projects like replacing carpets to large-scale software deployment)
• a project-centric operating model, with centralized reporting on the “portfolio” of project status in flight
• progress-tracking measures (earned value management, planned work complete, progress red-amber-green status) are more specified and discussed than outcome or customer impact measures
• proxy-focused management with little to no direct traceability to business value (management focuses instead on proxies like budget adherence, passing risk reviews)
• a strong “failure is not an option” assumption
• governance models that require upfront capitalization and need to get everything “right”
• burdensome personal time tracking (in part required to distinguish CapEx from OpEx)
• feature factory approaches, which treat features/requirements as immutable
• a heavy emphasis on plan adherence that tolerates little or no feedback (e.g., revising or invalidating requirements based on new information)
• mythical man-month accounting (expenses are determined based on hours against a set of requirements)
• cost accounting (all investments and operational expense must be “paid for” by some identified portion of operational revenue)

Traditional funding is the result of many years of corporate process evolution. It evolved to control and balance the risks of handing out the right money to the right places to stay in business and grow appropriately. It is well suited for investments where the solution and return on delivering that solution are well-known, such as refreshing capital assets, opening a branch in a new region, or purchasing a new aircraft.

These investments aren’t without risk, but the problems they solve are slow-moving, there is generally less variability of outcome, and they are incremental expansions rather than innovations. These investments fit nicely into a yearly budgeting cycle as they often take longer than a year to ripple onto the radar, and the cost of delay in making that investment is low.

Technology innovations aren’t as static in problem and solution space. We can make a hypothesis that a solution might solve a problem, but proving it can never be guaranteed. This is the biggest weakness of traditional funding. We want to know (up front) that the solution we are delivering is the right one, and we can’t. And a year is too long to get the funding to find out or take the first step.

Valuable and necessary innovations and opportunities unfold quickly, and to avoid missing the window of opportunity, we need a decision faster than the budgeting process allows. The cost of delay in deciding to invest is high—sometimes (ask Blockbuster or Kodak) catastrophic.

Embracing innovation as a business imperative is one issue. Evolving the funding process is also needed to allow Lean, Agile, and DevOps teams to perform at increasingly higher levels. The funding process is often orthogonal to known good practices.

We explore three of the problems traditional funding causes in more detail: the one-size-fits-all risk model, project versus product funding, and intolerance to failure. Let’s look at each one and their effects on an enterprise’s Lean, Agile, and DevOps practices.

One-Size-Fits-All Funding Models

If you run a finance team, it makes sense to use one method for all investments and budgeting. You want to avoid creating different auditing and reporting requirements for each project. Enforcing a standard process is efficient and safe. However, our case studies (available here) saw two different perspectives on the topic of standardization.

Our first case study involves a retail company. Although the company had a one-size-fits-all process for documenting business cases, the financial team who assessed these business cases hated it.

Scouring through five-hundred-page works of fiction and thousand-plus-cell spreadsheet forecasts for smaller and low-risk items was tedious (not to mention wasteful—think about that paper trail!). The gymnastics required to create a project plan were the same, whether you were hiring a team of five to ten people or planning a project that cost hundreds of millions of dollars.

In this case study, the finance team joined the technology team to attack this problem and diverge funding paths based on risk exposure patterns.

The third case study concerns a large retail bank. This organization struggled to evolve funding models that suited a DevOps approach. Interestingly, this same company operated in a totally different way when providing loans externally. For example, they had different requirements when offering lines of credit to companies with different risk profiles. In other words, there was a cultural difference between how money was allocated internally and loaned externally.

The biggest issue with a one-size-fits-all approach is that the documentation and expectation for the cost-benefit analysis for small investments and large investments are the same. This documentation effort can be excessive and unproportionally burdensome.

Fiduciary responsibility, of course, remains essential. Auditors exist for a reason, and even small investments can add up to substantial financial risk when there are hundreds of them. The evolved funding process must be adaptable, providing appropriate guardrails to keep people moving down the road safely rather than a gate impeding all flow.

Many initiative leaders in organizations with a legacy funding model report initial success at the proof of concept and pilot level only to become bogged down as they attempt to scale and operationalize. On further examination, it’s typical that pilot innovation has strong executive sponsorship (it’s someone’s idea) and is given a temporary pass on governance and compliance. When this temporary pass on compliance ends, funding needs to go down the traditional path. Pain and suffering ensue as the voluminous business case is built retroactively and presented for approval.

In other words, once an initiative reaches a certain level of success and support in these legacy funding-model organizations, it runs into a barrier to further scaling as it now must abide by the existing legacy governance processes and is no longer considered suitable for the “fast lane.”

Further, it is not possible to grant universal policy exceptions. Regardless of whether terms like “waterfall” appear, many policy frameworks and operating models include unspoken assumptions that work against DevOps behaviors. Such assumptions may both be written into specific policy language as well as encoded in the assumptions of managers and contributors who behave as “corporate antibodies” and contribute to an overall rejection of the new ways of working. The one-size-fits-all policy most often coexists with another problem: funding is inextricably linked to a project structure.

Project Funding Models

When funding revolves around a project, what happens to the team at the end of the project? It’s all too common to see that the functioning team disbanded, the members moving to other projects.

There are measurable benefits to keeping teams stable and together longer-term (see Appendix 1 of the Evolving the Funding Model paper for more). Forming and reforming teams as projects complete and begin wastes effort and creates stress. A team composed of smart, adaptable people who like challenges and already work well together is an asset to be cherished.

An evolved funding model would bring work to a productive team rather than attempt to cherry-pick the “perfect” team for every project (even if that were possible). We see this occur in companies that are moving to a product-centric model from a project-centric model.

In his book Project to Product, Mik Kersten clearly outlines the perils of the twentieth century’s cost accounting project structure. One concern he points out is that project accounting causes local optimizations rather than benefits that improve the entire value stream—piecemeal investments without a coherent strategy. These isolated investments and project teams don’t work together efficiently.

On an interpersonal note, forcing employees to worry that they may not have jobs at the end of one project until their next project is approved borders on abusive. It’s hard to think of a better incentive for team members not to finish a project.

It’s not generally overt, but those who worked in the software industry in the 1970s, ’80s, and ’90s, where “projects” were almost the universal funding mechanism, started looking and lobbying for their next project two thirds of the way through their current one. Productivity ebbed and flowed, making predictability difficult to come by.

It is becoming more common for organizations to fund a mix of project and product teams. During the annual budgeting process, process money is allocated to fund and staff incremental development as well as maintenance and operations for existing products. The case studies included in the full Evolving the Funding Model paper demonstrate that our industry is wisely moving away from project accounting, but it needs to happen more often with more types of work and different types of risk.

Zero-Risk Funding Models

Many funding models are intolerant to risk, uncertainty, or any speculation. They eliminate risk at all costs by selecting work that fits a safe and guaranteed outcome. This makes it hard for innovation and research to get funded. However, just like financial portfolios, there is a risk of low returns by playing it safe. The Google site reliability engineering (SRE) concept of an “error budget” follows a similar line of reasoning.

The use of an error budget resolves the structural conflict of incentives between development and SRE. SRE’s goal is no longer “zero outages”; rather, SREs and product developers aim to spend the error budget getting maximum feature velocity. This change makes all the difference. An outage is no longer a “bad” thing—it is an expected part of the process of innovation.

Avoiding risks could lead to a company becoming irrelevant no matter how good they were “back in the day.” Balancing the portfolio risk of too little and too much innovation is a critical funding goal.

To undertake innovation means moving intentionally with product feature experiments that are safe to fail, and if they fail, fail fast and promote learning. There is no way for complex solutions to generate information and learning without some failed experiments. Microsoft has encoded this investment risk imperative into a ratio of desirable risky features that they call 30/30/30.

Some companies have worked around the annual budgeting process’s inability to approve risky innovation by providing funding pools or staffing dedicated “[insert company name here] labs” silos to deliver short-lived or high-risk opportunities.

These are workarounds to a dysfunctional and rigid funding process ill-suited to IT with any innovative need. Isolating innovation to select groups means that good ideas are limited to that group’s capacity. Smart people are often relied upon to maintain the existing products. Should we ignore their innovative ideas? This is a high price to pay to work around the funding process. Instead, why not change the funding process to embrace innovation throughout the company?

Toward an Evolved Funding Model

We don’t just believe the current funding models are suboptimal; we view traditional funding models as a critical business risk which, if not changed, threaten the survival of technology-based organizations.

An evolved funding model must have the following traits:

• Avoid disrupting formed teams unless those teams no longer make any sense.
• Fund products rather than projects for work that will have continued investment past initial development.
• Incorporate funding of innovation as a critical aspect of doing business.
• Put dollar values on learning and inventing and treat them as assets.
• Focus investment decisions on customer outcomes rather than cost alone; track progress toward these outcomes rather than budget spent.

We propose assessing investments using the Three Horizons model, which will help communicate why an investment makes sense and how the right funding and fiduciary control mechanisms can be put in place.

A New Funding Model Built on the Three Horizons

McKinsey has long described a framework for portfolio management. It describes that investments need to consider different but overlapping time horizons to reduce the risk of being relevant now but extinct in the future due to market disruptions and better solutions. It is a tool for balancing work to do now, work to do soon, and work to do in the future in an investment portfolio. We think these categories of investment also represent how funding should be approached, with different expectations and guardrails assigned during approval.

In this model, the three horizons are called 1, 2, and 3, but they could also be called Core, Emerging, and Future Growth:

• Horizon 1 represents those core businesses most readily identified with the company name and those that provide the greatest profits and cash flow. Here, the focus is on improving performance to maximize value.
• Horizon 2 encompasses emerging opportunities, including rising entrepreneurial ventures likely to generate substantial profits in the future but that require considerable investment.
• Horizon 3 contains ideas for profitable growth down the road—for instance, small ventures such as research projects, pilot programs, or minority stakes in new businesses.

Figure 1: McKinsey’s Three Horizons Model

This model recommends investing across multiple time horizons to manage the risk of losing market share in the future.

In stable times and stable markets, most of an enterprise is focused on Horizon 1. And most financial reporting (e.g., GAAP) has evolved to describe Horizon 1 business in a standard way for transparency to investors and stakeholders. Continuous improvement is very appropriate for Horizon 1, but as Oren Harari often noted, continuous improvement of the candle did not produce a lightbulb. We would still be burning candles if funding light sources only focused on Horizon 1 ideas. We have a lot of candle-
like portfolios in IT.

Horizons 2 and 3 are about medium-term viability and longer-term survivability. The rewards of investing in ideas that will likely only repay themselves in the future are often at odds with business case assessment based on cost invested for guaranteed return. We feel Agile, Lean, and DevOps have solved the problem of reacting to unforeseen market changes and delivering new ideas that support all three horizons, but the funding process has been left behind.

Horizon 3 and, to a lesser extent, Horizon 2 require executives and teams to imagine how a market will react to new features and products they don’t yet have. They require a degree of speculation and learning if the speculation is actually factual. This makes creating a business case for Horizons 2 and 3 a leap of faith compared to Horizon 1 investments, which are better known and have quantifiable returns. Traditional funding values Horizon 1 ideas because they are more certain. But emerging funding needs to encourage the right amount of investment across all three horizons to ensure longevity for the business.

Stable product teams delivering work using Agile, Lean, and DevOps practices solve the seemingly intractable problem of funding only “safe” ventures and avoiding speculation. In fact, the investment horizons are not as simple as shown. Steven Blank says that many disruptive ideas (from Horizons 2 and 3) can be implemented by repurposing Horizon 1 teams and infrastructure into new business models. “It’s the speed of deployment of Horizon 3 products, strategies, and capabilities that are a devastating upset to the status quo.” In other words, the ability to deploy at high speed (via Agile, Lean, and DevOps practices) is a disruptive benefit in its own right.

If we use the Three Horizons model in an evolved funding process, here is how it might work:

• Proposed investments are organized into the three buckets (Horizons).
• A company would spread investment funds in an intentional ratio across the three buckets (horizons). The ratio would vary from company to company.
• Stable teams would be given capacity and permission to explore and would propose ideas that fit the Horizon 2 and 3 models, as they know the capabilities of the technology.

Success would be measured by these metrics:

• Horizon 1: Outcome achieved and customer retention in the current year.
• Horizon 2: Validated learning and customer acquisition over one to three years.
• Horizon 3: Market relevance and growth over three to five years.

This process is a far cry from what the average company does today. Many companies have diverged investment strategies across emerging and existing products by forming specialty “labs” or groups, and some have encouraged innovation at all levels by having “hack days.” But both of these workarounds stumble when it’s time to fully support the proof of concept and approve traditional funding for the project. Innovation is still seen as an outlier process rather than a mainstream funding necessity.

In the full Evolving the Funding Model paper, we examine three case studies to explore and uncover the techniques used to avoid a one-size-fits-all funding approach. We analyze how organizations moved from funding projects to products, and how the budgeting process accounted for and encouraged innovation. 

You can download the full Evolving the Funding Model paper here.

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•