Doug Barton <do...@dougbarton.us> writes: > On 11/24/2011 11:58, Jonathon Exley wrote: >> That's the problem - as a propellorhead I don't make the purchasing >> decisions. I can recommend products but low cost speaks more loudly than >> "this gear is a dog to work with". > > That's where you get a chance to impress the business folks by using > terms like "total cost of ownership." You make the case that while > product X may have a higher capex, that's a one-time expense that can be > amortized and/or depreciated. Whereas the opex for product Y is going to > be higher for the life of the thing. Make sure to tart up your estimate > by including the developer costs of the tools you will need to verify > that changes are correct and/or disaster recovery because everyone is > human, and the horrible UI magnifies the likelihood of an "innocent" > fat-finger mistake turning into a complete meltdown (or worse, a > security hole that no one sees until it's too late).
What Doug said. Also, don't forget the value of letting the decision makers know the worst-case. It's not really FUD if you're just opening their eyes to the consequences of their buying decisions. For instance, if you can't back the config of the device up in a human-readable/mergeable format (or worse yet, can't back it up _at all_), consider the cost per hour of downtime on a 24 port switch with a bunch of random office workers connected whose fully loaded hourly cost (including cost of office space, health insurance, employer part of FICA, etc) is, um, let's be cheap and say $40/hour. Funny how this puts the cost of both CLI-based stuff *and on-site spares* in perspective. "We can't buy it if I can't back it up with RANCID because of the negative impact it has on our business continuity" is a good way to put this into terms that the folks who hold the purse strings can understand. -r
