How to lie with cost models

Listen to this podcast

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.

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.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I agree with your post, having seen many of these fudged cost models.  But the model has to be defensible, otherwise you end up looking like an idiot when challenged.


Fundamentally I think you're absolutely right Brian, I don't think I have ever seen an IT vendor presentation without the phrase "lowering TCO" or "increasing ROI" in it somewhere. And these statements are mostly somewhere between violently stretched and completely fabricated.

However, I was told about a bank that deployed, sorry delivered, XenDesktop and profited massively from increased "user productivity" levels. They measured log-in times and found out staff were, on average, working an extra 2-3 hours at the weekend to catch up on emails etc. simply because they could.

Surely that's worth something in real financial terms - particularly if it's a large company - even if it is just people clearing out their inboxes in readiness for the upcoming week...?


Nice article Brian. I agree everyone makes numbers support their points of view and it tends to be easy at this stage. But if the OpEx savings you promise (or tried to prove) don't vet out over time you better be able to show why! :)

Good Morning all....


Fudging numbers in ROI/TCO modelling doesn't help retain long term multi-year partnerships with your clients/customers if the results don't live up to the expectations.

I certainly use TCO and ROI modelling as part of the engagement process but my aim is to review the results with the customers post-installation and ensure that they are actually seeing the results we predicted.  This then allows customers to more accurately budget for the following years, and builds confidence in the partnership.

In short ROI/TCO works, you just need to be able stand or fall with your analysis..


I think there is a lot of truth in what you say, but the reality is that geeks are crap at justifying why in my experience. They get too lost in the nitty gritty details of x,y,z and get into circular arguments about features and miss the big picture. That's why the senior leaders have to get the space, understand the real value of doing a project. It's the constant battle of justify IT to a business. The best senior guys I have worked with know how to present and deliver measurable value to their business leaders. Mid level managers get lost in cost models and completely miss the boat on transforming events going on around them. Having the balls to lead change is much harder and riskier than hiding behind cost models and playing cynic which is populist and saver thing to do. The real question is do you real GET why the F you are doing something of value for the business. I assure you most people don't and hence they are lost in circular loosing cost justification arguments around desktop virtualization, VDI etc.


Just also add that what is important for certain people is not for others...


I do have some issue with this post. Are we assuming customers are stupid?

In most of my engagement with customers, they have their own internal finance team building their own models. The vendors' models are being compared against their own. If the numbers are widely different, the vendors' credibility is in question.

Also, most of the numbers I've seen come from industry sources. If you make too much of these numbers up, you end up looking like idiots. Why put yourself in such situation?

All in all, the vendors' TCO/ROI model is to trigger the customers to consider other "factors" that they might not have before. They'll run their own internal calculation.

Very few people buy on pure TCO/ROI anyway.


I wrote about this issue way back here:

With that said, AppDetective is right on.  Geeks aren't concerned with cost models,  Well put amigo.


Isn't number 5 how changing our energy consumption habits is justified by global warming alarmists?


I think the biggest challenge usually is figuring out what the costs of the existing desktops are.  Costing the end to end cost of the new infrastrcuture and desktops/thin clients usually is fairly easy but figuring out the legacy costs is usally quite tricky.  IMHO.


In my organisation and several of our affiliates, TCO/ROI didn't come into play once. It's all about adding value to the users, meeting their expectations, etc, etc.

The TCO/ROI varies in each use case. Some will benefit and others will see very little from a financial view.

Most projects (specially in the UK) are driven from the ground up. Strategy by stealth :)

Anyway thats my two pennies worth and my first post :P


Interesting article.  My boss often quotes your last line about liars figure.  I wanted to point out that the quote is Figures don't lie, but liars figure.  This is a quote from Mark Twain.  The Figures don't lie, the numbers are correct it is just how you display them and which numbers you include, that is where the liars come in.


I must work in a more evolved organisation as we back up all our cost models with post implementation benefits realisation plans and monitor them assiduously over the life cycle of expected benefit attainment.

And we all know that benefits realisation is an exact science and the numbers can't be fudged eh?