An Introduction to Vendor Management

What is the overarching trend in vendor management today?

Do it in-house or pay for an outside pro? That’s the question at the core of any vendor management discussion. In thinking about the answer, it’s important to consider plunging prices for hardware and the software revolutions of plug-and-play modularity, Web-based services and open source—all of which serve to drive down do-it-yourself costs. Yet in the final analysis, in 2007 it often makes more sense than ever to assign IT-related tasks to external contractors.

To understand why, it’s useful to start with the ideas of nonagenarian economist Ronald Coase. More than a half-century ago, Coase offered a brilliantly simple explanation as to why companies and firms ever emerge from the vast sea of sole proprietorships that form the grist of any free market economy. After all, it seems that all entrepreneurs in an efficient open market should assemble their businesses from high-skilled, low-cost specialists willing to work on a contract basis.

Coase notes, however, that turning to the open market is rarely as easy as it sounds. All too often, he explains, once entrepreneurs factor in the cost of finding the specialists in the first place, then bargaining with them, and finally policing and enforcing their agreements, having a stable of in-house employees suddenly seems like an attractive option.

Of course, building a company, a vertically integrated mini-fiefdom, is hardly a cost-free endeavor. Coase says that, as a firm grows, administrative overhead invariably encroaches on the time the entrepreneur can devote to core creative work. And as boxes are added to the org chart and in-house complexity grows, even the best managers are prone to making mistakes.

Weighing these internal and external costs helps explain the number and size of firms, Coase writes in his 1937 essay “The Nature of the Firm”—analysis that still rings true today. What’s changed is that, thanks to increasingly global and transparent networks, it’s cheaper than ever to find and hire competent vendors.

How should I prioritize the time I set aside to deal with vendors?

Sometimes it’s a good idea to pause and remember that the idea of a C-level executive devoted to information technology is relatively new on the business scene. A search of The New York Times website for the term “chief information officer” in articles published in the last two decades of the 20th century yields slightly less than one mention per month. In the first six and a half years of the 21st century, the term garnered more than three hits per month in the Times.

Yet even though the notion of a strategic-thinking, six-figure-earning senior IT manager has gained currency, as a community CIOs sometimes adopt a somewhat defensive posture. After all, even today there’s no shortage of skeptics who say that IT is merely an undifferentiated commodity, like plumbing or electricity. (See Nicholas G. Carr’s “IT Doesn’t Matter” in the May 2003 Harvard Business Review as an example.)

Of course, plumbers and electricians don’t get paid to strategize and take sweeping organizational risks. And so perhaps it’s no surprise that a strong streak of conservatism runs through the ranks of CIOs. In fact, CIOs may spend upwards of 80 percent of their annual budgets on incumbent vendor fees and contracts—the rough equivalent of concentrating mostly on keeping the toilets flushing and lights on.

A better approach is to aggressively evaluate all vendors on their ability to add value and participate in the collaborative Web that stretches well beyond the boundaries of the business. “Today, most companies are networked businesses,” says Vallabh Sambamurthy, professor and executive director of the Center for Leadership of the Digital Enterprise at Michigan State University. “Not only must CIOs be involved in shaping their own business models, but they must also be vigilant about taking advantage of outsourcing, offshoring and other relationships with vendors in managing IT services.”

The trend, Sambamurthy says in a May 8 podcast, is for CIOs to make sure that all information technology investments, including money spent on external vendors, are driving future business growth opportunities.

What’s the evidence that forging more strategic, collaborative relationships with vendors actually works?

From trade press articles to reports by tech analysts to ubiquitous company-sponsored case studies, tales of increasingly value-added CIO-vendor partnerships abound. The only problem is that, even aside from the blatantly self-congratulatory case studies, so many of these sources of information are tainted by questions about objectivity. When selling advertising or analyst services to the tech industry, it’s generally better business to accentuate the positive when telling stories and reporting on trends. So when reading the latest paean to collaborative problem-solving in the new vendor-as-partner world, it’s likely that many CIOs harbor at least a few quiet reservations.

However, this is a case where reassurance can be found in even top-drawer business publications and much of the recent academic literature. One example is a September 2006 article in Harvard Business Review that summarizes results from a survey of 156 procurement executives about how their job responsibilities are changing. More than 90 percent of respondents described jobs that were expanding in scope to include shortening cycle times, taking the lead in product innovation, enhancing the quality of products or business outcomes, and generating incremental revenue, according to authors Carlos Niezen and Wulf Weller, partners at Bain & Company.

Another example comes from the spring 2007 Journal of Supply Chain Management. Two researchers, Antony Paulraj at the University of North Florida and Injazz Chen of Cleveland State University, surveyed more than 200 firms in an attempt to tie savvy vendor management to positive business outcomes. The professors found clear evidence that strategic buyer-seller relationships coupled with smart applications of information could help to integrate external logistics operations and overall business agility.

There’s much more research along the same lines, from such geeky refereed journals as the European Journal of Marketing, IEEE Transactions on Engineering Management and others, all of which basically find that the combination of innovative IT and a cooperative orientation toward vendors leads directly to better vendor performance and firm profitability.

The notion of all this value-added partnering with vendors even crops up in disciplines far removed from IT or even business in general. The March 2007 issue of Notes describes the folly of evaluating vendors solely on the basis of response time and fill rate. (For the uninitiated, Notes is the foremost scholarly journal for music libraries and librarianship; never let it be said that CIO doesn’t scour the intellectual landscape for its readers.)

Vendors who sell new scores and other music publications to libraries add the most value by providing broad recommendations related to new publications—a critical role since so few scores, recordings or books are ever reviewed and so remain doomed to obscurity. Such vendors, writes Daniel Zager, associate dean and head librarian at the Sibley Music Library in Rochester, N.Y., “are truly our essential partners in the collection development enterprise.”

How do I think about and negotiate pricing issues with vendors?

It’s all well and good that the nature of vendor relationships is evolving. But one thing remains unchanged: You still need to negotiate with and eventually pay vendors for their services. And here, of course, things can get sticky.

These days there is no shortage of bad news about open-ended, time-and-materials-type contracts. Anything even remotely resembling cost-plus contracting is now nearly universally tarred as a questionable business practice, so buyers across the board, including IT, may be tempted to insist on fixed-price arrangements. Yet it’s a mistake to assume that fixed price always means the best deal.

The bottom line is that negotiating pricing issues is hard work, and most formal agreements and casual norms should entail various carrot- and stick-related techniques. FedEx, for example, jointly celebrates the success of its vendors and gives out awards at regular luncheons—part of its overall effort to glean ROI from being good to its vendors and suppliers. Other incentives can include a willingness to act as a customer reference or case study if certain benchmarks are met.

Unfortunately, establishing benchmarks can be problematic, particularly as vendors take on projects that rely more on abstract brainpower than more easily measured technical or engineering brawn. Metrics like minimum required levels of uptime, bandwidth or computing cycles may make sense for servers and data centers, but not for software and systems integration. In fact, benchmarks can all but backfire if they give knowledge workers incentive to hit the wrong target.

As just one example, say you insist that your techie contract application development team document and track all bugs using a robust and transparent defect-tracking process. It’s a reasonable enough request, and the team will probably happily install and use one of the many open-source or commercial-issue tracking tools, most of which generate pretty charts and graphs designed to pacify process-loving managers.

The problem is that issue-tracking databases can quickly become clogged as developers input even piddly problems. And as the list grows, it is tough to stay focused on what bugs really matter and what, in the big picture, are mere minor annoyances. In the worst case, managing the bug tracker itself can become nearly as big a problem as keeping the development project moving forward.

In nearly all instances, a better approach is to instead assign business-related targets: Install the application by the end of the month, get users trained by the end of the quarter, move the application squarely into the critical workflow or transaction stream by the end the year, and so on.

Incentives aside, any big-ticket, long-term vendor contract needs to contain some provisions to protect the buyer, particularly from the one trend that’s a fait accompli throughout technology: The capabilities of hardware, software and services go up and the prices come down. This means that a contract that’s a bargain in 2007 may be a disaster by 2012, if not sooner.

For an insurance policy, consider using what’s known as a benchmarking clause, language inserted in the contract that gives buyers the right to have vendors’ prices reviewed by a third-party auditor. Prices found to be uncompetitive are enough to require renegotiation midstream.

In the 1990s, benchmarking clauses contained mostly vanilla language designed to facilitate gentle course corrections when buyer-vendor differences arose. But today, thanks to the usual gremlins that gum up dealings between technologists—high-priced consultants and lawyers—such clauses are increasingly controversial.

Benchmarking still may be the best way to avoid being locked into an agreement that goes from model of efficiency to money pit in a few short years. But if you want such a clause in the contract, expect to fight for it.

Beyond details about pricing, delivery dates and such, what can I put into my contracts to help foster good buyer-vendor relationships?

There’s an old saw in business that if you find yourself consulting the terms of your contract, your relationship with the contracting party is likely already shot. Certainly it’s not a good sign when you start sending e-mails that begin: “You know, according to page three of our agreement…” But a carefully constructed contract actually can help sow the seeds of collegiality—or, at the very least, forestall the nuclear option of lawsuits and expensive litigation.

As a first antidote to the inevitable tensions that arise in working relationships, contracts should always require face-to-face meetings, still an important ingredient in most business dealings. Fact is, it’s a lot easier to be belligerent and unreasonable by e-mail or phone than it is when hashing through things across a conference table.

Next, contracts should contain clear dispute escalation paths, including use of alternative dispute resolution, or ADR. Compared to the courts, ADR is generally cheaper, less confrontational and significantly faster. This last point is perhaps the most important since the longer conflicts go unresolved, the more they start to fester.

Then there are the basics. The group negotiating the contract should include at least a few people from the company who have the need for the vendor’s services in the first place. And throughout negotiations, the emphasis should be on reasonable expectations and flexibility. This means accepting the likelihood of at least a few snafus with some grace and good humor.

“An outsourcing partnership based on unrealistic delivery terms for a price that leaves little profit for the supplier is almost destined to fail,” writes Mark Amsden, a partner and national head of the IT Disputes Group at U.K. law firm Addleshaw Goddard, in the Jan. 5 issue of Public Finance. “Combined with the fact that no outsourcing project is cut and dried at the requirements stage—and will almost certainly involve change of some sort—conflict will almost inevitably arise.”

I need to cut the cord with a vendor. What should I do?

The best way to answer this one is to mention a few things that you probably shouldn’t do.

First, don’t act in haste and fire a vendor in a fit of pique. Instead, do your best over a series of weeks or months to clearly communicate your expectations, why they are not being met and what you intend to do about. (Namely, that you plan to show the doofus the door.) Ideally, many of these expectations should be spelled out in the up-front contract. But if they’re not and you start to suspect things are going permanently south, start creating a paper trail now. Having documentation can help you respond to the howls of protest that might eventually come from your vendor or his lawyer when you finally terminate the relationship.

Second, if the vendor is responsible for creating or maintaining any business-critical data or services, don’t fire her before you’re sure that your own employees have documentation or at least some serviceable knowledge of the vendor’s work. Even under the best of circumstances, it’s often tough for techies to deal with opaque work of unseen colleagues. Software developers, for example, often lament the prospect of dealing with OPC, or other people’s code. Though it’s sometimes easier to start from scratch rather than trying to pick up where the defrocked predecessor left oft, this option is almost always more expensive for the buyer footing the bill.

And finally, try not to be too public in voicing your displeasure and shopping around for a replacement vendor. Stories abound of vendors who, upon getting wind that they’re about to be fired, savage IT systems or important personnel with retaliatory activities.

One of the worst reported examples comes from a small biotech company based in the Rocky Mountain region. When the company’s onsite contractor realized that he was about to be canned, he surreptitiously wrote code so that he was blind copied on his employer’s e-mail traffic. This trove of correspondence included clear evidence that the company’s lead scientist was having an extramarital affair.

“On the day the consultant was to be fired, he zipped up 500 racy e-mails and, using another executive’s account, forwarded them to the scientist’s wife,” writes Dan Tynan of InfoWorld.

I’m not sure whether the Nobel Prize-winning Coase accounts for such subterfuge in his famous theory. One thing, however, is clear: Even though prices have plunged, the decision to send work to outside contractors and vendors can still come with the occasional hidden costs.

Science and technology writer Geoff Koch can be reached at koch.geoff@gmail.com. Read his “ABC: An Introduction to Change Management.”