Vendor Selection

  • Comments posted to this topic are about the item Vendor Selection

  • My guess is that often someone played golf with someone else, or takes them to dinner or other entertainment and the decision maker makes the decision that's best for them personally, not necessarily the company. I hate to be so cynical, but I see it happen over and over.

    I've seen more than one corporation ruined because the C-level goes with the vendor that wined and dined and showered them with sex instead of making a rational business decision.

    πŸ™

  • My rant about this subject:

    With my organization (K-12 Education), if the IT department chooses the vendor, we do as you do; research, test, compare, do an RFP maybe and get the best product for our dollar. We do get to purchase what WE select.

    However, even though we have a policy to not aquire software or systems without IT's approval, other departments choose a vendor with no thought process what so ever. Sometimes it is "free" software. Of course, we all know nothing is actually free. Free still means support costs, equipment costs, and IT time spent getting the "free" software functioning. Sometimes they just purchase an appication they read about, without any proof of it actually affecting student performance or getting us to research the product, then run in our office and want us to "install this program on the server." They have no idea what actually goes into getting a system or application functioning and we do not get any support from higher levels to tell them NO.

    Also, vendors are tricky. They get into State Education representative's pockets and convince them to give school district's some "free" moneys for a particular program, however the catch is you have to contract with a that vendor, get their application, and then get caught in a reccuring contract that ends up costing the school distrcit more money in the long run. Then there are also the implementaion costs - the less a product costs, the more it seems to cost to get it functioning!

    Holly

  • Steve Jones - SSC Editor (3/26/2012)


    Choosing vendors to be partners is hard[/B]

    I think the key term that needs to be considered is "partners" and even though not highlighted as a specific component of this search in the editorial, it is nevertheless one of the main considerations when looking at vendors. It is necessary to remember that this vendor is being selected to fulfill some critical business need or you wouldn't be spending the money with them, regardless of how small or large that amount of money is. With that, there is a need to ensure that the vendor will be able to fill that role. Golfing with them will not ensure that though. πŸ˜› What will? Look at their application lifecycles, the company history, their presence in the community and ensure that all those areas are at the level you would expect. A company that spends the time, and money, to impact the community is obviously desirous of making sure that their customers are going to be well taken care of as well.

    David

    @SQLTentmaker

    β€œHe is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot

  • In my experience, people in IT don't know where to start with an evaluation. I've asked simple questions about what are the inputs and outputs, how are the functions exposed, have we seen any documentation, have we talked to their support people. I get deer in the headlights responses. And I'm talking about other IT people.

    True, decisions are made based on golf scores and who provided the better lunch, but no wonder, if an IT person isn't ready with some basic questions, some system of evaluation that sounds cogent and reasonable, I wouldn't trust them either. Everybody has to evaluate things they don't know about all the time; cars, cell phones, insurance. People tend to glaze over more for IT decisions than others, and IT people tend to do a lot of whining about that. Instead, maybe we should be working on our communication skills.

  • You hit the nail on the head. I used to be a purchasing manager. Salesmen would come in to sell me products, and invariably used pro sports tickets and other inducements to make the sale. One time a vendor offered to outfit the bathroom I was remodeling, so I went to my boss, and explained the deal. He gave the OK for me to accept about $1,000 worth of product, as long as the salesmen knew we were not going to buy from him. I even wrote it up and had him sign that he understood.

    Later he was incensed that we didn't start ordering from him. When I brought up our agreement, he said something like "yes, but that isn't how it is done!"

    Clearly salespeople feel if they can get you to accept some free gift that you are obligated to buy their product. The pressure they put on you once you take the gift is extreme, and I doubt many people can say no.

    In fairness I see the same thing in family relationships, friendships, et cetera. People plan how to get someone to do what they want, then follow through with some enticement, and most people feel it is then rude to go against the wishes of that person because "they did that nice thing for me."

    Dave

    Dave

  • WolforthJ (3/27/2012)


    In my experience, people in IT don't know where to start with an evaluation. I've asked simple questions about what are the inputs and outputs, how are the functions exposed, have we seen any documentation, have we talked to their support people. I get deer in the headlights responses. And I'm talking about other IT people.

    Maybe it is the quality of people you hire, or lack of training. True IT people DO NOT have this issue. I have worked with technical staff in a number of companies, some as employees and some as consultants. There are always those who under perform, but no more than those in other fields, and nowhere near as many failures as I have seen in management. Those who are truly inteliigent, and who have been allowed to learn, have an understanding of what it means to select a good product.

    Dave

    Dave

  • WolforthJ wrote: "I've asked simple questions about what are the inputs and outputs, how are the functions exposed"

    Your IT department probably wouldn't know that. We keep systems running and keep the infrustructure running, but when it comes to using a system, the users are more cognizant of requirements and expectations. The creator of the system would know details such as how do the programs work (inputs, outputs, functions, etc). In our case that would be a call to development support. Planning the implementation of a system requires input from all stakeholders. IT will not have all of the answers.

    Holly

  • Your IT department probably wouldn't know that.

    What I meant was, as an IT person, those are the questions I think would ask of a potential vendor. Users would know what they want, but they tend to only look at the interface, what they will actually interact with. I hear salespeople and people who are passing on marketing info say that the behind the scenes stuff is easy. That may be, but I would like the opportunity to evaulate that myself if I'm the one who will be asked to do that easy stuff.

    Sometimes the quality of the answer is all I need to hear. As you say, the creator of the system should know how the programs work. If I ask, and they wave their hands and highlight a couple hot features but avoid the details, that's a bad sign.

  • For all that we'd like to believe in our rational choices, there is too much unknown and unknowable. We tend to favor products that would have solved our recent issues had they been in place (and yet not be sure about how they'd handle our unknown future crises). We tend to choose products that make sense to us as IT, but might not make the same sense elswhere in the organization. We cannot tell how it will scale in reality, how people will accept it, and how it will handle unanticipated needs.

    And every major product or project subtley changes the company down the road, a kind of 'butterfly flapping' event. It tends to channel users in directions where that product, by nature of it's philosophy, steers them. That, mixed with the unpredictable impact of outside forces in a continuous feedback loop can mean that we'll get to a somewhat different place. But we simply cannot predict what that place is for any product.

    In the end we can agonize indefinitely. Better to choose a qualified product and run with it.

    ...

    -- FORTRAN manual for Xerox Computers --

  • Given that this is a database-oriented forum, the (loaded) question that I'd like to ask is this: What do you want the vendor to supply you in relation to the database... regardless of anything else? The fact of the matter is that the vendor is much more likely to bend over backwards if they are trying to get your signature on a contract than they are if they already have your signature. So BEFORE you sign, have you seen the database schema? Have you seen the support documentation? The ER diagrams?

    In my organization, until recently these purchasing decisions have been made by people who honestly don't know what a database is. They'd go to the report writers after the event and say we need some reports from this completely undocumented, incomprehensible, unsupported "database". So the report writers would spend endless nights and weekends doing unpaid overtime trying to crack these databases. Often they'd produce the wrong results and they could be wrong for years. And bad business decisions would be made. It is an utterly false economy. In my experience, vendors DO go the extra yard to give you appropriate doco to enable rapid reporting development, if you ask for it BEFORE the contract is finalized. Beyond that.... pffft.

    ...One of the symptoms of an approaching nervous breakdown is the belief that ones work is terribly important.... Bertrand Russell

  • GPO (3/27/2012)


    Given that this is a database-oriented forum, the (loaded) question that I'd like to ask is this: What do you want the vendor to supply you in relation to the database... regardless of anything else? The fact of the matter is that the vendor is much more likely to bend over backwards if they are trying to get your signature on a contract than they are if they already have your signature. So BEFORE you sign, have you seen the database schema? Have you seen the support documentation? The ER diagrams?

    In my organization, until recently these purchasing decisions have been made by people who honestly don't know what a database is. They'd go to the report writers after the event and say we need some reports from this completely undocumented, incomprehensible, unsupported "database". So the report writers would spend endless nights and weekends doing unpaid overtime trying to crack these databases. Often they'd produce the wrong results and they could be wrong for years. And bad business decisions would be made. It is an utterly false economy. In my experience, vendors DO go the extra yard to give you appropriate doco to enable rapid reporting development, if you ask for it BEFORE the contrat is finalized. Beyond that.... pffft.

    Very good points indeed. If you don't ask beforehand don't expect to get it. πŸ˜€

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • At one company where I worked, our 'IT Tech lead' told us he had found a top vendor to provide a consolidated monitoring tool. We did intrusion detection using a couple of products, with one product (call it application X) was our main intrusion detection application.

    I asked the IT lead for more details and he directed me to the vendor's website. The IT section, management, and the vendor's sales rep and tech person were all going to have a meeting in a couple of days. Everyone was supposed to review the white papers on the product.

    So, I review the information and start seeing 'flags' go up.

    At the meeting, the vendor's reps start saying all the right things - their product will seamlessly merge with everything we have now and provide us all the reports we want in one package. Everyone in the meetting is smiling and the IT Tech lead is almost glowing. Then I raise my hand and it goes something like this:

    Does your product work with version # of our application X? Yes it does. My response: Then why does your website say it doesn't.

    The reps start 'huddling' and checking their information.

    No, that is the latest version and it takes development time to bring a 3rd party product up to the same level as the one it works with. (So they feel it would take them 6 months to update their code to make it work with the intrusion detection software we were using). I responded - but this version has been out for over a year.

    The reps 'huddle' some more.

    I then ask, does your product work with SQL Server 2000 SP 3a? Yes. Well, your website says it doesn't. Hmmm, again we need time to see how a new version works and then we upgrade our product to that version. It takes around 6 months. I responded, but SQL 2000 SP3a has been out for 8 months.

    The reps start 'serious huddling' and giving me the evil eye.

    My IT Tech lead starts turning red and the managers all start to stare at me.

    I say...so what you are saying is your product won't work with anything we are currently using and to use your product, we would have to stop doing current upgrades and stay about one year behind. Correct?

    They weren't very happy with me as they could see this sale going 'bye-bye'. But they did agree with me and tried to say that no one upgrades their applications to the latest until 6 months to a year has passed.

    My managers escorted them out of the building and the IT Tech lead was put on a very short leash for reviewing products.

    So, bottom line is....sales people will try to partner with you and sell you anything they can. That doesn't mean you need it or that it will really work with your existing product. Due diligence is really needed to make sure they can do what they say and that the business really will benefit from the partnership.

    -SQLBill

  • SQLBill (3/27/2012)


    At one company where I worked, our 'IT Tech lead' told us he had found a top vendor to provide a consolidated monitoring tool. We did intrusion detection using a couple of products, with one product (call it application X) was our main intrusion detection application.

    I asked the IT lead for more details and he directed me to the vendor's website. The IT section, management, and the vendor's sales rep and tech person were all going to have a meeting in a couple of days. Everyone was supposed to review the white papers on the product.

    So, I review the information and start seeing 'flags' go up.

    At the meeting, the vendor's reps start saying all the right things - their product will seamlessly merge with everything we have now and provide us all the reports we want in one package. Everyone in the meetting is smiling and the IT Tech lead is almost glowing. Then I raise my hand and it goes something like this:

    Does your product work with version # of our application X? Yes it does. My response: Then why does your website say it doesn't.

    The reps start 'huddling' and checking their information.

    No, that is the latest version and it takes development time to bring a 3rd party product up to the same level as the one it works with. (So they feel it would take them 6 months to update their code to make it work with the intrusion detection software we were using). I responded - but this version has been out for over a year.

    The reps 'huddle' some more.

    I then ask, does your product work with SQL Server 2000 SP 3a? Yes. Well, your website says it doesn't. Hmmm, again we need time to see how a new version works and then we upgrade our product to that version. It takes around 6 months. I responded, but SQL 2000 SP3a has been out for 8 months.

    The reps start 'serious huddling' and giving me the evil eye.

    My IT Tech lead starts turning red and the managers all start to stare at me.

    I say...so what you are saying is your product won't work with anything we are currently using and to use your product, we would have to stop doing current upgrades and stay about one year behind. Correct?

    They weren't very happy with me as they could see this sale going 'bye-bye'. But they did agree with me and tried to say that no one upgrades their applications to the latest until 6 months to a year has passed.

    My managers escorted them out of the building and the IT Tech lead was put on a very short leash for reviewing products.

    So, bottom line is....sales people will try to partner with you and sell you anything they can. That doesn't mean you need it or that it will really work with your existing product. Due diligence is really needed to make sure they can do what they say and that the business really will benefit from the partnership.

    -SQLBill

    Good for you SQLBill. That is one of the many reasons why we DBA's get paid the money we do. To see through all the Vendor/Sales BS.:-D

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • My description of most 3rd party software is very simple. "Over promised, under delivered." Of course, I feel that same way about 1st and 2nd party software, as well. It all normally falls under the category of "planetary" software... it sucks so bad that, like a planet, it has it's own field of gravity. πŸ˜€

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic. Login to reply