Dealing With The Vendor End-Around

In his recent blog, Mike Workman, CEO of Pillar Data Systems, offers an example of what is commonly called the "end-around." This is when a larger vendor will leverage a relationship at the VP or CxO level to stop a lower level person from selecting a more innovative product from a new and smaller vendor. Instead of getting stung by this tactic, there are steps that you can take as the IT Manager, project manager or even the evaluator to keep it from happening.

George Crump

September 20, 2010

4 Min Read
Network Computing logo

In his recent blog, Mike Workman, CEO of Pillar Data Systems, offers an example of what is commonly called the "end-around."  This is when a larger vendor will leverage a relationship at the VP or CxO level to stop a lower level person from selecting a more innovative product from a new and smaller vendor. Instead of getting stung by this tactic, there are steps that you can take as the IT Manager, project manager or even the evaluator to keep it from happening.

The first step is to see if it even makes sense to include newer vendors in the evaluation or review. Before you start the project, ask people in the management chain if you are allowed to include newer, potentially more innovative and less expensive vendors. If the answer comes back no, at least you know up front and you won't waste your time or the newer vendor's time. Often the answer will come back as a yes. We suggest getting as many details as possible to answer that yes. How new? How innovative?

With that approval in hand, the next step is to go as far up the management chain as possible and let them know that if you review and select a newer vendor, that the end-around is likely coming. Defuse the bomb before it gets there. Don't assume because it has happened before that the people above you will know about it. Tell them that if you actually do select one of these newer vendors, that they will likely be getting a call inviting them to lunch, dinner, golf or some sporting event. Get agreement that they won't take these meetings or discuss these projects until you can provide them with information as to why you are recommending the newer vendor. Also get agreement upfront that if the project team finds that a product from an new vendor that upper management won't be swayed and force you to re-review.

After that, of course, run through your normal process, treating all vendors fairly. If through your testing and business evaluation process you determine that a product from a newer, lesser-known vendor makes the most sense for your organization, prepare for the end-around. The end-around attack strategy typically focuses a little on technology but mostly on business viability and service/support.

The technology attack is often something like, "Well we can't do XYZ feature yet or not without a huge performance impact, and you don't want to put your data/network at risk do you?" The big guys basically assume if they can't do it no one else can, despite irrefutable evidence to the contrary, including your own testing. We suggest arming your senior management with these details, just in case they do happen to meet with the larger vendor. Let them know, "here is what the vendor is going to say vs. here is what we found." If your senior managers are not armed with the facts ahead of time, their only option is to believe what they are told by the more established vendor.

The business viability and serviceability attack is typically "Those guys are too new." Make sure you define what "new" is. For most vendors, too new is any company that is newer than them. Being publicly traded is not an indicator of how stable a company is. I've seen a company called "too new" even when they have been in business for 5+ years. If you select a real start-up, say less than two years old, prepare your senior management with the facts. Admit there are risks but also explain what the payoff is. There is risk in any IT decision. You can't change reality, but you can remind them of the initial conversation that newer companies were okay to explore.

Finally, discuss serviceability. I am not impressed by large service and support organizations. It makes me wonder if the product is overly complex or fragile. Certainly you want some people there, but it should be as a percentage of the installed based and the frequency of service calls. A company that builds a better product, that is easier to operate and maintain shouldn't need a large service organization, especially when you factor in install base. As before, address those points and feed them to senior management prior to them taking any meetings.

The vendor end-around can't always be stopped, but it can be prepared for. It takes work on your part, though. Let or remind senior management that it is coming. Provide them with a short, very short, summary of why you made the selection. While everyone will be impressed with your formal write-up, very few will read it cover to cover. In that summary, address the key points that you expect the end-around move to challenge. 

About the Author(s)

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox
More Insights