Design, deliver, and run enterprise blockchain workloads quickly and easily.
All servers and systems
No matter what the project is—from an exciting Internet of Things innovation to a data center migration—the IT department needs money to pay for it. But IT, all too often, does a lousy job of communicating its needs in language the financial and executive types who decide on the budget really understand.
You can argue that this is because financial officers and executives don’t understand IT as well as, say, manufacturing. You can argue it’s because IT managers tend to speak geek at budget time. Whatever the reason, the onus is on IT managers to fix the problem because they’re the ones who want the money.
“The failure is on the side of IT for not learning to understand the customer properly and thus not being customer-focused.” says Dave Chesworth, a consultant and project manager based in Manchester, England.
All too often, non-IT managers lack a clear understanding of how the money in the IT budget affects the rest of the company. In the words of Jim McGittigan, research vice president at Gartner, the IT budget is “a necessary evil and a $300 million black hole.” McGittigan stresses that his positions are his and not Gartner’s, but others echo his observation.
According to Chesworth, the most important thing IT needs to do to get a budget approved is “communicate constantly.” No matter how many client companies he works with, the process includes improving understanding between IT and the business and financial areas. “I am forced to conclude that the situation needs improvement almost universally,” says Chesworth.
It may seem obvious that IT needs to explain its budget requests to the business and financial side. Nearly all IT managers pay lip service to the concept. The problem isn’t that IT managers don’t explain their budget needs, but that they do it badly—and then suffer the consequences.
“If the CEO and CFO do not have an understanding of what’s being delivered for that X millions of dollars every year, you’re going to get further and further behind,” McGittigan warns.
It’s a truism that you must speak the customer’s language to market successfully. That, in general, is where IT managers fall down in budgeting. The benefits of the proposed budget items may be obvious to the technically oriented, but most executives aren’t technically oriented. They tend to have, at best, only a general grasp of what all that stuff in the IT department does.
McGittigan says the result is an attitude in the executive suite: “We can really save a lot of money if we cut 20 percent from the IT budget.” That may be true, but if the decision-makers don’t understand how that budget reduction affects the company overall, it may turn out to be a major mistake.
For example, one company needed a database to support a rapidly growing call center business, and it needed it quickly. Rather than spend the time and money to do it right, the staff was under pressure to deliver yesterday, so they hacked together code as quickly as possible. The company completed the database application, quickly and cheaply, but it quickly ran out of headroom. Because of poor database design, the system bogged down as the number of records grew. Updates took several minutes—unacceptable, in a high-volume call center—and the company lost business as a result. Finally, the company had to go back and completely replace the application—after replacing most of the IT staff.
If the company had been more savvy, or if the IT manager had done a better job of explaining the consequences of the executive decision, the business would have budgeted the time and resources to do the job right in the first place, thus saving itself a lot of grief and lost revenue.
The way to avoid these problems and get the budget you need is effective, constant communication. It is vitally important that the business and financial side understands what IT wants the budget money for and how it supports corporate goals and strategy.
Of course, if what you’re proposing doesn’t directly support those goals and strategy, you’ve got a problem come budget time. That means that the first step in preparing an IT budget is finding out what those corporate goals and strategies are. If you’re proposing an overhaul of the network to improve response time while corporate attention is focused elsewhere, you’re probably going to have trouble.
Even if the proposed budget does support corporate goals and strategy, it’s important to make that obvious to the business and financial types. According to Chesworth and McGittigan, this means building bridges well before budget time.
“Realize it’s not a once-a-year and submit-a-number process,” McGittigan says. “You have to build that relationship.”
Of course the relationship runs both ways. By maintaining contact with the financial and business side, the IT manager learns what goals and strategies the organization is pursuing. This also builds credibility with the decision-makers, which makes things easier when the time comes to ask for money.
“IT leaders who provide transparency and provide a relationship with the business side have the most opportunity for success in the budget process,” McGittigan says. “Those are the two major contributors in the budget process.”
Besides getting the message across, McGittigan says, there’s also the problem that staying within the budget isn’t the highest priority for IT managers.
“There’s always a financial component, and everyone gets it,” he says. “But the financial component is generally third. If I’m late or if I don’t deliver the right features or functions, I get fired. If I happen to go 10 percent over budget I’m still here. In my experience, staying on budget falls just a hair behind the timing.”
As McGittigan points out, people deliver what they’re given the incentive to deliver: “If there’s no penalty or reward built into the plan [for meeting budget] it doesn’t happen.”
Except, of course, it does have a consequence. If IT constantly busts its budget, that can destroy trust between the IT managers and the business and finance people. The results may not be as immediate as not delivering a project on time and with the desired features, but it can be just as crippling.
This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.