Preventing Vendors From Playing The Blame Game

The blame game, with its finger-pointing and mutual buck-passing, is a familiar feature of politics and organizational life, and blame avoidance pervades government and public organizations at every level. The frustrations of dealing with organizations whose procedures seem to ensure that no one is responsible for anything are way too typical to be accidental.  See Bureaucratic avoidance of responsibility

Vendor blame game is the trick used by software and hardware vendors to avoid responsibility for the problem. It is just a finger pointing to other vendor instead of researching and solving the problem.

And contrary to common misconception getting everything from a single vendor limits, but does not completely prevent finger pointing. For example instead of Oracle blaming Sun, you'll have the websphere group blaming the DB2 group who blames the AIX group within IBM. Unless you're a really big IBM or Sun or HP customer forget about getting a more or less complex problem resolved in a reasonable amount of time.

Even with the best selection of vendors, you cannot escape a certain amount of "not my problem; it's him" finger pointing. The reason is simple; when something breaks, you are not dealing with a hive-mentality supplier where everyone in that company knows everything about the company's products. You will be dealing with individuals. And usually, the first person dispatched on a problem call is the lowest-ranked, -paid, and trained. And as they can't resolve the problem and are vary to escalate it, they will resort to finger-pointing instead of calling their next level support.  This is just a question of priorities...

NEWS CONTENTS

• 20000729 : Preventing Vendors From Playing The Blame Game ( Slashdot )

Old News ;-)

[Jul 29, 2000] Preventing Vendors From Playing The Blame Game

Several insightful posts about AIX, Websphere, etc.

Slashdot

smoon (16873)

My company did the same thing last year. We ended up going with AIX, DB2, and Websphere. _BAD_ choice. We've since switched a lot of what we'd hoped to use, and the RS/6000 for to a different platform.

The AIX has been OK, but IBM doesn't seem to know their own hardware/software very well. We've tried to order some performance monitoring software and were sent the wrong CD (three times and counting). When we discussed our performance problems (definitely not IBM-related) the senior technical person had 'never heard' of a configuration like ours (internal SSA disks). When trying to buy an extra hard drive we were promised Monday delivery. On Thursday we get a call asking for more detailed information so they can ship the right drive (even though there is only one possible drive to ship for that model/capacity).

DB2 is not a bad database, but good luck finding

• A: any software that _really_ supports it, and
• B: any DBA that can support it -- there are lots of Mainframe guys out there, but mainframe DB2 is a bit different than DB2 'UDB'. Enjoy the 1-2 books out there.

For my part I would heartily recommend looking _really_hard_ at Oracle, MS SQL server, Sybase, DB2, et. al. and verify you can: get a DBA, can find developers familiar with the database (DB2 is different enought you don't just develop and pretend it's 'any' database), and that any future software you might use supports the database.

As far as 'no finger pointing' -- getting everything from IBM does nothing to prevent finger pointing. Instead of Oracle blaming Sun who blames BEA, you'll have the websphere group blaming the DB2 group who blames the AIX group within IBM. Unless you're a really big IBM customer (read: have a mainframe or two) forget about getting it resolved instantly.

homebru (57152)

Even with the best selection of vendors, you cannot escape a certain amount of "not my problem; it's him" finger pointing. The reason is simple; when something breaks, you are not dealing with a hive-mentality supplier where everyone in that company knows everything about the company's products. You will be dealing with individuals. And usually, the first person dispatched on a problem call is the lowest-ranked, -paid, and -trained. And a large percentage of such, if they can't resolve the problem, will resort to finger-pointing instead of calling their next level support.

As suggested elsewhere, you (or someone in your shop) will need to be learn enough about the entire installation that you can tell when someone is pouring lemonade in your ear and saying it's rainwater. Don't just give some surplus manager the title of "Architect" and let it go. Find a techie who knows how to back off and observe.

Other suggestions:

Getting reps from all suppliers in the same room is a good idea, but not generally possible until you have been down much longer than you want.

Don't be afraid to "escalate" the problem. If the first response body can't / won't solve the problem, ask for a manager. Managers don't like talking to customers, but the good ones like even less having unhappy customers because of untrained employees or employee attitude. Odds are that the manager may not even know about your problem (other than "there was a ticket but we closed it").

If you find a support rep who really knows her stuff, saying "thank you" never hurts. (Lots of customers think it does.) For a really good job, a note to the salesman (to be forwarded to the support boss) will be appreciated.

Sometimes, it is possible to request that a particular support rep be assigned to your account. If you find a good one, do so.

Bottom line: support reps from the suppliers are not your employees and so do not care quite as much about your company's problems as you do. Since you cannot completely avoid getting involved in problem resolution, get trained. Get multiple people trained.

Wellspring (111524)

Unfortunately, there is no way of avoiding finger-pointing. As others have pointed out, if you go and get a single big vendor, they will keep bouncing you between project groups, who will keep remarking on what a fascinating problem you have or what a strange/nonstandard setup you have.

The best ways to get a problem fixed in a hurry is to keep escalating it. You don't want to be a 'problem customer', but it sounds like you are pumping plenty of moolah into this, so they won't be able to just brush you off.

Ultimately, picking a single vendor will better avoid the fingerpointing between unrelated service techs because you can always find someone who is superior to both of them. But if you pick an inferior system, you'll have to make more service calls.

If it is onsite service, throw a 'tea party'. Get all the techs from each software package which has been blamed, and say that none of them can leave until the problem is fixed. I've had three weeks of back and forth end in two hours that way-- usually the tech isn't going through his whole routine and so is missing something. Once he is in that environment, he will have to do everything, even the stuff he thinks he doesn't have to do.

I guess my answer to your question is to thoroughly explore interoperability before you buy, but then get the best stuff with the best service-- without trying to find the one company for everything. Make sure interoperability is explored before you buy, so the sales reps won't weasel out of it later.

pete-classic (75983)

I have just gotten out of tech support, so let me shed a little light from that perspective.

What you have to do to avoid finger pointing is ISOLATE the problem BEFORE you call.

For example, you have a problem with the tape drive on your RS\6000, using some non-IBM tape backup software. BEFORE you pick up the phone, try tar. Now you know who to call. Since it is IBM's tape, in IBM's system, with IBM's tar it is IBM's problem if it doesn't work. OTOH, if it works, when you call your backup (or DB) vendor and tell them their software is goofy. If (when) they try to point at IBM you tell them, "Hmm, works with tar."

See?

Again, from a tech support guys point of view, this is YOUR JOB. Using a single vendor makes your job easier, because you don't have to figure out who to call. But it is not the tech support guys fault if you just call the vendor who's product is exhibiting the SYMPTOM, if it is not the component that actually has the PROBLEM. You will be the victim of finger pointing as long as you don't believe it is your responsibility to isolate the problem before you pick up the phone.

Please don't interpret that last paragraph as "finger pointing is the customers fault." It is not. The vendor should say "It is possible, or even likely that the problem is in fooware. Here is how we can make sure our product, barsoft, is working correctly." Bad support techs don't do this. (Actually, this is a management problem, but that's another thread.)

The point is sometimes you will get bad tech support. Doing your homework is how you avoid finger pointing.

Stinking Pig (45860)

Hear hear -- I'm level three installation support at a company which makes a complex networking software product, which is necessarily dependent on a bunch of other complex software products and operating systems. The methods described above are the difference between a support "issue" (opened and closed with a minimum of bleeding) and a support nightmare (massive cranial bloodloss for all parties concerned).

You are dealing with individuals -- people who may have a multistate territory, people who might or might not have been well-trained, people who might or might not have natural aptitude for their job. They'll do a lot better if you gently steer them toward the problem and help them be calm and logical about it.

Support people, especially field support, see the worst side of their customers and the products they support. They might secretly (or not so) think that you are a moron and the product they support is a buggy POS. If you're being unpleasant, they'll act to get you off of their desk quickly, which means run through the flowchart looking for interaction with other products. As soon as interaction is found, they'll tell you to go double check it and hope that you call back after their shift is over.

martyb (196687)

It would be simple, if you (or your staff), knew ALL the ins and outs of ALL these parts. In the real world, this is not likely to happen. But, if you can isolate a problem down to being NOT in two out of those three, then it looks pretty likely that it would have to lie in what's left. Hence "know what you don't know." That is, know what areas you are weak, and what areas you are strong. Use that to your advantage in trying to sort things out.

Often, in my experience, have I found myself going down the debugging path in frustration until I step back and realize the problem is not where I thought it had to be. That meant those areas which were not even a consideration, before, now come back for another look. I had again stumbled upon a case of:

If it can't be what it has to be, then it has to be what it can't be.

But, I suspect the real desire of this post is not improved debugging skills, but to avoid the need for debugging inter-vendor problems in the first place.

Good luck! It's the nature of the beast that bugs tend to occur in the interfaces.

But, there are some steps that can be taken to lessen the challenge... find someone else who has been down this path before and can point out the landmarks and land mines along the way. I commend you for doing so here in /., but there is more that can be done:

1. Start with the smallest project that you can. When you get that working and stable, take what you've learned and then add capabilities. Build not your house upon the sand.
2. Ask each vendor of each of the various components for a list of references -- and contact them. Consider, for example, your database vendor. Contact IBM and ask for references of customers who have used their DB2 database in a similar situation. Contact those references and find out what THEY learned from their experience. Do the same with Oracle and MicroSoft. Build up a table of strengths and weaknesses.
3. Contact others who have been down a similar path.
   • Search usenet newsgroups.
   • Read trade magazines.
   • Search WWW pages for vendors trumpeting their successes.
   • Search WWW pages for customers trumpeting their successes.
   • Search for FAQs on each of these components.
   • Read "The Mythical Man Month"

Yes, it is a lot of work, up front, but it has been well said:

A week in the lab can often save an hour in the library.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019