New! Listen to this post in our daily podcast.
by
Brian Madden
To desire to save money is a one of the big reasons people choose to implement desktop virtualization. In these cases, companies typically try to produce some kind of cost model or analysis which quantifies the amount of money they can save with the new solution.
Anyone who's been in the industry awhile has seen these cost models. Consultants have them. Vendors have them. You boss makes them. They range in complexity from a few simple lines on a napkin to multi-page Excel workbooks that could make a mathematician's head spin. And while it's truly rare that a company makes technology decisions solely based on cost models, it's a safe bet that they play at least a little part in most IT decisions.
All that makes what I'm about to say all the more scary: When you're creating a cost model to justify your desktop virtualization project, I absolutely 100% guarantee that you can easily rig the results to ensure the model comes out in your favor. Every time. No problem.
You can take the same situation—the same company with the same apps and users—and easily create two models; one that shows VDI is brilliant and one that shows it's stupid.
How? It's simple! All you have to do is get a bit creative. So here are the five most basic techniques you can use to ensure that the cost models you produce always lead to the result you want.
Technique #1. Bundle in the "soft" costs
Adding soft costs to your model is the simplest way to get it to swing widely in the direction you want. (Remember, these work in both directions. You can calculate the soft costs of expenses or savings.) By "soft costs," we're talking about the qualitative costs that effect a value to the company that can't be quantified with money. Common soft costs include things like "employee productivity" or "user satisfaction."
Of course since we're talking about cost models here, if you want to include soft costs, you have to quantify them in order to plug them into your spreadsheet. So how do you quantify stuff like this?
For user productivity, sometimes people think, "we get 3000 helpdesk calls per year, and 15% are related to desktop support. If each helpdesk call costs us $200 (another easily manipulated total BS made-up number), then we can save 90k (3000*0.15*200) dollars per year if we virtualize our desktops and eliminate those calls!" That's a basic level of soft cost manipulation.
If you want to take that to the next level, toss in the productivity lost while the users are down. You might calculate that the average loaded cost of an employee is $50 per hour, so if desktop virtualization saves each of your 1000 employees 2 hours per year, that's a $100k (1000*2*50) yearly savings right there! (Of course it's not like the employees are really going to work two more hours each year with desktop virtualization. In the real world they'd probably just stay late to make up the time they lost while waiting for their desktops to be fixed. This is why furloughs are so good for employers.)
If you want to get really advanced in the soft cost areas, you can add all sorts of things to the hourly "loaded" cost of an employee. Sure, taxes and benefits are easy. What about training, facilities, admin overhead, equipment, knowledge of your specific environment, and lost earnings potential?
Technique #2. Move trackable costs to non-tracked areas
The easiest way to deal with the pesky costs that keep breaking your model is to just get rid of them, which you can easily do by reallocating them to areas that are not tracked by your model. Power and air conditioning are great examples of this. One argument for desktop virtualization is that it could lead to more people working from home. This in turn could mean fewer people working in the corporate offices which leads to lower rents, electricity consumption, and heating and cooling costs—all of which result in money saved for the company (which helps whatever cause you're modeling which lets users work from home).
Of course in the grand scheme of the world, this is actually less efficient, because now you have each employee paying for his or her own power, cooling, and heating. So really you're just transferring costs from something the company pays for to something employees pay for. (I know it's more complex than that because you have to take commute times and distances into this too, but I'm choosing to ignore that since I'm trying to prove a point. See Technique #5 below.)
Advanced liars (err, cost analysis consultants) can combine this with Technique #1 to assign a cost to the productivity lost by not having face-to-face meetings.
Technique #3. Abuse what you can't prove
A few months ago, we had a conversation about whether VDI was actually more "green" that traditional computing. One of the points we made was that actual power consumption of a device (server, desktop, thin client, whatever) is not necessarily the same was what the device is rated for. In other words, just because a server has two 800W power supplies doesn't mean it's actually consuming 1600W whenever it's powered on. That just means that the maximum output of the power supplies is 1600W. The actual consumption will vary based on how much memory is installed, how fast the processors are, how many peripherals and drives are installed, etc.
But how do you know how much power each server is consuming at any given moment? Sure, some servers have instrumentation on this, and some UPSes provide this data, but most don't. And most people don't know about the wattage thing. So if you're trying to kill new servers because they consume too much power, just go ahead and make up the number you use to calculate your per-hour operating costs. If you're wrong in the end, who will ever know? It's not like your facilities department is going to catch you later on.
So this is different than the BS soft costs from #1 or the real hard costs you're transferring out of your organization (#2). This is all about hard costs that you know are real but that you can't actually measure. So toss 'em in!
Technique #4. Justify the savings of features you know you'll never use
Cost models are complex formulas made up of many components—some more easily justified than others. ("How much does this server cost and how many users can it support?" is more universally accepted than "How much increased productivity will I get from happy users?") But what if you have "real" data that hurts you? No problem! You can still use it to help you. If you have data that helps your cause, you should put it in your cost model, even if you know it will never apply to your environment. The more universally-accepted the data, the better!
Does your hypervisor allow you to over-commit your physical memory across multiple VMs? Great! Built it into the cost model, even though you know there's no way in hell you'd actually do that in production!
Does the protocol you want to use consume half the bandwidth of a competitor whose product you don't want to use? Fantastic! Put that into your model, even if you have a LAN environment with unlimited bandwidth.
Technique #5. Ignore data that doesn't support your views
If there's only one liar's technique you take away form this article, make it this: if the data doesn't support your view, just ignore it!
Since there's no universally-accepted list of what's appropriate to include in your cost model, it's a simple matter to just ignore the data that doesn't help your cause. That way you can build a strong model that supports your desired case while showing that your company will clearly (and swiftly) go out of business if they chose a different desktop virtualization technology than what you want.
Remember, figures lie and liars figure. So fire up Excel and get to it! And if you have any techniques that I forgot, please share them below.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.