- What is the overarching trend in vendor management today?
- How should I prioritise the time I set aside to deal with vendors?
- What’s the evidence that forging more strategic, collaborative relationships with vendors actually works?
- How do I think about and negotiate pricing issues with vendors?
- Beyond details about pricing, delivery dates and such, what can I put into my contracts to help foster good buyer-vendor relationships?
- I need to cut the cord with a vendor. What should I do?
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 [artid:72525315|overall effort|new]] 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 centres, 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.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.