As part of their "Outsourcing Contracts Special Report," IT Business Edge completed a Q&A with Edward Hansen, a partner in the New York office. Hansen's practice focuses on IT transactions. (Reproduced with permission.)
Question: What are some of the pitfalls in outsourcing contracts?
Hansen: One of the biggest pitfalls that people run into is that they tend to write contracts that can be too rigid in the way they approach things. You have to be very careful when you draft these not to lock the present in for five years — particularly when you're expecting to see any kind of innovation.
The classic example of this is telecom. Five or six years ago, telecom was really a commodity, but now it's not. Lots of times when you do telecom deals, companies that are enlightened are looking at this as part of their marketing program. New things like converged communications are really moving telecom away from the commodity and into the strategic area. Well, what do you do if you outsourced telecom two and a half years ago, and you did something that was looking for really good contract terms and price — you may have gotten really rigid contract terms; you may have really kicked the other guy's butt — but that doesn't mean you've got something that's really going to work for you over the long term.
That's really where people seem to get into a lot of trouble. They start with a competitive process and with a procurement effort that really focuses on contract terms and price, and at the end of the day, contract terms and price are probably two of the least important aspects of an outsourcing arrangement. It's not that it doesn't matter. I don't want to give you the wrong impression; a contract is extremely important in an outsourcing arrangement. But the way they go about it focuses on the wrong things.
Question: What should they focus on?
Hansen: What really makes outsourcing work is the relationship between the parties. It's not a question of saying that I'm going to do this on a handshake, or that I'm not putting rigor into this acquisition. It's a question of understanding what the incidents of the relationship are, and then making it so that if the individual parties on each side of the table change, you can preserve the relationship.
Question: It's a matter of testing how you work together before you even get anything down on paper?
Hansen: That's exactly what it is...
Question: Can you expand on how the whole process should work?
Hansen: There's this thing I call the outsourcing paradox. To have a really successful outsourcing, the parties need to come together in a way that they don't have to come together for most other commercial relationships. I mean, you're taking part of your business, you're giving it to someone else, and you're buying it back as a service. You're buying back something that you're used to having complete control over, and now you have nothing to do with it. It's a very unsettling experience. … The customer and the vendor really do need to form at least a philosophical partnership in order to make this thing work. Otherwise, you're constantly relying on SLAs and legal remedies in the contract, and that's not a good way to live for five years.
The paradox is that the companies really do have divergent interests. As a vendor, you want to sell as little as you can for as much money as you can get. As a customer, you want to buy as much as you can and pay as little as you can. It's more complicated than that, but that's what it comes down to. So the question becomes, how do you take these two divergent parties and turn this into something that at least looks and feels like a partnership, where you have interests that align?
Typically, many people try to do that by starting off with one of the most obnoxious documents known to man, which is the RFP. … Everything about RFPs is about "You're going to do what I tell you, when I tell you to do it, and if you try to be creative I'm going to eliminate you. If you don't answer exactly the questions that I ask you, I'm going to eliminate you. I can eliminate you without telling you why I'm eliminating you." Everything about that process is about keeping the vendor on their toes and making them feel off balance. The problem with that is as a customer, you have a lot of leverage to begin with. There's a lot of natural leverage just in being a customer. You take that, then, and you play these psychological mind games that are completely useless and counterproductive. You've got people constantly watching everything they say; you're not telling them who their competition is; you're not telling them what they really need to do to win…
To make it worse, especially on the transformational deals, if you really knew what you wanted to buy, you'd do it yourself. The amount of burden it puts on the customer to get the requirements exactly right, to be able to say exactly what it is they want to buy, is making them take on responsibility that they don't have the expertise to meet. … You've set yourself up in a situation where you've got to be perfect because you're being so obnoxious with the vendor, you're setting the vendor up in a situation where you have a very complex sale that you're forcing them to put into a commodity-type arrangement, you're completely missing the boat on using what's really thousands of dollars per hour worth of consulting time that's on the sales side of the table because you're not allowing the vendor to sell. It just doesn't make sense.
Question: How does the process of inclusion come into play?
Hansen: The process of inclusion is based on the idea that you want to keep [prospective vendors] in as long as you possibly can. When I'm acting as lead negotiator on these deals, I tell people right off the bat, "I'm not trying to kick you out; I'm trying to keep you in." Just by doing that, you've changed the nature of every piece of criticism you give somebody. The only reason I'm telling you what I'm telling you is I'm trying to keep you in this game. … It changes the face of the negotiation, changes the tone.
The other rule is that you're not allowed to eliminate anybody based on an objection. You're only allowed to eliminate them based on a condition. The difference between a condition and an objection is that you can overcome an objection, but you can't overcome a condition. … So if you're doing a global MPLS implementation and a number of vendors come in for the presentation, and you find out that one of the vendors doesn't have a global MPLS network … you can't get the network performance that you need to get good quality voice. That's a condition. You don't even give that vendor the RFP because they don't sell what you need to buy.
On the other end of the spectrum is the price. You go through this exercise and you find out that one of the vendors is 20 percent more expensive than the others. But price isn't a condition. Price is an objection. It's the underlying cause that that price is what it is that becomes a condition. If you don't think that way, you lose a couple of things. First of all, there may be a reason the price is more expensive, and you may want to take advantage of that. For example, maybe their price is more because they have better engineering and you actually need that. Maybe they do a lot more R&D than the other guys, and you're a cutting-edge company that needs to have that cutting-edge kind of vendor.
On the other hand, maybe the price is what it is because the vendor is constantly embattled in lawsuits and they want to pass that risk to the customer, just because they have such a high operating cost. That's a condition. The fact that the price is too high is an objection, but what's causing the price to be too high is a condition.
What that does is unlock the vendors' creativity because they're never going to be eliminated just because they come in with a proposal that's too expensive. If you're doing a transformative outsourcing deal, that's really cool. What you're doing is allowing the vendors to put their brain power behind the solution — not to be stuck in whatever it was your procurement team thought the solutions should be, but really use their brain power to get behind what they're selling you. What happens is you start to learn things. Because you've gone into the process this way and you're really up front about how you're doing this with the vendors, you can change your requirements. You don't end up with an RFP that has these very rigid requirements that, when you go to change them, you've lost face.
Another thing that happens … Remember, you have a real interest in identifying what the conditions are, and the vendors have a real interest in overcoming your objections, because you can't go into the contracting phase with eight vendors. This is the first time you guys are aligned on something. You both have a real interest in uncovering the underlying conditions leading to your objections. It's the closest you're going to come before you actually get into a contract to being on the same side of a problem. What starts to happen is your engineers may end up talking to their engineers. This gives you an idea of how you would actually solve problems together when you're actually in the executory portion of the contract. Things start to take care of themselves. For example … when you draft the governance process [that will go into the contract], you design the process that really matches the way these companies come together to solve problems.
You've basically gotten to the root of why the people on each side of the table want to work with each other, and that's what becomes the basis of the contract. That's why I call it relationship-based contracting. You're getting that relationship established, then you're writing a contract so that, if the people on either side of the table change, you've got the fundamentals of the relationship documented. This isn't the same as doing it on a handshake.
Published 9/4/2007 by IT Business Edge
http://www.itbusinessedge.com/item/?ci=33144