10.4 Vendor Selection Process

< Day Day Up >

In my experience, the disconnect between customer expectation and vendor performance comes from a breakdown in communications between the two parties, whether the vendor is new or entrenched. The difference, if there is any, in recuperation from this common experience is that the incumbent vendor probably has a long-term relationship that can be used to escalate and resolve unforeseen issues or misapprehended requirements. I have sadly learned more than once that new vendors may not know how to do this with you and your company, or anyone else.

From the point at which a vendor is selected, whether that turns out to be a new one or an incumbent, you need to treat the vendor as new to you, and be very careful how you proceed. Before that is covered, let us take a look at the vendor selection process, where the challenge often begins.

At a previous engagement, a fellow project manager was tasked with a project where the scope was to replace the electronic badging system used at a few sites. There would be one server at each site, plus a disaster recovery server elsewhere. The system would manage one hundred thousand badges and thousands of access points. The server platform and software had already been selected, so my colleague's project tasks were to:

Write a request for proposal (RFP) to identify the right vendor.
Select the vendor per internal procurement standards.
Replace existing card readers with a new, specified reader.
Replace the existing "last mile" cabling from hubs to individual readers.
Test the system in conjunction with the application support team.
Remove old wiring and readers after successful testing.
Obtain maintenance on the new wiring and card readers, with specified service levels.

If you had to guess how many pages the RFP was when it went out, what would your number be? If your guess is under 100 pages, your commitment to brevity, although commendable, has knocked you out of the competition. Even with relatively detailed drawings or descriptions of the legacy system and the requisite terms and conditions, the RFP should have been approximately 50 to 75 pages, not the 300 or so it turned out to be. Although the intent leading to this overkill was clearly to make sure everything that could possibly be included was, the opposite results were obtained, including:

Lack of clarity
Disorganization
Contradictory verbiage

Although I mean no disrespect with any part of this story, it is instructive in many ways. RFPs are often the strategic component in the vendor selection process. I think we all can acknowledge that obtaining satisfactory results for both customers and vendors through this process is statistically dubious. I have personally written and responded to dozens of these documents, some of them having presumptive price tags upward of $100 million. I can recall numerous occasions, as a vendor, when I would read one of these huge documents and wonder what in the world the customer was requesting.

I can also assure you that if, as a vendor, you receive an RFP from a customer with which you have done little or no business, you are tempted to chuck it in the dustbin. This is because you figure you are being used to pad the bid list so the customer can claim that a lot of vendors had a shot at the business, even though the deal was wired from the start with an incumbent provider.

On the flip side, as a customer I have read responses and accompanying questions from vendors that made me wonder if some of these companies or their employees had read our RFP, or had experience in the disciplines or activities that were the RFP's focus. Exhibit 3 summarizes the inherent, or at least probable, sticking points associated with the RFP process.

Exhibit 3: RFP Process Disconnects

The customer struggles to paint an accurate picture of target state.
Precise customer data is rarely available (census, asset counts, site information).
The vendor struggles to understand how much work (i.e., cost) is required to achieve target state.
Service levels, training, testing, and staffing requirements are too open ended.
Vendors strongly dislike being asked to state their "preferred" solution.
Respondents' proposals are difficult to compare as "apples to apples."

These conditions are not always true, but they generally are. What usually happens is this; because the customer cannot fully describe the current environment, target state, and his or her preferred path to get there, that ball gets tossed into the vendor's court. In essence, the customer says, "Give me your recommendations on what target state should really look like, and the best way to get there." Vendors are not stupid, and they are somewhat paranoid about losing business over pricing. So, they perceive RFPs as if the customer is really asking, "What is your best price for giving us the world?" In fairness, the customer wants value at a controllable cost, whereas the vendor wants a happy customer at a decent margin, but you can see from these disconnects how impossible those goals often turn out to be.

What tends to happen, then, is vendors respond with unit or tier pricing. Because the demographics (i.e., census or asset data) is generally pretty lame, and everyone knows it, the vendor offers basic products or services at a unit price. The vendor is protecting margin by saying "We will charge you $2 a widget. You tell me how many widgets are in scope, and we will do the math together." There is usually an accompanying floor and a ceiling, meaning there is:

A minimal billing assumption of, for instance, 10,000 widgets
A "not to exceed" billing level of a million widgets

Tier pricing is the other workaround. It typically reflects a laddered service level proposition. It is similar to going to the car wash, where the soap and water is $5, the wax job another $3.50, and the vacuuming is free if you pay for the wash and the wax. In IT projects, tiers focus on things such as recovery times, hours of support, and other matters of convenience. "The more service you get," they tell the customer, "the more you pay." A 24/7 call center, for instance, requires a headcount of five to provide one agent taking calls around the clock, once vacation, shifts, and supervision are taken into consideration. Someone has to pay for that. There is this myth of economies of scale, but having done some of that work, I can tell you that leveraging such economies generally translates into generic, depersonalized, and frequently ineffective service to the end users. I am not too sure about the savings, either.

Vendors tend to shy away from precise responses from a solution perspective for two reasons:

They fear that any good ideas revealed in the response will be shared by the customer with the selected vendor, who would likely be someone else.
Some vendor reticence to indulge in RFP response specificity is based on the fear that their proposed solution will be perceived as culturally or operationally incompatible with the customer's environment. Although this is one condition the RFP process is designed to ferret out, no salesperson worth his or her salt is going to create the impression that his or her team is strictly left-handed, especially when claims of ambidexterity appear far more likely to carry the day.

The final consideration is this. Several chapters and thousands of words have been dedicated in this book to tracking down requirements, vetting the design, crafting the right implementation strategies, and indemnifying the project, the environment, and beneficiaries against risk. To do this well, you needed liberal access to all kinds of resources, and you presumably held countless meetings. Put yourself in the shoes of a vendor's project manager who reads through your RFP and wonders how to protect his employer while doing a great job for you without the same advance, unlimited access to everything the insiders have. As a consequence, vendors quite naturally feel compelled to jack up their prices to cover risk that may, or may not, be lurking out there in customer land.

You may not be shocked to learn that vendors tend not to trust customers. Still, it is interesting to take a moment with the worst-case scenario in this regard, one that seasoned vendor representatives and project managers have experienced on numerous occasions. In it, a vendor agrees to perform certain project services for a fixed price, with agreed-to drop-dead dates. Sadly, it turns out that the customer had misrepresented the work or the risk associated with it. Even though this miscommunication may have been unintentional, the vendor tries to negotiate a different price or gain time to overcome this emerging trouble. The customer does not want to look incompetent, or more broadly, does not want it to appear that the problem is internal. Whether brazenly or not, the customer starts pointing the accusatory finger at the vendor. Now the vendor, who to this point has operated in relatively good faith, has three choices:

Call the customer a liar.
Eat the cost and take the blame to keep the customer happy.
Escalate on the client side, taking the chance that the seniors will be reasonable.

Frankly, this is all part of the vendor-customer taffy pull, but it is in the mind of every vendor representative responding to your RFP. Because I am taking the customer's side on the topic for this book, I want to end this section by summarizing what has been said here. Using RFPs to select vendors is a minefield because many issues surround whether or not an outsider should commit wholeheartedly to a possibly ill-conceived or, at least, poorly presented initiative. The vendor is being asked to offer a best price for a potentially high-risk venture. Add to this the potential for either side trying to use the other, and you can see why this process is often frustrating and can lead to unsatisfactory results. It also shows why, so often, an incumbent vendor wins the business in the end because they truly have an inside track, and they find the potential risks less onerous than vendors who are asked to fly blind on this one.

< Day Day Up >