I like to think of fiscal year planning in IT as a “season.”
Like all seasons, planning comes every year, spans a few months, and can have a love-hate vibe to it, depending on how you feel about the weather that time of year (or, more likely, the challenges planning will bring). And this year, IT teams are dealing with a very unpredictable planning season. The economic effects of the global COVID-19 pandemic have left most IT teams with reduced budgets and a suddenly remote workforce to support. Welcome to IT planning season 2020.
Though all teams at an enterprise undergo fiscal year planning, IT is unique. First, IT teams must plan ahead of the company to manage multiple, often conflicting dependencies from their business partners, while also planning “IT for IT,” such as infrastructure, upgrades, or compliance projects. Second, there is typically heavy scrutiny placed on IT budgets. Technology investments continue to grow as companies digitally transform their organizations, and CFOs and CIOs often have to use prioritization frameworks, business cases, and governance structures to make tough decisions and balance an IT investment portfolio. Third, IT budgets are typically one of the more complex budgets in an enterprise because of the multiple vendors, service providers, and contingent hires or contractors that may be required due to changing project needs. Adding to the complexity, IT leaders need to look at investments that span years because so much of their budget is tied up in long-term contracts.
All of these challenges grow exponentially as the IT budget grows. But even for IT teams that are just learning how to better manage their planning process, a few key practices can keep things efficient and effective, and can help your team navigate the uncertainty that comes with planning season: simplify your budget view; understand your IT costs; differentiate cost to run and cost to change; and balance your IT portfolio.
Simplify your budget view
A large portion of IT planning time is spent analyzing the budget. Finance departments typically track spend in a General Ledger (GL) view, whereas IT tracks their own budgets in a more simplified Cost view.
I think of the GL view as what we spent our money on, and the Cost view as how we spent our money. Finance views necessarily include every account in the GL and are used for financial planning and analysis work, but are often more information than IT leaders need. Instead, I want to know how we spent our money and by knowing that, I can help decide how we can reduce the cost of that spend. To get that, we roll up the GL into cost pools. The goal of using a cost pool is to simplify the financial view so that we can apply decisions against that category of spend and adjust up or down as needed. The cost pools can depend on the company and the IT budget, but often consist of headcount costs, outside spend and professional services (as “contingent work”), software and maintenance, hardware and depreciation, telecom, and other discretionary spend such as travel. Not every cost pool can be changed or influenced the same way, so breaking them out helps IT leaders understand the levers they can pull to accomplish the changes they seek.
For instance, pooling employee costs shows me how much we’re spending on IT talent and allows our leadership to compare that to headcount growth projections in different geographies or by different levels, such as the choice to invest more in recent university graduates vs. mid-level management. Another lever to pull is related to the contingent work spend, which offers IT teams the flexibility to fund skill sets based on project prioritization. The contingent work cost pool also allows us to re-examine large contracts and strategic vendors annually, sometimes even quarterly, to make sure we’re getting the right value and skill set for the spend. With good planning, we can stabilize the fluctuations in spend by standardizing on one vendor by location or skill set, or by restructuring the statement of work to be project- or deliverable-based (which can help save money), depending on how we want to allocate our resources.
The key here is to consolidate the unwieldy finance view into a structure that allows you to map categories of IT spend to your organization’s planned goals.
Bucket costs by capability
Another important step in IT planning is to group costs by service area or product. This lets us further break down costs according to function and cost pool, such as looking at the software costs of our HR IT service. This can reveal areas where we’re overspending for a function, or have allocated budget that isn’t being spent efficiently or isn’t in line with the value it brings to the business. Based on that insight, I can analyze whether to increase or decrease costs, depending on company goals.
Some organizations, especially those with large enterprise IT teams, need to go further and examine the cost of the various offerings that make up a service or capability. “HR IT” may be its own service, but it’s often so large that it requires an additional break out to understand the cost of the elements that fall under it. For instance, the total costs of operating recruiting systems that were built when a company had aggressive hiring goals might be reconsidered if headcount growth needs to scale back. Looking at a cost pool by service allows us a clean view to help make these kinds of decisions.
When I do this, it also gives me the opportunity to benchmark. Having a simplified view gives me quick access to the service cost of other companies of similar size and a better understanding of how we compare. This insight is especially valuable during planning season, when teams are deciding where to invest (or divest) their IT portfolio.
Differentiate the cost to run and the cost to change
Bear with me: I consider this tip a gross oversimplification of how IT should be analyzed as an investment. However, it has served me well as an exercise for thinking about costs.
The cost of an IT service can be broken down into two categories: what it costs to run the service to keep the business operating as usual, and what it costs to change the service through project investments.
Service run cost tells me how much we need to spend just to keep our service in “business as usual” (BAU) mode. At Atlassian IT, BAU means we make no changes, but still hit our SLAs, maintain uptime, and abide by compliance/risk measures. Project cost tells me how much money we’re investing in a service to change it. This includes projects, programs, upgrades, downgrades, and other changes to a service to adjust its use according to future plans.
Why separate costs this way? Just like breaking the budget into cost pools, each area creates its own decision framework that we can use to tailor our spend to our priorities. Service run costs should (hopefully) reduce year over year, or at least maintain slower cost growth than the company growth. If it doesn’t, we need to examine those costs to figure out why. Project costs should be prioritized according to business objectives. If there are changes for which costs outweigh expected value, or changes that we want to prioritize but are under-resourced, this view can help illuminate them and allows us to update our plans accordingly.
Note that cost to run and cost to change are separate, but related. An investment in change can (and often does) impact the cost to run the service.
Balance the IT portfolio by investment type
In my experience, the bulk of IT budget conversations tend to focus on projects. The word “project” generally means “new capability,” and since most IT projects come from business demand, it’s naturally the area of most interest. Spoiler alert: during IT planning season, demand always exceeds capacity, and stack-ranking projects across all IT services rarely results in a clear path forward. Rather, it’s a stack-ranked list of who is going to be happy (“your project is funded!”) or unhappy (“sorry, maybe next year”).
We navigate this delicate process by differentiating our investments into four categories: Transformation, Scale, Incubation, and BAU.
- Transformation projects make a cross-functional investment to create a new business capability.
- Scale projects change an existing capability.
- Incubation projects are experimental investments.
- Business-as-Usual is the cost of keeping the lights on.
Transformation projects need to be cross-prioritized due to the deep interdependencies between teams, and those projects are typically sponsored by the company leadership team. For Atlassian IT, Scale projects are usually smaller and more contained projects or large enhancements that can be prioritized between the IT team and their business partner team. Incubation investments are similarly handled within the teams for which the capability is being developed. And BAU is just a year-over-year cost adjustment.
Different IT teams may have different categories, but all teams have the same goal: to make sound decisions and create a balanced portfolio. Highly regulated companies may have a significant compliance category. Or companies aggressively saving cost may not invest in incubation projects. Categories should be based on the company size, industry, and expected growth during the coming years.
Every business and team is unique, and IT is no exception. There is no one-size-fits-all strategy to make your IT planning efforts successful. But by familiarizing yourself with these methods, you can make yours significantly easier.