Friday, June 25, 2010
Yes, vendors can be engaging and nice—especially when they invite you to dinner or to all-paid conferences. However, this topic is about how to engage with vendors—a topic that’s often neglected in IT management books and forums. The more you rely on external products, especially in the context of IT transformation, where large budgets are at play, the more likely you are to have a long line of vendors knocking at your door. This is particularly true when vendors are desperately trying to meet their quarterly sales quotas. Don’t feel pressured. It’s up to you to manage the pace and mode of engagement with them. After all, the vendor decisions you are mulling over are likely to have a significant strategic impact, and ill-advised decisions could put you in a specific vendor prison for years to come. If you recall the section on tenets, I suggested that any technology transformation strategy be architecture-led rather than vendor-led. You should always be in a position to choose or replace a vendor on the basis of your own needs and strict best-of-breed and cost considerations.
Still, it’s never painless to switch vendors. Nothing completely removes the migration burden imposed when switching vendors or changing the reliance on a specific technology suite. This is why it is so important to identify early on which choices in vendor selection are strategic in nature, which are commodity led, and which have a chance of becoming too ‘sticky’ or addictive. For example, the choice of a data base vendor for your core data is likely to be strategic. What about performance profilers? Not so strategic; especially if your tenets have you selecting best-of-breed components.
It goes without saying that the selection of a strategic vendor should be based more along the lines of choosing a strategic partner. It’s more like a marriage than a one-night stand. You are not simply selecting the product but the partner. As a part of your vendor selection you are also selecting their vision, their culture, and most importantly a business relationship between your respective companies. I am not going to sugar-coat it: if you’ve decided to go with a strategic vendor for technology transformation, it’s highly unlikely that you will go for a garage-operation outfit (the only exception being when you see an extraordinary value proposition or a potential acquisition play). Chances are that you will be engaging one of the “big-guys”: IBM, HP, Oracle, Microsoft, etc. No need to apologize for this. You should, however, be wary of completely buying into their “integrated” value propositions. You should be able to maintain some degree of decoupling and freedom when choosing a particular vendor as a base. Yes, chances are that in the end you will most likely purchase more products from the strategic vendor, but you will be doing so because it makes sense (the add-on product integrates better, it is part of a bundle deal, etc.) and not because you have to.
In the case when you need to select a particular point solution suite (not necessarily a strategic vendor), you will likely pursue the Request for Proposal approach. Coming from someone who has been on the vendor side as well as on the RFP issuer side, I would recommend the following tenets regarding RFPs:
· Focus the RFP around your needs. Avoid over-elaborating the RFP with too much background about your company or other details not pertinent to the request at hand.
· Select only those vendors that you truly plan to consider for the selection process. Too often I’ve seen vendors invited to an RFP purely out of political considerations or to meet an imaginary goal of “minimum number of vendors to consider”. Remember that vendors usually have to spend significant effort and money responding to an RFP and it is not fair to have them go through the exercise if there is no chance in hell you’re going to choose them.
· Analogously, don’t have an RFP asking for the vendor’s color of underwear. Be wary of assigning an RFP to be developed by someone who is overly technical. This person is likely to request extreme details that in the end might not even be relevant to the assessment. Clearly, the details requested by the RFP should be commensurate with the value of the business opportunity. Even then, discussions about details should occur during follow-up meetings rather than via a response the size of “War and Peace”.
· Make sure the RFP explains all the key requirements, constraints, and criteria you plan to consider in the selection. Don’t make the RFP so general that vendors can simply answer with a very high level response (Goldie Locks’ rule applies: “not too detailed; not to generic”).
· Define the RFP selection process precisely and follow-through on it. Avoid sending the RFP out on Friday expecting a vendor response by Monday. You may believe this approach gives you a good evaluation element by determining which vendors respond quickly, but I surmise that a vendor’s quick response is not an ideal indication of how well his product will meet your needs. The purpose of the RFP is to obtain a set of responses that you can compare against your requirements.
· Let’s be honest, if you already have a product in mind and merely want to validate your choice, don’t do an RFP. Don’t waste the vendors’ time. In this case, I suggest that you are forthright with the alternate vendor. Call them up, explain the context of your query, and give them a chance to explain why their product is better than the product you are planning to use.
Treat vendors well and give them the time they need. Their alliance and partnership will be essential to the success of your project.
Given that you are involved with a presumably large IT transformation, chances are that you will also be approached by a myriad of intermediate and smaller size vendors, offering a variety of niche solutions. Now, I’m aware, when you are involved in your day to day activities, busy as hell, battered by the tremendous workload imposed by the running of a major project, those sometimes persistent calls from vendors with their incessant requests to meet, can become a major burden. As a busy executive, there is the tendency to ignore their requests and, frankly, to not treat them with the respect they deserve. I advise against doing this. I’m not saying you should meet with every single one, and risk death by PowerPoint, but I am saying that you should at least give a cursory glance to a vendor’s proposition (or at least have someone on your staff do so) by quickly checking his/her email or web site. My experience is that 99% of the time you will be able to quickly determine whether or not the vendor’s product has an immediate potential for application in your environment. If not, you should politely tell the vendor to check back with you at a later date. Most vendors appreciate this type of response and will gracefully go away—at least for the time being. Still, there will be those vendors who continue to persist and persist and persist. With pesky vendors you do have moral ground to be a bit harsher in your refusal to engage them.
There will, however, be those cases where you are intrigued by a vendor’s proposition. Perhaps they claim to have a better way of managing services or perhaps they have a way to improve your systems performance that is patented and exclusive? Some of these potential benefits might not be applicable to your project today, but may be needed in the future. You can ask this particular vendor to call back within a specific timeframe, consistent with your project plan, and give them a chance to reengage. There will also be those times when you are sufficiently intrigued to schedule an immediate presentation from a vendor in order to learn more.
It is difficult to provide a general recipe of how to deal with vendors since, as in all human interactions, there will be those who are excellent representatives and others who are in the wrong business and should be selling used cars instead of software and hardware products. Just keep an open mind and take an objective view of their sales style and value propositions. Vendor whose sales tactics are suspect (e.g. badmouthing the competition, giving deceitful datelines, etc.) should be avoided.
Finally, once you have determined that a vendor may be suitable to your needs, have established the requisite inter-personal trust and relationships with them, and agreed with the overall terms of their proposal and engagement model; it’s time to delegate the handling of the detailed negotiations and engagement to your vendor management team. If you are to preserve the degree of ongoing goodwill with the selected vendor as the project proceeds, other than for key decision selections you may be called upon to resolve, it’s best to avoid direct negotiations with the vendor yourself.
In the end, the best vendors are those who become as emotionally attached and excited as you are about the success of the project. Remember, a good vendor can be your best ally.