Vendor selection – Tosamiro Consulting

A mandatory skill for any IT leader today is to know how to properly select a vendor. There are few projects/ services nowadays where internal resources, even with staff augmentation, can deliver the entire scope of a project/ service area. More often that not, nowadays cloud is the first choice.

Vendor selection should be managed as a separate work stream. The approach I’ve taken several times, successfully, is:

Understand what you want to achieve in the project and where scope gaps require a vendor. Prepare a clear scope statement that can be shared with a vendor.
Understand how the marketplace looks like in the area where you need a vendor. if you do not understand, then hire another vendor to do the research and prepare a report – with the caveat that this initial vendor cannot be one of the vendors that you will select (the “Dick Cheney” syndrome). This initial vendor should help with RFI (Request for Information – the discovery) and RFQ (Request for Quotes – the negotiation) development and evaluation, as well as provide a list of vendors.
You may decide you need multiple vendors as the scope it too wide for a single vendor or your procurement process requires it. You may also want to get multiple vendors in place as a risk mitigation strategy (“don’t put all eggs in one basked”).
Extend the scope statement and understanding from #2 to develop a RFI (request for information). This should be a formal structured questions driven table, that allows for side-by-side comparison.
Develop a list of vendors. The vendors should be matched not only by capabilities, but also by company size they serve, the geographic market, cultural fit, and what goals are most important to the organization (cost? quality? in person support? high end solution? etc.)
Send the RFI to a list of vendors.
Set a date for RFI response and respond to any clarification to all vendors. Make sure you have a level playing field (all vendors must respond by same date). Notes: High profile contracts tend to be extremely political; vendors who do not respond on time should raise red flags.
After receiving the RFI response, evaluate responses and remove the vendors who: (8.1) did not respond in time or (8.2) cannot deliver mandatory requirements or (8.3) are not a good fit for the organization. This latter point needs to be well documented. You may want to use the vendor from #2 to help with evaluation.
Remaining vendors should be required to submit a Request for Papers / Request for Quote (RFP/ RFQ), in essence a proposal on how the contract will look like. This also should be time boxed.
Once the RFQ responses are received, they need to be evaluated in terms of scope, cost (with finance), timeline, and contractual perspective (with legal and procurement). Again, you can have the vendor from #2 help with advice on whether the scope and price are reasonable.
If price negotiation is needed (you need to drive price down), keep top 2 vendor selections, and negotiate the price.
Adjudicate the contract/ formally select the winner. At times posting a press release can lower your price.
Negotiate the contract terms with the vendor. All contracts should be reviewed with your legal team, your technical architect and your security specialist. You should never have a vendor contract signed where you are in doubt whether the project will succeed (specifically that you have the resources and the time to complete the work).
Contracts should be all-encompassing, that is they should not be referring to external web pages, and they should include everything you need the vendor to do (e.g. if they need to do operations, make that part of the development contract, otherwise you are not in a position to negotiate).
Sign the contract.

Some key tricks in negotiating contracts:

IT contracts should be negotiated by technology specialists, not general procurement team. Technology is complex, and one word can make significant difference (think “Major System v.1” versus “Major System Lite v.1″). Procurement teams tend to be cost focused, whereas a tech specialist should be outcome focused. The goal is to get the job done. This said, procurement teams have proven strategies that can be used and should be involved in the process.
Vendors may low ball initial offer, so have a built-in maximum increase for contracts after they expire if you include operational costs.
When a vendor says a quote is only valid until date D to force your hand, be prepared to walk away. I have yet to see a special offer that could not be extended (except for acquisitions and monopolies).
Choose a vendor for the long term. It is a known fact that in IT once a system is “in”, replacing it takes double the cost: once to extract the data out, and twice to put in the new system. First implementation is always the cheapest project.
Given that many large organisations have a complex procurement process, check if the vendor can help in other areas. This is not to promote heavyweight multi-nationals who can do everything, but rather see if there is a symbiotic relationship that can be developed.
Document everything – especially on the consulting engagements. Some vendors are litigious by nature (especially for large engagement) and you need to protect yourself and the project from distractions.
If negotiations fail, be prepared to walk away from the winner and move to next selection. Failed negotiations are a sign of problems down the road, and as a project lead you don’t want to be known as “the person who brought in that terrible vendor”.
Have reasonable expectations. Not everything you search for will be available half price, even if you have a very large user base or budget.
Negotiate with decision makers. Just like when you buy the car, get to talk to the “sales manager”. You are wasting your time if you discuss with an intermediate.
It is of no value to discuss costs with a vendor that cannot deliver what you need. Only select solutions that work.
Treat vendors as partners. They are here to make money, and you are here to get value for the money. Underhand tactics, threats, will only attract a particular unscrupulous breed of vendor, and they will return the “favour” during project execution.
Expensive does not mean “good”.
Cheap does not mean it will work.

Good luck !