How to Analyze Non-Discretionary IT Budgetspost by Chris Curran on October 28, 2010
When faced with cost pressures, our reaction is often to delay or scale-back projects or cut discretionary projects altogether. To make matters worse, critical projects are not funded while the non-discretionary IT budget – often two to four times as much as the discretionary budget – continues to grow untouched.
We’d like to share some thoughts on how to better understand and attack waste in non-discretionary IT budgets.
A Long History of Classifying IT Spend
For more than twenty-five years industry analysts have been touting the value of tracking “IT spend”, including distinguishing between discretionary and non-discretionary allocation. By collecting data across organizations, these analysts created a market for benchmarking IT budgets against industry peers and a suite of metrics that is still used today. In addition, for more than twenty years, the IT Financial Management Association (ITFMA), a leader in educating IT Finance personnel on the ways to think about IT budgeting and reporting, has been reinforcing the use of these concepts.
Digging Deeper Into Non-Discretionary Spend
Companies use these proven approaches to better understand trade-offs within the discretionary portfolios while the non-discretionary spend is often deemed the sacred cow of the IT budget. The fear is that if one were to touch the non-discretionary pie, the lights would shut off and the servers would shut down the minute the money was re-appropriated. While it is true that a large portion of the IT budget is required for core services, there can be quite a large portion of this budget which is classified as non-discretionary, but actually is more “semi-discretionary.”
Within the non-discretionary bucket there are often large groupings of cost that too often are not scrutinized, or at least not governed. Specifically as it relates to compliance changes, there are often alternatives to non-discretionary approaches. The same applies to lifecycle management and other preventive maintenance choices.
Our colleague Rob Boudrow developed this semi-discretionary spending framework to help dig more deeply into the depths of non-discretionary spending.
Semi-Discretionary Spending Buckets
|Compliance||Upgrades to system/process to conform to new regulations or meet local statutes in new markets, correct broken pricing components necessitating refunds/rebates, and/or investment to maintain, adhere to internal practices|
|Lifecycle Management||Costs incurred in migration of service components or point upgrades to primarily ensure a current, stable operating environment|
|Preventive Maintenance||Costs primarily in HW and/or SW upgrades to continually ensure that currently agreed upon service levels are met and proactively prevent outages|
|Corrective Fixes||Costs to fix known faults that have been triaged, have defined correction (e.g., patch. code change, or manual workaround) and could be tied to SLA|
|IT Delivery Management||Cost of activities to ensure effective management, governance and support of work that makes any changes to the technology environment, including activities generally considered development, engineering, and maintenance|
Although not typically governed by the same group as the discretionary funds, these categories of spend can be managed separately and trade-offs can be made.
Semi-Discretionary Analysis Identifies $200M
This past year, one of our large clients analyzed their “semi-discretionary” budget and found that more than 25% of their overall non-discretionary budget, or $200M, fell into the semi-discretionary bucket. While the exercise did not free up the entire amount, it did provide an opportunity to determine if there were better uses for those funds and allowed the organization to set future spending targets. Sold on this kind of thinking, they also started reporting this third category of spend and added governance and controls to provide needed budget flexibility in the future.
As a side benefit, as specific “semi-discretionary” buckets were compared across application areas (corrective fixes as an example), the effort highlighted inefficiencies in the application of the SDLC with regard to the design and deployment of bug fixes, which funded a few extra discretionary projects.