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:
- Sales reps who don't know their own products.
- Over promise, meet under deliver.
- It's a software problem! No, it's a hardware problem!
- One size fits all documentation.
- Vanishing support after the sale.
- Putting down other vendors.
- Configuration fails.
- Outsourced telephone tech support.
- Customer-hostile online support.
- Abusing a monopoly position.
- Throwing [system] admins under the bus to make a sale.
- Getting what you pay for.
- 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.
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.
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.
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.
