I think that old line “You can’t live with them, but you can’t live without them” is really about IT vendors. We all need them, and these days IT seems more reliant on vendors than ever before, not just for equipment, but also for IT development, services and support.
But from my earliest days as an IT manager, my relations with vendors were difficult and reactive, and I don’t think that is unusual. My seniors took a hard-nosed approach. “Don’t worry about the contract,” they’d say. “If they don’t perform, just nuke ’em and swap them out.” Or maybe the equally tough, “Just hold their feet to the fire. That never fails to bring ’em around.”
Nuking vendors didn’t seem like the best approach to me, not least of all because of the legal complications that I foresaw as a result of actually carrying out such a plan. Instead, I was trusting. If a vendor’s representatives told me they would deliver a service or product at a certain time for a certain price, I took him at his word and moved on to address other duties.
If you’ve ever dealt with IT vendors, you probably know just how naive this approach was. Inevitably, some agreement wasn’t quite met. Vendors that were late or whose service was below the level agreed upon were ready with lots of excuses. I heard account service managers cite snow days and other natural phenomena as reasons for failing to perform as required. “We thought you knew what we were doing all along,” one told me once, leaving me to think, “Actually, I thought you knew what you were doing, but I guess I was wrong.” All of my attempts to move my complaints up the vendor hierarchy were short-circuited by unanswered phone calls and e-mails. Meanwhile, the vendor’s account service managers would sympathize with me. They seemed to earn their keep by acting as heat shields for the higher-ups. I was getting nothing but empty promises.
I still didn’t want to nuke the vendors — although a tactical strike against them did tempt me from time to time — but it was clear to me that my approach would have career-limiting consequences. If I didn’t come up with a better way to achieve consistent and cost-effective results from vendors, my credibility as an IT manager would steadily decline. I obviously didn’t have my vendors’ attention, so I decided that they needed some of mine.
Escalation
The vendor that finally sent me over the edge had been contracted to send us many workstations for a call centre. They arrived just before the weekend, giving us time to set them up and have them ready for Monday business. But we quickly discovered that all the machines were incorrectly configured. It being the weekend, we could get no hands-on help from the vendor, so the local IT team set up a makeshift workbench and installed what was needed and put the equipment in place just minutes before the call centre opened on Monday morning. What should have been a one-day, three-shift conversion took two days and six shifts.
Unhappy with the extra expense, I checked the specifications in our order. They were correct, and what we had received didn’t match them. Talking with my on-site project manager, I had to concede that I had shown poor forethought in some aspects of the contract. Delivery was made too close to our go-live date, and the intervening weekend reduced vendor support to some telephone calls. We should have built enough time into the schedule to allow for recovery in the event of a problem and to accommodate an operational readiness test on each piece of equipment. That would also have permitted a go/no-go decision point, so that we could have rescheduled the rollout and not risk business disruption. But we both knew that the root problem was that we could not trust our supplier. I made an appointment at the vendor’s headquarters and, seeking justice, got on an airplane.
The executives at the meeting were conciliatory, but I became even more enraged when they told me that my order had gotten less attention than it perhaps deserved because they had received an order from a larger customer. Were they saying that our formal agreement need not be honored because a chance to make more profit had arisen? I felt as if they were nuking me.
Faced with my dismay, much flapping resulted. No, no, they assured me, they had misspoken. How could they make it good? I told them that I wanted them to cover our expenses that resulted from their lack of quality control. And I wanted on-site technical support and rapid access to spares for any deployments in the future. They quickly agreed.
As I was about to head back to the airport, the executives mentioned that my selection of their company as a supplier had been a good one. After all, because we had relied on them so often, my staff had been able to rectify the configuration problem on their own, and that was a sign of strength in our relationship. “It has taken us a while working together to get to this point, but your staff really knows our product, almost as well as we do.”
I wasn’t sure if I was supposed to take comfort in this, and pondered just what they were telling me all the way to the airport. Only after take-off did it hit me. Their real message was that a change in equipment suppliers would carry a significant cost for my company. In fact, my senior management and my company’s shareholders probably wouldn’t like such a decision very much. Was I a captive client to this supplier? I needed another vendor relationship management strategy. This one wasn’t working.
Vendor Relationship Management 101
At this point, it became obvious to me that the problem was that we weren’t dealing with our IT vendors professionally. Oh, we were all professionals, and we behaved professionally. But my people were proficient in their various areas of IT expertise; they were not expert at procuring services and designing contracts.
We used the total cost of ownership (TCO) methodology for selecting and acquiring all services, software and equipment suppliers, but we weren’t strategically very good at it, despite having undergone training. It wasn’t possible for my people to gain enough experience with this type of analysis to do it really well. The depth of analysis varied from manager to manager, dependent on the amount of time available to them and the product or service being assessed. And an important factor was that my staff’s performance wasn’t measured on the quality of their vendor selection outcomes.
What we needed was a group of professionals who were dedicated to the task of contracting with vendors and working with them full time. They would not be distracted by other duties, and their performance would be judged entirely on their ability to achieve success in our vendor relations. In short, I needed a dedicated IT vendor relationship management (VRM) unit employing professionals adept at devising technical contracts, analyzing TCO and evaluating vendor performance.
I went to the senior executive committee with a compelling business case (the examples of contracts gone awry were embarrassingly abundant), got funding and established my first IT VRM unit. It paid for itself many times over in its first year.
From that time, as I moved to other IT management positions, I was never without an IT VRM unit whose only assignment was to ensure that we were achieving the lowest TCO practicable with all of our hardware and software vendors. “Practicable” is a key word. Pricing in isolation can be misleading. The IT VRM unit deepened the TCO analyses significantly beyond what any IT technical manager could even consider. Among the things that the unit evaluated and verified were competitive offerings and their features, actual warranty/guarantee value, support qualifications, references, contracts or agreements with other entities that might have a conflict of interest, confidentiality, actual support responsiveness, time to ship, involvement in new product design, access to laboratory results, upgrades, beta testing participation and results evaluation, product life expectancy, compliance with industry standards and best practices, company financials, company management depth, acquisition potential and vendor relationship exit strategies (to avoid contractor dependency situations). Sometimes the unit did research on emerging technologies to get a sense of the optimal time to buy into a technology. The result was ever more productive IT investment decisions.
In simple terms, each supplier or contractor is considered part of the IT function’s customer experience and, through the IT VRM process, their performance is measured using the same quality metrics as are used by each IT function. The relevant IT function and the supplier/contractor must jointly develop these quality measures. Missed quality targets are seen as joint issues, and the root cause for them is jointly sought. And payment to contractors/suppliers can eventually be based upon their performance against specific quality metrics.
A better customer?
So, had I come around to the “hold their feet to the fire” method? No, this was a far more sophisticated approach that stressed relationships over antagonism. For example, the VRM unit wanted to improve on the six weeks that it typically took to place an order for a desktop or laptop PC and install it. Some of the VRM staff met with the vendor and learned that a small volume commitment would allow the vendor to “stack” its product locally for ready shipment — an easy fix that benefited both parties. As a result of this small change, the PC order-to-install time dropped to seven days (including weekends). Instead of holding their feet to the fire, we had just become a better customer.
With an IT VRM unit, we were able to make outside contractors and vendors more of an involved partner in the success of the IT function and its clients. And when the contractors “get it,” their performance improves. Recognition occurs. Metrics are raised and an overall continuous performance improvement process actually sets in and becomes expected. And when you get vendors involved to the point that they care about your success as much as you do, another benefit of this approach surfaces: Vendors voluntarily begin making improvements in their offerings to better achieve the jointly required outcome. While this last benefit can be a bit competitive at times, it is irreversible. And it is priceless.
If I were asked about the likelihood of using the “just nuke ’em” approach to attain this level of vendor harmony and partnership, I’d probably respond with some sort of example involving a snowball and a blowtorch. I’d also have to point out that as the above “part of it, proud of it” method is more certain and proven, why would anyone try?
Al Kuebler was CIO for AT&T Universal Card, Los Angeles County, Alcatel and McGraw-Hill and director of process engineering at Citicorp. He also directed the consulting activity for CSC Europe. He is now a consultant on general management and IT issues, as well as a speaker at the graduate schools of NYU, De Paul and the University of Chicago. He is the author of the book Technical Impact: Making Your Information Technology Effective, and Keeping It That Way, from which this article was extracted. He can be reached at [email protected].
Computerworld (US)
