The annual budgeting and planning cycle is the one process that touches all of IT. It has impact on how decisions are made, teams are organized, work is delegated, projects are started (and/or ended) and responsibilities are allocated Yet, few people think about realigning and transforming the budgeting process for DevOps.
The Problem with Current Budgeting Processes
The annual budgeting process is inherently flawed. It requires executives to predict the future (sometimes 12 months in advance), allocate resources accordingly and lock in the funding. And if that is not bad enough, once budgets are set, they spend the rest of the time reconciling between today’s needs and yesterday’s predictions.
Add in personal agendas and organizational politics, and you end up with a system that sucks time, energy and ambition. For an organization looking to be more nimble and responsive, our current budgeting process has the exact opposite effect.
Budgeting Process for DevOps: 3 Options
Some organizations are taking a much different approach to help cope with the dynamic demands.
1. Shorter Cycles and Frequent Reviews
Learning from our European friends, some organizations are moving to a shorter budgeting and review cycle. The traditional construct of annually funding projects remains, but plans and allocations are revisited quarterly or on a rolling basis. Both business and IT are continuously reprioritizing what features to fund and jointly collaborating on making go/no-go decisions.
The benefit of such a system is that it allows teams to allocate funds dynamically within the project—it forces teams to think in terms of a minimum viable product, and mistakes in allocations can be quickly corrected. However, there are two major drawbacks. First, funds cannot be reallocated across projects, forcing executives to still wait for the annual cycle. And second, if the quarterly review process is not streamlined, it can create a climate of constant budgeting, where managers end up spending more time jockeying for funds instead of doing real work.
2. Product-Based Funding
Others have been experimenting with product-based funding. Here applications and the associated resources are grouped into product teams and are given a share of the total budget. This budget is primarily managed by the chief product owner (represented by either the business/IT), which then further distributes it to her product owners. Just like in the last model, the chief product owner collaborates with the business to decide on go/no-go activities. In addition, it also allows chief product owners to reallocate funds across both products and projects within their portfolio. And the product owners are responsible for executing on the minimum viable feature sets within their allocated funds.
The benefit of this model is in its simplicity. Instead of making bets on projects, CFOs just have to decide on how the budgets are spread across various product groups. Chief product owners and product owners have freedom to allocate their share as they see fit. As a result, budget decisions are pushed as close to the front line as possible, allowing for greater flexibility and improved market response times.
A prerequisite to this method requires IT to move from the functional organizational model to a product model—not an easy task. As for the drawback, product owners have a tendency to fund the new/sexy work while ignoring routine maintenance work. To get around this, some organizations force teams to reserve a piece of the budget for maintenance and paying down technical debt.
3. Venture-Based Funding
While not my favorite, venture-based funding is a model a small handful of companies are experimenting with. Just like Silicon Valley-style venture capitalists (VCs), an executive board funds ideas for minimal viable products. Based on the effectiveness of the product, additional funding is granted to the teams.
The promise of this model is to seed lots of ideas and fund only the ones that work. The benefit is greater transparency and reduced financial risk. The drawback is that most companies are not wired like VC firms. A “sink or swim” culture gives rise to other problems. When viability is all that matters, why should employees follow any of the corporate rules, security policies, best practices or infrastructure requirements, to name a few? And if the idea is good, what prevents the developers to seek out actual seed funding and create a new competitor?
Changing your budgeting process for DevOps is not an easy undertaking. There are significant risks and short-term disruptions to address as the new process takes hold. But one thing is sure, a DevOps transformation must eventually include a budget transformation as well.
About The Author / Mustafa Kapadia
Mustafa Kapadia is the Service Line Leader for IBM’s DevOps practice, a business advisory practice focused on helping large enterprises transform their software & application delivery. He has over 17+ years of experience in the tech. space, both as a service provider and a management consultant.
Prior to joining IBM, Mustafa was a management consultant with Deloitte’s Strategy & Operations practice. He lives in San Francisco Bay Area, is an avid blogger (when time permitting), a speaker, and adviser to start ups.