Have you ever tried to get an infrastructure project funded only to discover that it is like pulling teeth to get your senior manager’s approval?
If so, it is probably because your senior manager is having major difficulty understanding what you are talking about. All he hears is a lot of 'technology talk and that you are asking for lots of money, and that’s not something he lets go of without understanding the value of what he will receive from the investment.
Most senior executives normally do not understand technology, nor do they want to.
Well, if that’s the case, how do you get a technology project funded that’s critical for the stability and support of your company's infrastructure? You know how important it is but you aren’t getting the message across to your boss, the CEO.
Something that will help is to discuss the project in terms of business value, not in technical terms.
Discuss 'WHY', not 'WHAT'!
'WHY' deals with benefits, i.e., business value. 'WHAT' deals with technology, things like routers, switches, etc.
Unfortunately as former technical people, IT managers tend to discuss the 'WHAT' and not the 'WHY'. Delivering your recommendation in technical terms is a guaranteed way to put your CEO to sleep or give him a major headache.
Business value includes one or more of five very specific things that help your company:
- Increase revenue
- Decrease cost
- Improve productivity
- Differentiate the company
- Improve client satisfaction
If we were to dive deeper into these elements you would quickly see that each of these business value items have a financial implication to your company, but that's material for another article. The key is to know that when you discuss something in a perspective of 'increasing revenue', 'decreasing cost', 'improving productivity', 'differentiating the company', or 'improving client satisfaction', the financial implications resonate with senior business managers, they GET IT!
When you change your presentation to highlight the business value your company will receive by making the infrastructure investment you are proposing, your senior manager hears and understands you, and when this happens, he makes a decision that usually goes your way if there is sufficient value for the investment.
A tool that can help significantly is to paint a picture of the ‘cost of downtime’ that your project recommendation will help eliminate.
Calculating 'cost of downtime' is straightforward, but first you need to visualize what we are talking about. Below is a simple infrastructure scenario:
In this example, we literally 'paint a downtime picture' to show the following:
- Corporate HQ Office is home of the Data Center where there are three servers.
- There are five remote offices (Atlanta, Denver, New York, Chicago and Dallas)
- In each location we list the number of Users (500 at HQ, 100 in Atlanta, 400 in Dallas, etc.)
- We estimate the average salary of a company employee is $20/hour.
- The green filled circles are routers.
- Three downtime scenarios are highlighted:
- If the Atlanta office router goes down or they lose connectivity, the productivity loss at 100% is $2,000/hour (100 people X $20/hour).
- If the HQ router goes down (green filled circle on the Corporate HQ box), all remote offices lose connectivity and 100% productivity impact will be $20,000/hour. (1,000 people X $20/hour)
- If the E-mail server crashes it affects productivity of all 1,500 workers. At 10% productivity factor, the impact is $3,000/hour. (1,500 people X $20/hour X 10% productivity factor)
Using these assumptions you can quantify the ‘cost of downtime’ for any technology component in your company, , , even a zone printer or a single PC.
Note: When an office (like Atlanta) loses connectivity, the office staff does not lose 100% productivity. However, the longer the downtime the higher the productivity loss becomes. Most senior managers will give you a 50% productivity loss impact if they have no connectivity, even in the first hour. Some managers will tell you it as much as an 80% hit when downtime occurs.
Once you and your client can visualize the downtime scenario we created above, you can list key components in a downtime chart and refer to it when trying to justify an infrastructure project.
In this chart, you can see that we estimate the productivity impact of many different resources, from a single PC (Row 9) to the Email server (Row 2). To estimate the productivity loss implication of any resource, simply multiply the (Number of people affected) X (Average dollar salary per hour of the impacted people) X (Estimated productivity percentage impact for that group) as shown in the examples above.
Downtime has huge cost and productivity implications for your company. If you need to implement a redundant router at the HQ building to reduce the risk of having a single router point of failure for 1,000 of your remote office workers, it is pretty straightforward and easy to get a redundant backup router funded when the CEO sees the potential productivity cost risk of downtime with a single router failure.
What makes this easier is that senior executives understand the implication when you present it in this way because they see dollars and cents, plus they understand there are other employee productivity implications. You see, it's a much bigger deal than simply a loss of productivity cost estimate. There are other intangible implications that company executives know are very important to the success of their company, things like impact on staff morale, potential impact on the company's client satisfaction, even a possibility of lost revenue and other financial problems that can occur when company employees cannot do their job.
In summary, you want to stop discussing issues in technical terms and start communicating in business terms, the five business value items listed above are key discussion focuses we need to have if we want our senior managers to hear and understand us. And something very important to remember is that if you can turn your discussion into a financial impact discussion it's all the more effective in helping you justify IT recommendations.