Non-Technical Factors in Vendor Choices

[NetworkGroover]

Lol technical issues... too bad, accounting says that it's cheaper to run our routing off the ASA instead of using a dedicated L3 device, so you get that EIGRP to work, or you're over budget. And that won't look good on your annual review.

Accounting is architecture, remember that!

Wow... classic.  That's where you need to put a $$ behind what the outages cost you because of the technical issues.  Or maybe have them sit on troubleshooting calls with your end users to explain to them that they shouldn't be complaining because it their decision that saved the company money!

[deanwebb]

you missed out support and ease/cost of acquiring skillset (whether permanently in-house or temporarily/contracting or outsourced/consulting).
<snip>

You know... reading this... I gotta say this sounds a little lazy (Minus the support part - that's spot-on).

So you're saying you wouldn't go for an overall 20% improvement in performance simply because you'd have to learn something new?  Isn't that part of working in IT?  I mean I get the reality and all... but in my mind I'd say a little growing pain (which should be minimal if you have the right people with the right mindset) is well worth a 20% permanent improvement to the network.  You should always welcome a new challenge and improve your skill set!  But I guess that's why I would never be a CTO...

*I* sure love training and learning about other vendors, but I'm not paying the training cost. In an environment with any amount of turnover, the risk is that as soon as you train up a guy, he walks to a different place, leaving you with zero ROI on the training.

And if you have to train up the next guy because the market isn't very forthcoming with Vendor X experience, then it's that risk, all over again.

[deanwebb]

Lol technical issues... too bad, accounting says that it's cheaper to run our routing off the ASA instead of using a dedicated L3 device, so you get that EIGRP to work, or you're over budget. And that won't look good on your annual review.

Accounting is architecture, remember that!

Wow... classic.  That's where you need to put a $$ behind what the outages cost you because of the technical issues.  Or maybe have them sit on troubleshooting calls with your end users to explain to them that they shouldn't be complaining because it their decision that saved the company money!

CTO Counter-Argument: Do you know in advance what the outages will cost? No? Then we can't count them. Besides, our customer-focused, next-gen, transparent, strategically synergized and orchestrated IT staff will be able to deal with outages and prevent them from costing us any actual money.

[NetworkGroover]

Lol technical issues... too bad, accounting says that it's cheaper to run our routing off the ASA instead of using a dedicated L3 device, so you get that EIGRP to work, or you're over budget. And that won't look good on your annual review.

Accounting is architecture, remember that!

Wow... classic.  That's where you need to put a $$ behind what the outages cost you because of the technical issues.  Or maybe have them sit on troubleshooting calls with your end users to explain to them that they shouldn't be complaining because it their decision that saved the company money!

CTO Counter-Argument: Do you know in advance what the outages will cost? No? Then we can't count them. Besides, our customer-focused, next-gen, transparent, strategically synergized and orchestrated IT staff will be able to deal with outages and prevent them from costing us any actual money.

I'd counter with it's more foolish to bet against what history has shown time and time again, and specifically choosing to not learn from previous CTO's mistakes...  then I'd probably be boxing my stuff up...

[NetworkGroover]

you missed out support and ease/cost of acquiring skillset (whether permanently in-house or temporarily/contracting or outsourced/consulting).
<snip>

You know... reading this... I gotta say this sounds a little lazy (Minus the support part - that's spot-on).

So you're saying you wouldn't go for an overall 20% improvement in performance simply because you'd have to learn something new?  Isn't that part of working in IT?  I mean I get the reality and all... but in my mind I'd say a little growing pain (which should be minimal if you have the right people with the right mindset) is well worth a 20% permanent improvement to the network.  You should always welcome a new challenge and improve your skill set!  But I guess that's why I would never be a CTO...

*I* sure love training and learning about other vendors, but I'm not paying the training cost. In an environment with any amount of turnover, the risk is that as soon as you train up a guy, he walks to a different place, leaving you with zero ROI on the training.

And if you have to train up the next guy because the market isn't very forthcoming with Vendor X experience, then it's that risk, all over again.

Fair, but if a 20% increase in performance is PROVEN (not just claimed by a vendor with no supporting data), that's a definite - not a risk.  Then you're only risk is investing in people, which I frankly believe will always be a risk, and a risk you should take.  To me it's fairly obvious who to invest in - they're just a certain "type" of person.  Burnyd, yourself, and that1guy15 being a few perfect examples.  But, again, it's easy for me to say as an armchair quarterback.

[deanwebb]

Putting a management hat back on... also combining responses...

Your first response counters the argument in the second. We get the ROI on the hardware *if* we go with training, but the training is going to reduce our ROI. As for outages, even with all the training in the world, we're still going to have outages. Why not take a few more hits without a big training budget? If the hits are small, then they're less than the training cost and, therefore, justified. As for the major hits, we call TAC anyway for an RMI. Who needs expert training to dial a phone and say, "Please send the replacement to this address"?

(Management hat still on) We view training here as part of each employee's personal growth, not as a requirement for going with a particular vendor's gear. Granted, if we put in something brand new, we need to get that vendor training lined up. But for our core business functions, we should be able to rely upon normal personal growth for our source of expertise.

We also strive to maintain a structure in which, if we had to ramp up staff quickly, we wouldn't be hampered by obscure or exotic technology. If we have something off the beaten track that's easy to pick up on, not an issue. If we have a core function handled by some bespoke solution that has a high learning curve, well... how familiar are you with the fall of the Roman Empire? Once they lost the ability to support and maintain their technology, it went into decay, disuse, and then disappeared. I want to make sure our IT dollars are spent effectively.

***

(Management hat OFF) There are some niche players - firewall management, for example - that don't compete with Cisco. Those guys can actually be selected on the basis of their merits and then procurement goes to it at grinding down the prices. Some of the niche players, however, ride on the coattails of a major player and then the above stuff comes into play. I see this in the netflow analysis market. There are two major vendors there and *one* of them is in the Cisco order book. That's the one that we looked at the most, even though I liked the other vendor more.

Where majors collide, IE Cisco v. Microsoft in the voice market, it gets really brutal. The network runs on Cisco; the servers run on Microsoft. Two men enter, one man leaves. Heaven help the engineer that champions the wrong vendor.

I mentioned "How about Arista?" when we were talking about needing much higher 10gig port density in the datacenter. That led to an interesting discussion... basically, it would be better to take the hit on the datacenter 10gig stuff than it would be to take the bigger hit for Cisco to get mad and give us less of a discount. Even a single percent move on the discount would be a much bigger cost for us, globally, than what it would cost for us to stay with Cisco in the DC.

[NetworkGroover]

Putting a management hat back on... also combining responses...

Your first response counters the argument in the second. We get the ROI on the hardware *if* we go with training, but the training is going to reduce our ROI. As for outages, even with all the training in the world, we're still going to have outages. Why not take a few more hits without a big training budget? If the hits are small, then they're less than the training cost and, therefore, justified. As for the major hits, we call TAC anyway for an RMI. Who needs expert training to dial a phone and say, "Please send the replacement to this address"?

(Management hat still on) We view training here as part of each employee's personal growth, not as a requirement for going with a particular vendor's gear. Granted, if we put in something brand new, we need to get that vendor training lined up. But for our core business functions, we should be able to rely upon normal personal growth for our source of expertise.

We also strive to maintain a structure in which, if we had to ramp up staff quickly, we wouldn't be hampered by obscure or exotic technology. If we have something off the beaten track that's easy to pick up on, not an issue. If we have a core function handled by some bespoke solution that has a high learning curve, well... how familiar are you with the fall of the Roman Empire? Once they lost the ability to support and maintain their technology, it went into decay, disuse, and then disappeared. I want to make sure our IT dollars are spent effectively.

***

(Management hat OFF) There are some niche players - firewall management, for example - that don't compete with Cisco. Those guys can actually be selected on the basis of their merits and then procurement goes to it at grinding down the prices. Some of the niche players, however, ride on the coattails of a major player and then the above stuff comes into play. I see this in the netflow analysis market. There are two major vendors there and *one* of them is in the Cisco order book. That's the one that we looked at the most, even though I liked the other vendor more.

Where majors collide, IE Cisco v. Microsoft in the voice market, it gets really brutal. The network runs on Cisco; the servers run on Microsoft. Two men enter, one man leaves. Heaven help the engineer that champions the wrong vendor.

I mentioned "How about Arista?" when we were talking about needing much higher 10gig port density in the datacenter. That led to an interesting discussion... basically, it would be better to take the hit on the datacenter 10gig stuff than it would be to take the bigger hit for Cisco to get mad and give us less of a discount. Even a single percent move on the discount would be a much bigger cost for us, globally, than what it would cost for us to stay with Cisco in the DC.

You sound like management material - and I don't say that as an insult.  Wouldn't mind working for someone with that mindset even if we don't see eye-to-eye because you at least have some merit behind your statements.

Haha... as for the Cisco discount.. just tell Cisco that you're considering Arista, and enjoy the temporary almost free gear.

EDIT - And wow, being held hostage via discount?  Classy.

[NetworkGroover]

you missed out support and ease/cost of acquiring skillset (whether permanently in-house or temporarily/contracting or outsourced/consulting).
<snip>

You know... reading this... I gotta say this sounds a little lazy (Minus the support part - that's spot-on).

So you're saying you wouldn't go for an overall 20% improvement in performance simply because you'd have to learn something new?  Isn't that part of working in IT?  I mean I get the reality and all... but in my mind I'd say a little growing pain (which should be minimal if you have the right people with the right mindset) is well worth a 20% permanent improvement to the network.  You should always welcome a new challenge and improve your skill set!  But I guess that's why I would never be a CTO...

*I* sure love training and learning about other vendors, but I'm not paying the training cost. In an environment with any amount of turnover, the risk is that as soon as you train up a guy, he walks to a different place, leaving you with zero ROI on the training.

And if you have to train up the next guy because the market isn't very forthcoming with Vendor X experience, then it's that risk, all over again.

I'll say to this, though I know it's an impossibility, that the company should take a good hard look at itself and accept the fact that it may be at fault for people leaving.  Why are those people turning over?  Are they unhappy about pay? If other companies are willing to pay them more, that's not a fault of the person, or the other company - your company has decided that it's only willing to go so high.  You shouldn't hurt/hinder your infrastructure or team because of a fear of something happening that you're empowering to happen - if that makes any sense. That goes for things other than pay as well.

"Training" can be cheap.  It doesn't have to be a 5k/per person class with an instructor who hasn't spent a day in the field.  You can hold weekly morning breakout sessions where a topic is chosen and presented by a member of the team.  Not only does it force the member to sharpen their skills around that topic, it teaches/reinforces their ability to speak in front of a group of people - particularly their peers, which of course is great for a multitude of reasons.  Maintain a knowledge base - an internal team blog of how-to's and what-not.

There are options out there....

[deanwebb]

When I was at MSFT, we actually did brown-bag sessions and got lots of magical manager review points for doing them. That is a good idea.

Where I am now, we do periodic briefings on tech that we're implementing, just so that everyone else knows what's going on. We document level 1&2 work instructions for the helpdesk people that will also be in charge of repetitive tasks.

We actually get one conference and one week-long class per year for our personal development. It's seen as a part of the overall benefits package, right up there with PTO and a very good health plan. With that mentality, sure, I could take a class and then skate away, but that training wasn't part of an ROI calculation. It was an employee benefit. That being said, there's encouragement for me to maintain my CCNP, get entry-level vendor certs (especially if the test is for free), and work towards a CISSP. Advanced vendor certs? Naaah, not so much. I'm not working for a VAR, so I don't need to gather those up. Experience with a product, absolutely, get as much of that as I can. General certs, like GIAC? I got the green light for those.

[wintermute000]

you missed out support and ease/cost of acquiring skillset (whether permanently in-house or temporarily/contracting or outsourced/consulting).

No use going with vendor X for 20% performance gain if nobody on your staff has the skills, you have to fly them somewhere else for a week @ 5k per head to do the basic course and their TAC is useless, etc. It usually has to be a pretty big gap to go to a completely unknown/niche vendor. Its obviously less of an issue for the big boys e.g. Cisco to Juniper.

Of course it depends - eg. deploying brocade switches on your access layer instead of cisco for example, no big deal. Core / MPLS switches, another issue altogether. (In Brocade's defence I've seen cost/performance figures up to 50% better than comparable ASRs so yes it can make sense LOL). Ditto for changing firewall vendors.

You know... reading this... I gotta say this sounds a little lazy (Minus the support part - that's spot-on).

So you're saying you wouldn't go for an overall 20% improvement in performance simply because you'd have to learn something new?  Isn't that part of working in IT?  I mean I get the reality and all... but in my mind I'd say a little growing pain (which should be minimal if you have the right people with the right mindset) is well worth a 20% permanent improvement to the network.  You should always welcome a new challenge and improve your skill set!  But I guess that's why I would never be a CTO...

I'll take that comment in the nicest possible manner (but it would be nice if you bear in mind the non-cisco alphabet soups next to my handle and my constant skepticism of any Cisco non-R&S product). You're missing the point entirely - I'm speaking from the POV of management which deanwebb has covered off nicely.

You need to take off your vendor SE / telco / military hat and look at it with an enterprise POV with their harried in-house team of what, typically 2-3 guys (1 if mid market) who already have a major skills gap compared to consultants/SE/PS engineers. How much is it going to take to upskill them? And critically how much use are you going to get out of those skills? And how much extra are you paying for PS every time something remotely major needs to happen? What's taking that engineer out of the firing line for a week worth? then say add an extra week of man hours lost a year due to unfamiliarity. See it all adding up. And again, can you quantify how many dollars this '20% better' is going to make for the enterprise?

The 20% figure is plucked out of the air but lets go with that. Typically I'm referring to replacing one component (or set of components) - how does a 20% more throughput edge firewall improve the network performance by 20%? And a lot of the time, esp. in enterprise, they are not using anywhere near the capacity of their products. What's 20% more throughput going to help the business in everyday terms on their access switching or a nowhere near loaded firewall? (of course if there's a must-have feature then that's an auto deal-maker or breaker but that's a different question). Let me spin this around: buying existing vendor C (lol) will give you capacity of 100, buying vendor X will give you capacity 120 - but guess what, your maximum anticipated usage is 80. What's the extra 20 doing for your bottom line? nothing.

Finally remember that the network is an afterthought to most enterprises. They want the least disruption, the least change, the lowest opex and lowest capex. Nobody blinks an eyelid when replacing like for like so politically there is zero risk. New vendor? Its on your head..... so how many conservative managers want to make that risk? What plaudits do they gain by putting in something that's got 20% better throughput? Harsh but that's the reality. Then of course to put in the new vendor product, its new change (at least) or project (normal) or program of works (eek!). Who's paying for all this disruption? There is a ton of political conservatism and inertia. These aren't necessarily good reasons-  but they're there nonetheless, and is it worth your political capital/time to push this particular wheelbarrow uphill? For a minor performance gain I would probably lean on the side of no. Again, I'm not talking about a killer or required feature, I'm talking about marginal gains.

I've been through this discussion many a time when I was in-house and pushing for something different. Why are we still deploying 8XXs instead of SRXs? Why are we paying for ACS when I could just spin up FreeRadius? Why don't we replace all those expensive 3750Xs with Brocades, then I can stop begging you for IP Services licenses? etc. and I lost that plenty of times due to the management reasons deanwebb sprouted off quite readily. I don't always agree with it but I've heard those arguments enough times from managers who weren't all stupid (and including one or two pretty damned good managers actually) to realise that there is a kernel of truth in there.

And don't discount the hiring question. Maybe you have it easier in the US but here in Oz its difficult enough to get good normal network engineers (and by that you basically assume at least a CCNP level of knowledge on Cisco products). Have you ever tried to hire a good Juniper guy? Now drill down to a more obscure vendor. See where I'm going with this.... this applies also to getting contractors and/or adhoc resources.

Anyhow just pointing out there are a myriad of (possibly good) reasons from a management POV why you wouldn't just buy a competitor's product that is better on paper and cheaper. In my line of work, I see this ALL the time and believe me its in my company's interests to push for a change (since then win the professional services gig designing and implementing, and basically every vendor has a better margin in it for us than Cisco... as our director says, there are 19 Cisco gold partners in our city alone, why chase the same dollar bill as them)

[NetworkGroover]

you missed out support and ease/cost of acquiring skillset (whether permanently in-house or temporarily/contracting or outsourced/consulting).

No use going with vendor X for 20% performance gain if nobody on your staff has the skills, you have to fly them somewhere else for a week @ 5k per head to do the basic course and their TAC is useless, etc. It usually has to be a pretty big gap to go to a completely unknown/niche vendor. Its obviously less of an issue for the big boys e.g. Cisco to Juniper.

Of course it depends - eg. deploying brocade switches on your access layer instead of cisco for example, no big deal. Core / MPLS switches, another issue altogether. (In Brocade's defence I've seen cost/performance figures up to 50% better than comparable ASRs so yes it can make sense LOL). Ditto for changing firewall vendors.

You know... reading this... I gotta say this sounds a little lazy (Minus the support part - that's spot-on).

So you're saying you wouldn't go for an overall 20% improvement in performance simply because you'd have to learn something new?  Isn't that part of working in IT?  I mean I get the reality and all... but in my mind I'd say a little growing pain (which should be minimal if you have the right people with the right mindset) is well worth a 20% permanent improvement to the network.  You should always welcome a new challenge and improve your skill set!  But I guess that's why I would never be a CTO...

I'll take that comment in the nicest possible manner (but it would be nice if you bear in mind the non-cisco alphabet soups next to my handle and my constant skepticism of any Cisco non-R&S product). You're missing the point entirely - I'm speaking from the POV of management which deanwebb has covered off nicely.

You need to take off your vendor SE / telco / military hat and look at it with an enterprise POV with their harried in-house team of what, typically 2-3 guys (1 if mid market) who already have a major skills gap compared to consultants/SE/PS engineers. How much is it going to take to upskill them? And critically how much use are you going to get out of those skills? And how much extra are you paying for PS every time something remotely major needs to happen? What's taking that engineer out of the firing line for a week worth? then say add an extra week of man hours lost a year due to unfamiliarity. See it all adding up. And again, can you quantify how many dollars this '20% better' is going to make for the enterprise?

The 20% figure is plucked out of the air but lets go with that. Typically I'm referring to replacing one component (or set of components) - how does a 20% more throughput edge firewall improve the network performance by 20%? And a lot of the time, esp. in enterprise, they are not using anywhere near the capacity of their products. What's 20% more throughput going to help the business in everyday terms on their access switching or a nowhere near loaded firewall? (of course if there's a must-have feature then that's an auto deal-maker or breaker but that's a different question). Let me spin this around: buying existing vendor C (lol) will give you capacity of 100, buying vendor X will give you capacity 120 - but guess what, your maximum anticipated usage is 80. What's the extra 20 doing for your bottom line? nothing.

Finally remember that the network is an afterthought to most enterprises. They want the least disruption, the least change, the lowest opex and lowest capex. Nobody blinks an eyelid when replacing like for like so politically there is zero risk. New vendor? Its on your head..... so how many conservative managers want to make that risk? What plaudits do they gain by putting in something that's got 20% better throughput? Harsh but that's the reality. Then of course to put in the new vendor product, its new change (at least) or project (normal) or program of works (eek!). Who's paying for all this disruption? There is a ton of political conservatism and inertia. These aren't necessarily good reasons-  but they're there nonetheless, and is it worth your political capital/time to push this particular wheelbarrow uphill? For a minor performance gain I would probably lean on the side of no. Again, I'm not talking about a killer or required feature, I'm talking about marginal gains.

I've been through this discussion many a time when I was in-house and pushing for something different. Why are we still deploying 8XXs instead of SRXs? Why are we paying for ACS when I could just spin up FreeRadius? Why don't we replace all those expensive 3750Xs with Brocades, then I can stop begging you for IP Services licenses? etc. and I lost that plenty of times due to the management reasons deanwebb sprouted off quite readily. I don't always agree with it but I've heard those arguments enough times from managers who weren't all stupid (and including one or two pretty damned good managers actually) to realise that there is a kernel of truth in there.

And don't discount the hiring question. Maybe you have it easier in the US but here in Oz its difficult enough to get good normal network engineers (and by that you basically assume at least a CCNP level of knowledge on Cisco products). Have you ever tried to hire a good Juniper guy? Now drill down to a more obscure vendor. See where I'm going with this.... this applies also to getting contractors and/or adhoc resources.

Anyhow just pointing out there are a myriad of (possibly good) reasons from a management POV why you wouldn't just buy a competitor's product that is better on paper and cheaper. In my line of work, I see this ALL the time and believe me its in my company's interests to push for a change (since then win the professional services gig designing and implementing, and basically every vendor has a better margin in it for us than Cisco... as our director says, there are 19 Cisco gold partners in our city alone, why chase the same dollar bill as them)

Wow.  So.... I wrote a post to apologize, and then realized I was still missing the point so I deleted it.  Suffice to say, I apologize for getting snarky there and for my failure of reading comprehension. Also, as I stated in other posts, it's very easy for me to say and think how I feel as an armchair quarterback when I'm not in your real-world shoes. /respect

[deanwebb]

On the other side, corporate horror stories carry a lot of weight. Nobody wants to be the guy that signed off on something that later resulted in a massive outage. If the outage *could* happen, meh, that's why we hire engineers. But...

"My buddy over at Big Company put this product in as their solution and it shut down an entire production line for a week."

You better believe that calls will be made to corroborate that info and the vendor will have a very rough meeting with the higher-ups at Your Company.

"I know a guy that used to work at Major Firm and he said they put this in and ripped it all out after a two years and millions in professional services when not even the vendor could get it to work as advertised."

Again, that's a huge, career-limiting risk. It's one thing if I have to hire people with moar skillz, it's quite another when the vendor and his gold partners can't get it up and running. Calls will be made, meetings will be booked.

Part of what I have to do in making a product recommendation is to put out feelers and find out who else is using it and what they think of it or what their experiences have been with it. Stuff like, "Works fine on 100 meg or 1 gig, but forget about 10 gig and this product," make for good information on how this stuff flies outside of a proof of concept demo.

To that end, we have a policy of doing a live PoC, with our engineers flipping all the toggle switches and stuff. Don't show me what this does on a pre-fab lab setup. We want to hook it up to our own ugly gear and see what kind of trouble we can get into. Phrases like, "Oh, you need a license upgrade on your switch" or "that sup card's not supported" or "we need to stand up another VM for that function" from the vendor can give us a better idea of the slog ahead and which product *really will* be the one to go with.

Ease of implementation is a huge factor. If a strategically-shaved monkey can get basic functionality out of the product because the GUI is intuitive, we got us a winner, here. If it's got a CLI-only interface that requires a Mandarin Chinese keyboard layout to work with... well, see ya! As a manager, I would feel tons better about a product that may require that week-long course for deeper knowledge, but that could be worked on by people with no experience after a short ramp-up.

Ease of implementation also appeals to the project manager. That dude wants zero overruns in budget or timetable. Comments like, "slick GUI", "fun to work with", "hopped right on the network and got to working right away," really help them to feel good about a product. Maybe the budget could be massaged with fewer man-hours of implementation assigned, with that money shifted over to capex for the higher-quality vendor?

As for the engineers that disparage the GUI... you're forgetting the Level 1 helpdesk dudes that don't know their DOS from a DoS. They *need* graphical utilities in order to be functional.  You're also forgetting that managers like pie charts with colors on them. Those colored pies need to be easy to find and generate, or those managers' eyes are going to glaze over as you show them debug outputs.

[NetworkGroover]

On the other side, corporate horror stories carry a lot of weight. Nobody wants to be the guy that signed off on something that later resulted in a massive outage. If the outage *could* happen, meh, that's why we hire engineers. But...

"My buddy over at Big Company put this product in as their solution and it shut down an entire production line for a week."

You better believe that calls will be made to corroborate that info and the vendor will have a very rough meeting with the higher-ups at Your Company.

"I know a guy that used to work at Major Firm and he said they put this in and ripped it all out after a two years and millions in professional services when not even the vendor could get it to work as advertised."

Again, that's a huge, career-limiting risk. It's one thing if I have to hire people with moar skillz, it's quite another when the vendor and his gold partners can't get it up and running. Calls will be made, meetings will be booked.

Part of what I have to do in making a product recommendation is to put out feelers and find out who else is using it and what they think of it or what their experiences have been with it. Stuff like, "Works fine on 100 meg or 1 gig, but forget about 10 gig and this product," make for good information on how this stuff flies outside of a proof of concept demo.

To that end, we have a policy of doing a live PoC, with our engineers flipping all the toggle switches and stuff. Don't show me what this does on a pre-fab lab setup. We want to hook it up to our own ugly gear and see what kind of trouble we can get into. Phrases like, "Oh, you need a license upgrade on your switch" or "that sup card's not supported" or "we need to stand up another VM for that function" from the vendor can give us a better idea of the slog ahead and which product *really will* be the one to go with.

Ease of implementation is a huge factor. If a strategically-shaved monkey can get basic functionality out of the product because the GUI is intuitive, we got us a winner, here. If it's got a CLI-only interface that requires a Mandarin Chinese keyboard layout to work with... well, see ya! As a manager, I would feel tons better about a product that may require that week-long course for deeper knowledge, but that could be worked on by people with no experience after a short ramp-up.

Ease of implementation also appeals to the project manager. That dude wants zero overruns in budget or timetable. Comments like, "slick GUI", "fun to work with", "hopped right on the network and got to working right away," really help them to feel good about a product. Maybe the budget could be massaged with fewer man-hours of implementation assigned, with that money shifted over to capex for the higher-quality vendor?

As for the engineers that disparage the GUI... you're forgetting the Level 1 helpdesk dudes that don't know their DOS from a DoS. They *need* graphical utilities in order to be functional.  You're also forgetting that managers like pie charts with colors on them. Those colored pies need to be easy to find and generate, or those managers' eyes are going to glaze over as you show them debug outputs.

Haha some very good points here. 

About doing a live PoC... yes.. yes.. yes.. yes!!!  I LOATHE when a product evaluation is only, "Do you support X, Y, and Z feature?".  Sure it's important, but you also need to performance test, and keep the vendors honest.  Ixia/Spirent has a way of doing that.  I'll never forget slapping 10Gb transceivers into a Juniper Netscreen and watching the SCREAMING 1.xGb performance we were getting according to Ixia.  That was my first lesson in ASIC channel polarization (A single point-to-point VPN only uses a single channel in the ASIC, and it's limited to 1.xGb, at least that's what the Resident SE told me) - something you never read about (that I've noticed) in traditional studies.  Everyone's perfect according to their data sheets - put em to the test!  You also get a real eye-opener on just how "easy" to implement a solution actually is, as you stated.

I remember when I used to knock on GUIs.... then I remember using Arista's TapAgg Manager GUI to configure a traffic steering policy with 10% of the effort it takes to type it all out in the CLI.  That and c'mon... when you start managing tens and hundreds of devices... the more time you can save the better, I'm sure.  The CLI is still king for troubleshooting though - no doubt.