Skip to main content

The BUSKLAW July Newsletter: Mitigating the Things that System Administrators Hate About IT Vendors



I just finished the excellent article "13 Things System Administrators Hate About IT Vendors" by Jeff James at Petri IT Knowledgebase. Here are those 13 pain points:

  1. Sales reps who don't know their own products.
  2. Over promise, meet under deliver.
  3. It's a software problem! No, it's a hardware problem!
  4. One size fits all documentation.
  5. Vanishing support after the sale.
  6. Putting down other vendors.
  7. Configuration fails.
  8. Outsourced telephone tech support.
  9. Customer-hostile online support.
  10. Abusing a monopoly position.
  11. Throwing [system] admins under the bus to make a sale.
  12. Getting what you pay for.
  13. Clueless consultants.
Good news! Well-drafted contract documents between the IT vendor and customer can mitigate many of these issues. Here's how:

First, the customer should base its selection of an IT vendor on the vendor's written response to a carefully-prepared Request for Proposal ("RFP"). In my experience, IT customers don't spend enough time in preparing their RFPs. The RFP should include a section that contains an itemized list of the customer's business requirements for the software (i.e., its features and functionality), followed by three fields (with the following headings) for the vendor to complete:
  • Yes (meaning that the software meets the stated requirement).
  • No (meaning that the software does not meet the requirement).
  • Will, as described, be part of a future release (give specifics).
The customer should reject any RFP returned by the vendor that doesn't have this section completely answered. And the RFP should include putting the vendor on notice that:
  • its answers in this section will be entirely incorporated into a contract; and
  • the vendor will comply with this section of the RFP, notwithstanding any other provision in the contract, the RFP, or the Statement of Work ("SOW"). 
If the vendor won't agree to so incorporate the RFP into the contract, the customer has a red flag that at least suggests a serious discussion with the vendor, if not consideration of the vendor's closest competitor for the solution. 

The RFP can also address some other issues that Mr. James identifies, including (i) the quality of the documentation (ask for it with the return of the RFP and clear up any gaps at an early stage in the relationship); (ii) support after the sale (the RFP should contain the customer's support requirements, including prohibiting off-shore support if appropriate); (iii) the vendor's going out of business after the deal is inked (have the vendor provide bank references and financial statements to determine its strength in the industry). 

And as part of the customer's due diligence, the vendor should be asked to provide several current customers who can be contacted to determine their experience with the vendor. Visits to these customers should be considered to tour their facilities running the vendor's software.   


Second, the customer should consider including a pilot or trial period in the contract, allowing the customer to test the software in its IT lab and accept or reject it for any reason after 30 to 90 days  This may be the best way to see if there are software configuration problems or incompatible hardware issues and try to resolve them and if not, the contract ends. The customer returns the software and its documentation to the vendor, the vendor returns (or destroys) the customer's confidential information, and the parties go their separate ways. Even if the vendor charges the customer a fee for this trial, the fee (and the customer's time investment) will be significantly less than if a permanent deal is inked and software configuration or hardware issues become evident.

Third, make sure that the parties hammer out a SOW that contains more than generalities. If the vendor has to configure or customize the software for the customer's unique data processing environment, specify how this is going to happen, when, and for how much. And for the vendor's configuration or other professional services, tie payment to the vendor with specific milestones evidenced by deliverables. And be sure to include appropriate change control provisions to reduce "scope creep." 

Fourth, many large IT vendors are big players, Microsoft comes to mind. My response is "if you can't beat them, join them." So, larger customers should see if they can become Microsoft "reference clients" to gain business benefits, including free passes to user conferences, access to senior executives, input on new products, and the first right to try beta products. The trade-off in becoming a reference client is the time the customer's IT staff must spend in recommending Microsoft solutions to other potential Microsoft customers. If a customer goes this route, the benefits of being a reference client should be spelled out, including how long these benefits will last. In addition, there should be restrictions on how much the customer is required to show the Microsoft solution that it has adopted to its competitors. 

Finally, customers shouldn't fall for the IT vendor's song and dance that there is no need for a RFP, Statement of Work, or definitive contract, or that the customer can just sign these documents prepared by the vendor. IT customers should never sign vendor-prepared documents without review by all of the customer's stakeholders, including qualified legal counsel. To do otherwise is just dumb.


Executive Summary:

To mitigate the pain points between an IT vendor and customer, consider having: 
  • A carefully-prepared, comprehensive Request for Proposal that itemizes the customer's specific business requirements for the vendor's software;
  • A pilot of the vendor's software in the customer's lab, with the customer's right to accept or reject the software for any reason at the end of the pilot; 
  • A detailed SOW that specifically addresses who is to perform what configuration and customization services; and
  • A definitive contract that, among other essential provisions, requires the vendor to comply with the RFP and the SOW. 
  • The customer may leverage an IT vendor's market power by becoming a "reference client" for the vendor, allowing the customer to obtain clearly-specified business benefits in return.

Comments

Popular posts from this blog

The BUSKLAW June Newsletter: Forcing Business Behavior Changes Through Buried Contract Provisions: Salesforce and Camping World

As reported by  The Washington Post , business-software giant Salesforce  recently instituted a policy barring its retailer customers from using its technology to sell semi-automatic weapons, including the AR-15 used in numerous mass shootings. One such customer is  Camping World , whose Gander Outdoors division sells many "AR" and other semi-automatic rifles .  Rather than approach Camping World/Gander, a "leading" Salesforce customer, and negotiating the termination of their semi-automatic rifle sales in exchange for some benefit (such as a software discount), Salesforce was tricky. They buried a provision barring the sale of semi-automatic rifles in the acceptable-use policy  ("AUP") binding on Camping World/Gander: Salesforce wants to force Camping World/Gander to make a major change to its business model via an addition to their AUP that is irrelevant to their customer's licensed use of Salesforce software. And although sneaky, I bet tha

The BUSKLAW Halloween 2022 Post: Stephen King's Asides on Poor Writing in Fairy Tale

  Having just read  Stephen King's Fairy Tale in time for Halloween, it's appropriate to examine his asides on poor writing included in the book. (BTW, Fairy Tale is a good read with King's typical well-executed character development, plot, and a great finish to the story. But you have like the whole Grimm fairy tale genre before you read his take on it.)  Stephen King doesn't tolerate anything less than crisp prose. When the story's hero, Charlie Reade, tries to read a book about the origins of fantasy and its place in the world matrix ("what a mouthful"), he can only scan it because: It was everything I hated about what I thought of as "hoity-toity" academic writing, full of five-dollar words and tortured syntax. Maybe that's intellectual laziness on my part, but maybe not. Later on, Charlie tries to focus on a particular chapter in the "origins of fantasy" book about the story of Jack and the Beanstalk but is put off by "t

The BUSKLAW April Newsletter: A Force Majeure Clause for the New Millennium

(Author’s Note: I originally wrote this post for Y2K, but I’ve updated it using plain English.  Happy April Fool’s Day 2016!)             A standard force majeure contract clause, where "Acts of God" excuse one party from performing their obligations without that non-performance being a breach of contract, are so 20th Century. So what if fire, flood, hurricane, snowstorm, or riot excuse contractual non-performance. Those events are too mundane to contemplate! Contract lawyers desperately need a force majeure clause for the clear and present dangers of the new(er) millennium! So, as a public service to the legal profession, I’ve assumed the heavy burden of drafting a "new age" force majeure clause for my colleagues to freely use: Either party's non-performance of this agreement will be excused to the extent that it is caused by the occurrence of any of the following events or circumstances: (i) Alien abduction, alien invasion, alien cerebral possession,