Dealing with Vendors

Like a lot of people in the industry, the pile of magazines is high, unwieldy, and largely unread. At best, an issue is skimmed through with an article or two read. But with a cover article titled, "10 Things I Hate About IT" with lots of spit and venom pointed at vendors and their marketing (i.e., "me") I had to take a read.

A lot of usual suspects are covered; over-promising, over-buzzwording, support sucks, etc. The discussion around support issues reminded me of a rant I had not too long ago...

The Smarter Half has long held the belief that everyone in IT should have to take a project management course. It took a while, but I've come to agree with her on this one. Most of the challenges customers face with vendors, amongst other aspects of their organization, are due to poor project management. My co-worker and I were the fortunate ones that fielded most escalations as a result. Without fail, almost every single first step was to scream "STOP!" to get the bitter, pissy rambling to quiet down so that we could start collecting the specific issues in a spreadsheet.

These first discussions were often the most painful. I can handle the personal attacks, but wasting an hour on "issues" that can't be articulated in a clear, crisp sentence... Well, that just gets under my skin. This meant getting past "everything is broken" to "well, these n things are broken" and "chuck it off the roof and let my Glock fix it" to "well, fixing this bug will address problems 7, 8 and 9". Once we got past the circuitous rambling, we ended up with a list of specific issues that needed to be fixed to make the customer happy, assignments for who owns each item, and dates for follow-up.

So, below are my tips to IT buyers looking for resolution to their issues:

1. Get Organized

This seems simple. I mean, really simple. Yet, it's amazing how many escalations happen where after a month of "working the problem", no one can clearly articulate what they are trying to solve. If you can't articulate what's broken in a clear, succinct sentence, you're not going to get the right help from the vendor. For example, "It craps out which makes all of the servers time out waiting for it and you know that means Lumbergh is going to show up with his bleeding coffee mug asking whether a memo went out about the outage," is not a problem statement. "The system catches fire every day at 2pm which makes it shut down," is a problem statement. When you have a list of problems and what you define as fixed, the vendor can start working the problems and progress can be measured.

2. Stick to the Facts

When you stick to the facts, the vendor is forced to draw his own conclusions. If the conclusions are wrong, it's the vendor's fault. If you draw conclusions and give your assessment and the vendor goes off that information, then the problem becomes yours.

3. Be Ready to Invest Your Time Too

This is a tricky one -- if the product is broken, it's the vendor's fault and they should fix it. But the reality is that your time is going to be necessary to fix things. Your willingness to collect data and try things will go a long way to keeping the pressure on the vendor to reach resolution. Don't be afraid to push back on being the QA department, but remember that there are some things that are unique to your environment.

4. Pick A Point Person

If there are a team of people, communication between everyone starts getting tricky and confusion is ripe for setting in. Pick a point person on your team to deal with the vendor so there can be no excuses of "but I told this to so-and-so" and insist that a point person be assigned from the vendor's team so you don't have to piece together their organization.

Best of luck with your escalation. And if you insist on putting a bullet through the product, at least make it colorful and post it to YouTube.