Viewing entries tagged
Finance

Managing Technology Finances - Part 1: The challenges

Comment

Managing Technology Finances - Part 1: The challenges

Technology and finance don’t go together well. This is an unfortunate fact of life when you are managing an IT department. A fact that you MUST deal with the finances in an IT department even if it’s a challenge. The underlying problem is that Technology presents many financial scenarios and challenges that are not present in the rest of the business. Traditional financial constructs do not always align easily with technology processes. This is exacerbated by the fact that there is a lot of complexity to technology expenses that the finance team does not understand or may not have the time or patience to understand.

In larger companies there are financial roles that straddle technology and finance to assist in these challenges. This article is geared toward small and mid-sized businesses where this role is most likely not present and not feasible. Instead the person overseeing the IT department often will need to manage these complexities.

The best way to start off this discussion is to look at a few of the challenges that present themselves in the financial management of technology. Here are some examples.

Financial Challenge: Virtualization

Virtualization allows a single piece of server hardware to be used to host multiple “virtual” server roles. Prior to virtualization a company needed to buy and maintain hardware for each server role. Today we buy one server that hosts many server roles. In a typical SMB you can host maybe 10 servers on a piece of hardware that costs about double the price of a server that would host just one role. (i.e. Database servers, application servers, print servers, files servers, etc.) The challenge comes in how these resources are accounted for.

In the beginning the hardware server (known as a hypervisor) will be built for 1 or 2 roles that are needed now. The hardware will be purchased with additional CPU, memory and disk space for future needs. Lets assume that you need a $5,000 server to fill the current needs. You may spend $10,000 on the server knowing that it will have the ability to host 9 additional roles in the future. In the long run this is much less expensive on a per server basis but you need to spend the additional money today.

How does this look from an accounting perspective? If you consider the entire purchase price of the server as a part of the project it is likely that the project may not meet the cost/benefit requirements. The business unit will likely ask why you need a $10,000 server since you clearly only need to spend $5,000. You may decide to offer two options for $5,000 and $10,000 servers to an executive team they will always pick the cheaper option. Do this for 10 projects and you end up with 10 servers at a cost of $50,000 instead of $10,000. You also end up with at least one additional employee or consultant managing all these servers.

If you make the decision to buy the $10,000 server you will face additional challenges. Will the entire cost of the server be considered part of the current project? It is likely that only a portion of this shared server will be assigned to the project. Where do you assign the other costs in the short run while there is no other server role to assign these costs? Will future projects in future years need to absorb some of the costs of this server? How will the accounting work? How does that accounting align to budgets?

The complexity expands when you look at the total cost of ownership (TCO) of this server which will include maintenance, monitoring and support. You may also have complexities at the project level where the new server is only going to support one server role for the current project and 2 other server roles are best served by existing servers. These server may be intertwined with other projects, prior years capital and different maintenance expenses.

Financial Challenge: Expenses vs. Capital

Technology does not always play will when put within the accounting confines of rules about capitalized assets. When we purchase a new piece of hardware it is most likely a capital expense. We will use a server for an example since some companies will expense inexpensive PC’s (Plus, this is not an article about accounting itself but moreover an article to assist you in navigating the relationship between technology and accounting) The server will most likely be treated as capital and depreciated over some period. For this example we will call it 3 years.

Now lets look a year down the road. An alarm goes off and the IT team is alerted to a hardware failure. (let hope a pending hardware failure and not a crash) They resolve the problem by replacing a failed piece of hardware. Lets think about common failures like a power supply, memory or hard disk. These are common failures and generally inexpensive to repair. Lets assume it’s a $200 power supply in a $10,000 server. This is likely going to be treated as an expense.

This is where the complexity sets in. What if it is a $100 stick of memory? Likely an expense. But what happens when the memory is no longer available and must be upgraded? In this case you may need to buy a $200 memory stick. Still an expense? Now suppose that there are multiple memory sticks that must be the same which causes all of them to be changed. So we are replacing 4 of them at $200 each. How about 32 of them at $200 each?

Lets take it to the next level and assume that we are talking about the 4 sticks at $200 each to repair the server. Now the IT team comes and tells us that while the machine is being repaired they can add 12 additional $200 memory sticks and prevent the upcoming purchase of an additional $10,000 server. Is this now part expense and part capital? Does it hit multiple budgets for maintenance and also a project? What if some of the memory is under warranty? It gets complicated fast.

Financial Challenge: Authorizing Expenditures

In most companies there is an expenditure limit set and beyond that limit an employee needs approval to make a purchase. This is prudent under most circumstances. With technology it may require some exceptions. When dealing with systems there may be circumstances where critical systems may need large expenditures due to problems and these expenditures may be highly time critical. Here is an example taken from a real life event.

An alarm goes off at 10:00 pm on Friday night that a system is down. A second level tech happens to be on call and gets the call. It looks like a typical outage until 2:00 am when it is clear that there is a software issue requiring the software partners assistance. At 4:00 am the software partner engages and works through the night. By 10:00 am tech identifies the following:

  • The problem is being caused by a configuration that is common to the software and the underlying server.

  • The underlying server configuration is incorrect and requires a very specialized resource.

  • Neither the software partner or the IT team has access to the specialized resource.

The server is business critical an must be up by 4:00 am Monday morning if the business will be able to continue operations. The tech updates management on the problem every 2 hours but realizes that he needs to pull in new resources if the server is going to be repaired by Monday. The tech uses his deep network to find a company that has a specialist in both the software and the underlying server technology. They look at the problem and are not sure if it can be fixed by Monday morning due to configuration issues that go back decades which need to be unraveled. the cost will be at least $5,000 and could be over $20,000.

The tech decides to personally sign a contract in order to get the work started immediately and then updates management of the cost. Management calls a 6:00 pm meeting but there are key players at dinner so the meeting is pushed to 10:00 am Sunday. The Sunday meeting commences with over an hour of questions about the problem but the complexities are far beyond what can be explained to non-technical management team members. By noon the executive team approves funding to “begin” work on the problem and asks for updates to the estimate when they have them.

While the finances were being discussed the technical team worked in 3 shifts through the weekend to resolve the problem. By Sunday afternoon the spend was well beyond the “begin work” budget long before the money was ever approved. The problem was resolved by midnight and the internal IT team started to bring back up all the surrounding systems. The 4:00 am deadline was met with about 2 hours to spare.

Had the technician stopped and waited for approval from management on Sunday, the problem would not have been fixed and the business would have been shut down on Monday. This outage would have been devastating to the business which would see catastrophic results from a shutdown between 2-5 business days. The technician made the right call to spend the money and likely saved this business from failure. Sadly the tech was scolded for this move and new spending restrictions were put in place. If a similar problem were to occur in the future this business will risk perishing at their lack of a plan for spending in an emergency.

These are just a few examples where managing the finances of an IT department present challenges that are not seen in other areas of a business. The rest of this series will focus on how to properly manage the finances of your IT department. I will present various methodologies for budgeting your technology and discuss how to plan for the worst of times.

Comment