5 ms·

The Limits of Cost-Benefit Analysis in IT - Server Fault Blog

20 points by ajdecon 15y ago

count 15y ago
I think he was right - technical people apparently have a hard time explaining themselves. I think the point of the article is that you need to be able to include actual benefit information, which isn't necessarily straight forward to gather or develop, rather than just short term stuff. Benefits are not just inverted consequences, in other words. What it comes off as saying, is that who cares, just buy what ever you want, I mean, a developer might get upset that it takes more time to purchase equipment than to write some code. I can't imagine there being anything remotely close to a catch-all rule for this kind of thing - buying new hardware at a Fortune 50 vs. buying hardware at Facebook/Google vs. buying hardware at small, agile, cash-rich web startup are all going to be radically different, as they should be.
bugsy 15y ago
In real life, cost-benefit analysis typically works similar to business plans. First you decide what you want to do. Then you write up a case supporting that. In doing so, you make lots of wild guesses and make sure that + ones use the high side of the guestimate range, and - ones use the low side of the range. Remember, there was a business case and cost benefit analysis for pets.com and nearly every other internet failure that justified everything they did to investors. This is the real limit of these analyses.
DrJ 15y ago
I was hoping for a more numeric analysis of purchases and upgrades for IT/SysOps. The article is talking mostly about vague non/difficult to validate benefits that may or may not exist numerically. Sure, "Pride", "Momentum", "Inspiration" are great benefits from making something 'awesome' but those metrics do not quantify well in a corporate, and even in a startup setting. I think his second example "momentum" actually sums up the viewpoint about hardware purchases, ' IT tells them they can’t push it to production until a new server gets approved, ordered, setup, tested, and then deployed, they will get discouraged. Eventually, they won’t even think about new features. ' Is this a problem with IT's budget? or is it a problem with a dev who gets discouraged too easily? Why not simply the feature? why not nag at the IT? It feels like the author was flippant about this issue, and in reality doesn't do any real cost-benefit analysis.
- mistermann 15y ago
  I quit my last job in very large part precisely because they didn't think of this aspect of decision making, and the cost of me leaving was a hell of a lot more than the hardware that would have made me happy enough to stay.

20 points by ajdecon 15y ago

count 15y ago

I think he was right - technical people apparently have a hard time explaining themselves. I think the point of the article is that you need to be able to include actual benefit information, which isn't necessarily straight forward to gather or develop, rather than just short term stuff. Benefits are not just inverted consequences, in other words. What it comes off as saying, is that who cares, just buy what ever you want, I mean, a developer might get upset that it takes more time to purchase equipment than to write some code. I can't imagine there being anything remotely close to a catch-all rule for this kind of thing - buying new hardware at a Fortune 50 vs. buying hardware at Facebook/Google vs. buying hardware at small, agile, cash-rich web startup are all going to be radically different, as they should be.

bugsy 15y ago

In real life, cost-benefit analysis typically works similar to business plans. First you decide what you want to do. Then you write up a case supporting that. In doing so, you make lots of wild guesses and make sure that + ones use the high side of the guestimate range, and - ones use the low side of the range. Remember, there was a business case and cost benefit analysis for pets.com and nearly every other internet failure that justified everything they did to investors. This is the real limit of these analyses.

DrJ 15y ago

I was hoping for a more numeric analysis of purchases and upgrades for IT/SysOps. The article is talking mostly about vague non/difficult to validate benefits that may or may not exist numerically. Sure, "Pride", "Momentum", "Inspiration" are great benefits from making something 'awesome' but those metrics do not quantify well in a corporate, and even in a startup setting. I think his second example "momentum" actually sums up the viewpoint about hardware purchases, ' IT tells them they can’t push it to production until a new server gets approved, ordered, setup, tested, and then deployed, they will get discouraged. Eventually, they won’t even think about new features. ' Is this a problem with IT's budget? or is it a problem with a dev who gets discouraged too easily? Why not simply the feature? why not nag at the IT? It feels like the author was flippant about this issue, and in reality doesn't do any real cost-benefit analysis.

mistermann 15y ago
I quit my last job in very large part precisely because they didn't think of this aspect of decision making, and the cost of me leaving was a hell of a lot more than the hardware that would have made me happy enough to stay.