Leadership

Four strategies for dealing with vendors that don't talk to consultants

Are you dealing with a vendor that won't talk to you? If so, Chip Camden explains that understanding why a vendor may be keeping mum can be the key to figuring out how to handle the situation.

 As a vendor to your client, sometimes your relationship with your client's other vendors can become strained -- and even hostile.

TechRepublic member mothershelper sent me an e-mail describing her troubles with a vendor that wanted nothing to do with consultants. The vendor provided her client with a custom hardware/software solution that was overpriced and underengineered. The software was sold as is, and the support contract becomes nullified if the user modifies the code. Thus, the customer is locked in to using only that vendor for any corrections or enhancements unless they're willing to go off of support. To add insult to injury, the support contract included a "free" software upgrade that won't run correctly on the client's "outdated" server without some modifications. When mothershelper contacted the vendor's support line to figure out what was wrong, she was told "We don't deal with consultants."

Mothershelper would like a little help:

"Anyway -- if you or others have run into something like this, I'd like to read about it and see how you handled it and how it turned out. Me? Right now I am plowing through thousands of pages of manuals and hundreds of files, backing up everything in sight, and performing PC necromancy when I have to in order to keep them going until I am certain I can get them on to new hardware and into new software without losing a day's work or their entire database."

I've certainly run into the same sort of situation. It gets particularly frustrating when the vendor is a largish company, and the only people you can talk to are just following orders and have no idea why the policies that they must enforce are in place. If you can talk to somebody with authority, it's helpful to understand their possible motivations in order to get them to see your side. Here are four possible motivations of vendors, as well as strategies for dealing with each one.

Supportability

The vendor's primary motivation for wanting to control everything may be to avoid supporting code they didn't write; this is a legitimate concern for any software vendor. Even custom modifications (and third-party customizations) that the vendor makes can snowball into a support nightmare.

Your strategy: Try to form an alliance to help their customer within their prescribed bounds of supportability. For instance, you might try to get the vendor to stretch its support guidelines a bit (with proper separation of concerns and documentation).

Revenue stream

Maybe they really are the big, bad wolf that wants all the little piggies for themselves.

Your strategy: Make it clear that you're an agent of their customer and not a competitor. You're not trying to take business away from them -- you're just trying to solve the client's problem. You'll gladly let the vendor make the modifications if they insist, but they need to act now to save the customer. If the vendor can't step up to the plate, maybe you could fill in for them, under their direction.

FUD (Fear, Uncertainty, and Doubt)

Nobody in the organization really has a clue about how to do business, so they have rigid rules to make them feel safer.

Your strategy: You have to be a really good talker. Reassure the vendor that you can help their customer without introducing any risks to them. Ask them (politely) what their (don't swear here) motivations are for their (don't swear here either) policies. Try to talk them through that thought process and calmly pose a solution or qualification to each pseudo-objection they raise.

Something to hide

The vendor secretly knows its product sucks, but they put on the Industry Standard Enterprise Solution act to cover that fact. They enjoy telling you that you couldn't possibly make the corrections successfully yourself because it's far too complex a system to learn in one lifetime. They don't want you to even look at their code because, unless they did a really good job of snowing you with their market speak, you'll see through their BS right away.

Your strategy: My best advice is to run away and leave the vendor alone to enjoy the grandeur of their huge pile of spaghetti code.

What to do if your client stays with the vendor 

If your client stays with this vendor, your contributions will be hobbled, so don't overpromise what you can solve. If the vendor is too nasty, you might want to counsel the client to leave them behind -- perhaps you could take over maintenance of the system (first, make sure that you're up to the task and that you want to do the work). Or, you could suggest a different vendor; conversions can be a nightmare, but if the new vendor is a lot easier to work with, a few months of pain could well be worth it in the long run.

Share your vendor horror stories

Do you have any horror stories of dealing with exclusive vendors? If so, how did you deal with them and what was the result? Can you think of reasons other than the four I listed in this article why vendors might be reticent to talk to consultants? Post them in the discussion.

---------------------------------------------------------------------------------------

Get weekly consulting tips in your Inbox TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

35 comments
nat_z_15
nat_z_15

i think i am the ruler of the world

herlizness
herlizness

I see only one approach to this situation: request your client to inform the vendor that you are acting on their behalf and they are expecting full cooperation. This can be stated in very civil terms, orally or in writing. If you can't get this from the client, I personally think the situation is futile or close to it. The decision then is to continue to waste time and get paid or to move on. If the client so informs the vendor but the vendor continues to withhold cooperation, I would advise the client to drop the vendor and take it from there.

The_3rd_Bit
The_3rd_Bit

I was involved in a situation where I was representing the Vendor. The distributed application we developed was running smoothly for more than a year, but then my customer went and added other systems to their network which we had no visibility, and neither could tell how it would affect our application's behavior. Ultimately the changes to the Network did affect our product. The Client went and hired a consultant to help figure out 'Who's fault the problem was?' - as I remember upper management seeing how the client wanted to charge us for our service. If only they would have changed their attitude to 'What causes the problem?' and focus on team work to resolve the problem, I believe it would have worked out much better.

cloudnavigator
cloudnavigator

I can't argue with your strategies...they sound pretty good. I always identify myself as working for the client and use the client's name when contacting a vendor for support. If the vendor is hesitant I put the client on the phone and have her inform the vendor that I've been retained to help with the "problem" or "upgrade" or whatever it is that needs to be done. I do not write code so the conversation never gets to that level with me. If the client winds up receiving no satisfaction from the vendor in terms of support, I will let the client know that I'm willing to help them find a replacement for whatever poorly or inadequately supported product they are stuck with. I've been working in IT on the reseller channel side for over 20 years and I rarely see any flat-out refusal to deal with me when I'm working on a client's behalf, especially if the client is paying for an annual support contract with the vendor. In fact, 9 times out of 10 the vendor is usually glad to have someone on the line who is "technically literate" and can give them accurate information and can implement their recommendation(s). Tim Wessels

mknibbs
mknibbs

I have faced similar problems with software vendors in dealing with proposed changes to their product. Many are acting in good faith - not wanting to support code that they did not develop and test. I have found that offering all amendments, patches and new functions developed by IT (or consultants) to the vendor for inclusion in future base product releases to be an effective win-win. They get a better and more stable product and you get vendor support going forward. All bets are off if the vendor is a 'bottom-dweller', in this circumstance they are going to hide behind any excuse not to meet quality and service standards.

pgit
pgit

Fortunately I have excellent relations with almost all other vendors, save one. This is a new client, I consulted with them and of course they brought me up to speed on their setup. (Windows server 2003 and this one, huge proprietary app) I was stunned when they started asking me my opinion of Linux, and did I ave any experience with it! (sha! like 10 years!) They were sick of their vendor constantly "upgrading" them out of their perfectly functional hardware. The company had recently told them they'd soon have to migrate to vista and possibly even server 2008. The owner started off on a rant about "no way we're going to buy vista..." while all the other employees sat there nodding in agreement. I called the vendor and was told flat out they would only talk to me to walk me through their application while on site. I did get out a question as to continued XP support and they said "we" (the client) would just have to move on...

derek
derek

We have a very simple solution when that problem comes up. Our relationship with that client is that we are their outsourced IT department. But we are STILL their IT department. When I am working with a vendor I am admittedly either an employee or an outside consultant depending upon which story suited the client's interest. I have no problem representing myself, or expecting to be treated as an employee even if it is "employee with an astrix." I think the real problem is that the client got shoehorned into a solution that tied their wrists. . .a common problem with proprietary programs. If someone has a solution to not getting extorted by software companies I would love to hear that.

Sterling chip Camden
Sterling chip Camden

... that you were a consultant. The most the vendor needs to know is that you work for their client.

Sterling chip Camden
Sterling chip Camden

After initial resistance, the company not only accepted the new code but established a symbiotic relationship for enhancing their product into the future. But it does take an organization that can be honest and open with itself and its customers.

JohnMcGrew
JohnMcGrew

...to another vendor. Sheesh. I wish I knew where I had this, but I recall Microsoft's pitch to developers back in the early '90s that Windows was supposed to be a "write once, run forever" kind of environment. I guess that was before they discovered the revenue stream in CALs.

Sterling chip Camden
Sterling chip Camden

Or as my buddy Stu Savory likes to call it, "Fister". I haven't heard of any software vendor requiring an upgrade to Vista yet -- that seems like a recipe for mass exodus.

pwoodctfl
pwoodctfl

Where is your customer in all of this? They should be backing you up. It is their problem that you are trying to fix. Here is my three step plan for a resolution to this stalemate: 1 . Meet with your customer and have them appoint and "in house" liason to interact with the vendor. Relay your questions through that liason or be in on the conference call. 2. Find out your customer's intentions for this product. If they are generally happy with it and/or are in a long term contract, figure out whether you are making enough on this contract to make up for the extra time needed to work around this problem, if not, reconsider your commitment to making this situation worse. 3. If this is a long term commitment to the vendor and you are generally happy with your assignment, work with your client to establish a rapport with the vendor. Once you are on the conference call 8 or 10 times, they will know that the customer has confidence in you and you are their agent. At that point, you can begin to call the vendor with "follow up" questions from the conference call which can slowly migrate into new topics under the guise of "while I have you on the phone".... It is a silly game, but it works...

elgeebar
elgeebar

I've been in this situation before and found that an out right lie to the vendor gets results! What I mean is (with the clients permission) pretend to be them. Write emails to the vendor asking the nitty gritty questions and get the client to send them on your behalf (or even get the client to set you up an email address so you can do it yourself). In the past, I've sent stuff to vendors as a clients Sysadmin, IT Manager and even IT Director. I've even got on the phone and done it (sat next to the guy in their own office though). It usually gets results, because they think they are now dealing with a customer who is now asking the right (from the vendors point of view, wrong) questions and they start to see all that support ?$ going down the pan unless they act quickly to resolve the issue.

mothershelper
mothershelper

considering what I found on the server we tried the 'employee' with asterik first it would be humorous if I really were just a new employee and they labeled me 'consultant' just the same as it is they're stalling - not a priority to answer anybody's questions since nothing is planned for right away right? *sigh* it's such a mess

herlizness
herlizness

in some cases that might be ok ... but look, how crazy is this kind of stuff going to get? I either have authority to do work or I don't; now I have to pretend to be an employee when I am not an employee? Personally, if I were the one who'd hired the vendor I'd tell them to work with my designees or be gone. When I give someone authority to do work on behalf of me or my company, in legal effect, they ARE me or my company. There comes a point where people have really do have to start behaving like adults. If there is a legitimate problem working with someone, the vendor needs to address it promptly and forthrightly. I'm just baffled by this stuff; when I'm wearing my lawyer's hat, I have no such problems ... acting on behalf of a client, if I notice someone for a deposition or send a demand letter, I've yet to have someone fail to respond or to even think about questioning my authority to act on behalf of that client. Why should it be any different for a consultant?

pgit
pgit

I remember a long while back a boss told me writing a letter to the president of a company is one of the best ways to get satisfaction. I didn't believe it, but I bet he was right. I should have this client write to them, all the suggested offices as a cc, sales, supports etc... We shall see what transpires. BTW there are alternatives to this software and they have an employee evaluating them as we speak. Smart people.

Sterling chip Camden
Sterling chip Camden

None of my clients has had any trouble with compatibility on XP if they write to run on Vista. The other way around is a different story, with all of the issues with required privileges and such. I wonder if this vendor is just trying to simplify their supportability by trying to isolate to one environment.

Robbi_IA
Robbi_IA

I don't know about vendors for commercial apps, but it's happening with government apps. An Illinois government organization has purchased and is preparing to upgrade their systems to a new app that only runs on Vista machines. One of our departments is tied into this organization and must upgrade to Vista by fall 2009. We run XP on all of our workstations currently, and were hoping that when XP support faded, we could move to Suse Linux Enterprise Desktop. But with all of our departments tied into various state and federal government entities, that will never happen.

pgit
pgit

...that's good. oh, savory.de didn't get me anywhere. BTW I have got to believe the app will run on XP into the future. But.. I can't confirm (because I can't talk to them, they're oh-so busy) but I believe what they were telling me is sometime in the near future they will only provide support if the customer is running vista. It's a support, not an OS compatibility issue. Unfortunately this thing is a heap of spaghetti that guarantees you're going to need support. O-T has everyone seen this? http://www.thewebsiteisdown.com/

Troy Wilkinson
Troy Wilkinson

This seems unbelievable, though I'm sure there are developers that are this unscrupulous. I have not heard of a forced migration to Vista from any vendors, yet. Unless this is a franchise with no choice but to stick with the vendor I would say it MAY be time to get out ASAP! I would be cautious about a move to Linux as well. There are plenty of vendors for most any application with more reasonable requirements then is suggested here.

Axl_Furneaux
Axl_Furneaux

When it comes to Vendors, in my experience they tend to fall into 2 camps; particularly when they are relatively small organisations. Often when they get larger, the need to "use" consultants to market and push their products over-rides thier desire to keep them at arms length. However, in the smaller bracket, the desire to keep their "cards close to their chest" over-rides this collaboratvie aprroach. I have experienced this several times in the past and by far the best approach I have found is as follows; 1. Look at the application/system from a client's perspective first and foremost. What is it actually achieving for them and is it unique in the marketplace? 2. Assuming it isn't (I have always found something which competes), then you have the chance to make an ROI case on the current product compared to others. Do not over-egg competitors, but focus on the current problems you are experiencing and liaise with other vendors - if nothing else to make sure that you are not jumping from one fire into another oone. 3. Once you have some reasonable data, sit down with the key stakeholder for the current system - typically this will be a business manager or Director. Clearly lay out the issues you are experiencing, ideally in terms of financial cost (upgrading servers and the like costs lots of money, so make sure you highlight this), and the potential advantage of migrating to a more amenable vendor. 4. Discuss the option of running a pilot with a new vendor to ensure that it covers all the "must have" features and functionality - you never know it might even be better than your current one. I have generally found that stroppy vendors have something to hide and performance is often the main one! 5. Once you can prove that the old system is not irreplaceable, you are in a significantly stronger position and might even get some push-back from the current vendor - get the key stakeholder to make a call to the vendor highlighting your pilot - it is amzing what a reaction you get at that point!

Sterling chip Camden
Sterling chip Camden

... the "we don't talk to consultants" should be translated "we don't want to talk to this customer at all, and you just gave us an excuse by calling yourself a consultant."

Sterling chip Camden
Sterling chip Camden

The reluctance of software vendors to work for a client has nothing to do with the consultant's legal status as a representative of the customer, IMO. It's juts one more thing a clueless support rep can grasp onto to get out of providing any meaningful support. Plus, they don't want to get shown up by the consultant, who probably knows a lot more about the system than the support rep does.

pgit
pgit

I called to suggest this client inform the vendor (in writing) that they are testing replacement software and the reason is this "we support Vista only" move coming at some indeterminate time. (they haven't named a date yet) This same Vendor forced their move to XP back when, but they are happy with XP so why migrate? I was told they were already planning to do so, but they thanked me for the suggestion. So thanks for the ideas, if nothing else it made me look good to this new client...

Sterling chip Camden
Sterling chip Camden

Yes, the more you can put the vendor in the position of potentially losing your business, the more cooperation you'll get from them -- generally.

Sterling chip Camden
Sterling chip Camden

I've seen a lot of software companies that force their users to upgrade to their latest "Vista-ready" version if the user needs to be on Vista, but not the other way around. Many are having to go that route anyway, though, because new systems are coming with Vista pre-installed.

Sterling chip Camden
Sterling chip Camden

Yes, especially direct your attention to whomever in the organization has part of their remuneration tied to keeping customers. In many software companies it's the VP of Sales.

tom.marsh
tom.marsh

You should ask the customer to escalate--and I don't mean "I'd like to speak to the manager" I mean write a LETTER on the customer's letterhead, signed by their CEO/President/Owner/Bigwig of Choice that basically says "Your policy of not supporting Windows XP after this date conflicts with our business goal of avoiding the mantrap that is Vista. Therefore, we have begun the process of replacing your product and will stop paying for it and for support as of the date you suspend support for Windows XP. Thanks for your partnership over the years, sorry to see it end." You need to send this to the VP of Sales, VP of Support, and President/CEO/CFO/Financially responsible parties in that organization. Leverage their executives to your benefit: If they see that an unreasonable support policy is going to cost them money, there will be pressure brought to bear internally to change it. Of course, this is a threat you need to be able to make-good on... If they're the only vendor on earth that does this function, that won't work...

Troy Wilkinson
Troy Wilkinson

I am not referring to reliability or security. In these areas I would push Linux as a choice. I say be cautious due to the level of support that can be provided to the client. If they don't have a Linux Admin on staff the recommendation of a Linux solution may be a dangerous one to the consultant recommending it.

mothershelper
mothershelper

It could be the client isn't all that tech savvy - there's been a few I would have loved to put on linux that curled up in their chairs in horror and won't even look at the idea. I pushed linux and won once to a company that didn't have anyone onstaff with a clue. Every time the server burps I get a panic call - for what's turned out to be nothing. That is SO not how I want to keep them coming back. and don't throw cookies at me for this... You could try the Xandros line - it's commercial enough to put some peace of mind in play, looks close enough to Windows that it won't scare them but it's still Linux. Between that and the smaller pricetag they might go with it.

Sterling chip Camden
Sterling chip Camden

Why would you be cautious about Linux? Unless there are other Windows-only apps that the client requires, I don't see how Linux is any less reliable or secure than Windows.

Sterling chip Camden
Sterling chip Camden

Especially the bit about the pilot test. Even if you were certain about converting, it's always a good idea to run in parallel for a full cycle before you switch over, just to make sure there are no gotchas.