In large international groups, budget season is always a time of tension:
- How do you translate the company’s priorities into budget envelopes?
- What budget should be allocated to this initiative? to this team? to this application?
- How do you separate the share of the budget allocated to new projects? to strategic projects? to recurring activities?
- What safety margin should you keep for the needs that will emerge during the year?
- How do you make sure the allocated budget will sustain the desired level of service?
Every year, CIOs and their teams need long months to answer these questions. Few companies can boast of a budgeting process that satisfies top management, business leaders and IT managers alike. And many companies want to review and simplify their budgeting process.
In this article, we will look at the 4 main ways to structure an IT budget, the process for building it, and the strengths and weaknesses that come with each.
Before diving into the details of the different budget structures, let’s go back to a more fundamental question:
A budget, but why?
By definition, a budget is an authorization to spend for a given scope, over a given period. It allows the company to frame the use of its resources and to limit excessive spending.
By choosing how to allocate the budget, the CIO and their partners give concrete shape to the organization’s priorities. But there is often an incomprehensible lag between budget priorities and the adjustments in the size and the activities of the teams.
Building a budget therefore means framing today’s resources to meet tomorrow’s needs.
To better understand the difference between the various budget structures, let’s take the example of a fictional company: Mega Corporation.
It is made up of:
- 2 scopes, A and B (value chains, tribes, departments…)
- 5 teams, 3 in scope A and 2 in scope B
And for 2023, 4 projects have been identified, each of which potentially requires contributions from all 5 teams.
The default option: Framing detailed contributions per project
In large groups, the most common budget structure is often to detail all the contributions expected from teams to upcoming projects. Each budget line therefore corresponds to a “project x team” pair.
In our case, the budget structure has at most 4 x 5 lines, as follows:
The budgeting process:
To reach this level of detail, project managers must talk with each team manager to estimate next year’s contributions. Budget complexity is therefore directly proportional to the number of “project x team” pairs: the more contributors a project has, the longer the budgeting exercise.
Strengths
A simple result — With a simple filter, a project, team or scope manager can see what their budget is for the coming year. They can then size their team accordingly (hiring, contract terminations…).
A precise framework — Every stakeholder has a precise view of who will work on what, and for how much. Once the framework is set, execution becomes simpler.
Weaknesses
Tracking execution — By multiplying the number of lines, this budget structure also multiplies the work of comparing budget and actuals. On top of that, the small size of each line pushes managers to challenge variances that are often insignificant.
A constraining framework — When priorities change, it is harder to pivot teams. If part of project 1’s budget has to be allocated to project 2, many lines need to be changed (potentially 10!!) and the whole execution framework has to be rebuilt.
1st simplification option: Framing consolidated contributions per project
To limit the proliferation of budget lines, one can decide to stop considering each team individually and instead move budget construction up to the scope level (= tribe, value chain, stream…).
In our example, we would then have 4 x 2 lines:
The budgeting process
This apparent simplification of the budget structure does not always simplify the process of building it. 2 approaches are commonly observed:
Option 1 — keep collecting needs at the fine-grained team level, but fill in the financial tools at the scope level
Option 2 — build the project budget per scope “top down”, based on project managers’ decisions, without explicitly consulting the operational teams on the detailed contributions
Strengths
Simpler tracking — by limiting the number of budget lines, comparisons between budget and execution become simpler. Financial control teams can focus on significant variances
Reallocation during the year — It is also easier to reprioritize and change budget allocations during the year. Teams’ execution can be adjusted locally without changing the budget lines. Only changes to the project budgets themselves, or changes between scopes, will require a budget review.
Weaknesses
Blurry contributions — By moving the budget granularity up one notch, team managers lose the ability to easily see the contributions expected from them. The detailed contributions may be recorded in another tool. Major synchronization issues then appear between the operational budget view and the official view. The IT department then in practice manages 2 budgets in parallel.
A cumbersome budgeting process — Whichever option is chosen, the back-and-forth needed between the team view and the per-project scope view creates real complexity. The collection exercise often has to be redone several times as new budget guidelines come in. And when a trade-off is made on a project, it is relatively difficult to see which teams it applies to.
2nd simplification option: Framing projects only
Another simplification path is possible. For smaller organizations, with few projects involving multiple contributors, it is possible to build the budget at the project level only. The detail of who will work on each project is then considered unnecessary when building the budget. It is during budget execution that teams will draw from the budget envelopes as the year goes on.
The budgeting process
In this situation, project managers play a structuring role. At each budget period, based on management’s priorities, project managers estimate their needs for the following year and are entrusted with budget envelopes. They thus become the guarantors of proper budget consumption. Every time a team needs to contribute to their project, they open a dedicated spending line for it. And they then make sure the team has not spent more than requested.
Strengths
Simpler tracking — By concentrating most of the tracking at the project level, execution tracking becomes simpler. It becomes very easy to get a project-by-project status of progress, budget consumption, updated estimates of needs…
A stronger project culture — This way of working gradually aligns the organization along the project axis. Business Analysts, developers and testers will tend to group together in shared teams to best meet the project managers’ needs.
Weaknesses
Managing team capacity — With this way of working, team managers no longer receive precise indications of the contributions expected from them. A major risk of paralysis appears: if a team with rare skills has to contribute significantly to several projects, it may run short of resources. By not specifying the expected contributions in advance, project managers prevent the team manager from recruiting and training more people in time. Conversely, a team may end up without a project and therefore spend its energy on secondary activities. Teams will therefore often be one step behind in adapting their capacity to business demand.
Complex prioritization trade-offs — Focused on their own project, a project manager can lose sight of the company’s broader objectives. This effect is especially visible when two projects compete for a team’s limited contributions. Very robust arbitration and prioritization processes are then needed to avoid conflicts between projects, all the more so if the projects serve the needs of 2 different business lines, which are hard to arbitrate between.
3rd simplification option: Framing only the capacity of scopes
The 3rd simplification option is the most ambitious and the most impactful. It starts from the principle that it is impossible to know 12 months in advance what the business’s requests and needs will be. Setting a budget framework per scope (= tribe, value chain or stream…) is enough. We then rely on the managers of each scope, along with the project managers, to continuously agree on priorities and favor the most relevant execution.
This is called capacity-based management: activities are adjusted and prioritized to fit within the scope’s fixed capacity. In the previous approaches, it was the capacity of the teams (or scopes) that was adapted to match the desired activities. This paradigm shift pushes us to rethink the whole interplay between business teams, finance and IT. In this new framework, agile principles apply more naturally to the whole organization. We note, however, that this way of working remains too rare, given the efficiency gains it enables.
The budgeting process
Relatively simple, the budgeting process has a single objective: defining the capacity of the various scopes. The simplest approach is to take the previous year’s capacity, assess development priorities for the coming year and adjust the budget envelopes accordingly. To make the prioritization exercise more concrete, companies often adopt the Objectives and Key Results method (see previous article).
Strengths
Focus on value — by removing the project axis, this way of working pushes everyone to focus on outcomes rather than on project progress. The various stakeholders regularly review all the execution requests for the scope (= the backlog) and reprioritize execution accordingly. Completing a project milestone no longer makes sense; the priority is now to identify the additional feature that will bring the most value to the business and to users.
Decentralized management — each scope thus becomes responsible for executing its own activities. There is no longer a central entity or big feathered chiefs who unilaterally decide, from way up top, on execution way down below. Decentralized management ensures that decisions are made at the right time, as close to the field as possible and with all stakeholders.
Easy budget adjustments — it is very easy to vary the budgets of the different scopes. For a reduction, there is indeed no longer any need to specify exactly which projects or which teams will have to scale back their ambitions or let go of part of their staff. The scope concerned naturally adapts its setup to fit the new budget guidelines. Prioritization mechanisms will then make it possible to focus on the subset of the most important activities.
Weaknesses
Managing cross-cutting projects — By design, large cross-cutting projects and programs (which span several scopes) no longer have an allocated budget. They must therefore manage to convince each scope to prioritize their topic and thereby obtain execution capacity. This can become particularly problematic when the developments of the various scopes are interdependent. Dedicated mechanisms such as the Scaled Agile Framework (SAFe) are then often needed (see previous article).
The importance of governance — the whole success of capacity-based budgeting rests on the collaboration of the stakeholders within each scope. Without a shared vision and without transparency between stakeholders, this open framework and this decentralization can paralyze the organization. It is therefore essential to make it a company-wide project and to give each scope advanced management and reporting tools.
Conclusion
Through a simplified example, it quickly becomes clear that the structure of a budget is far from a trivial question. It directly shapes all of an organization’s management mechanisms, the relationships between its various stakeholders and therefore, more broadly, its culture.
The 4 categories proposed here are themselves simplified views. Some companies may run 2 budgeting processes one after the other to limit the negative effects, or adopt different approaches depending on the type of budget (Change vs Run, Human Resources vs Technical Resources, Holding vs International…).
A CIO can no longer settle for challenging the budgeting process without rethinking the structure of their budget more fundamentally. Difficulties in building a budget, managing it and prioritizing are never inevitable. The CIO must become proactive and adapt their budget structure and the associated budgeting process to build an organization capable of meeting tomorrow’s challenges.
