Whenever I hear the expression “one throat to choke,” it makes me cringe. The phrase, in most cases, refers to contracting with a single vendor to help with every aspect of a technology project. Another variation is, “a single wringable neck.” Either way, it sounds like an explicit threat to the vendor: If this project fails, the blame will be placed squarely on your shoulders.
In reality, if a project does fail, it is very difficult to go after a vendor. Most organizations don’t. Lawsuits are risky, costly, and time-consuming. The only practical concession you can expect from a vendor is free labor, hardware, or software. But it’s from the same vendor that botched things in the first place.
Let’s face it—setting up a one-throat engagement is not really a threat. It’s a bluff. And it stems from an attempt to outsource accountability.
Choking a throat is not the point.
To put it even more bluntly, trying to shift the accountability to a vendor is a way for executives to mitigate risk to their careers, not to mitigate the risk of project failure. After all, the most common risk mitigation practice is to avoid putting all your eggs in one basket. But this is exactly what the one-throat approach represents.
Now, if we agree that using one vendor actually increases risk, we still have to debunk a few more common claims: that a single-vendor strategy reduces overhead and reduces costs.
The Overhead Myth
A frequent excuse given for centralizing to a single vendor is that managing multiple vendors requires additional overhead. On any project, someone must coordinate activities, issues, dependencies, timelines, and stakeholder communications. When you work with one vendor, a lot of that “overhead” activity is conducted internally by that vendor.
Unfortunately, as a result, IT has less visibility and control over performance. When IT assumes management responsibility, each vendor’s performance is much more transparent. This allows you, the client, to change course or reassign responsibilities before it’s too late and the heads need to roll.
The Lure of the Bundle
It is true that vendors often bundle additional hardware, software, and service components and offer them at a discount. Is this an upsell or a great deal? Typically, a vendor is doing their best to discount the items in the basket, but they also make every effort to increase the basket size. As a result, you are at risk of paying for items which:
- you’ll never use because they don’t fit your needs
- you plan to use in the future but can’t use immediately
- other vendors can do better and/or for less.
Some healthy competition, both in terms of scope definition and pricing, is a good idea. You can always award a segment of the scope to another vendor.
The Vendor Relationship Journey: Go in with your eyes open.
A one-neck vendor engagement is like a marriage that is destined for a divorce. There’s just too much pressure on the relationship. The journey includes periods of high trust and low trust, break-ups and make-ups, and worst of all, an emotional rollercoaster that wears both sides out. In the end, both parties come to an agreement to tolerate each other until they can finally go their separate ways.
Related: A Maturity Model for Vendor Relationships: You Can’t Marry All of Them
Luckily, it’s not generally assumed that client-vendor relationships are monogamous nor are they lifelong commitments. So, we can get a preview of what the relationship journey will be like by checking references.
While checking references for vendors I love to ask about strengths and weaknesses. Even the most satisfied customer often tells me that halfway through their engagement with a vendor, they identified an area of weakness which they compensated for by bringing in additional vendors. If you ask a vendor for a pure, one-neck customer reference, they will be hard-pressed to come up with any names. The bigger the project, the greater the diversity of vendors.
To mitigate risk, focus on accountability.
People that hire contractors to build a new house will tell you the only way to end up with a quality house is to be on the job site every day. Even the best building contractors require oversight. IT projects are no different.
Either IT needs to allocate project and vendor management resources, or a specialty vendor must be brought in to manage the project. It is this simple segregation of duties that gives IT executives control over the project’s destiny.
Divide and conquer.
The first step in delegating responsibilities to vendors is to bring in a trusted management team. If you are willing to bring in one additional vendor, let that be a management firm. That firm’s scope is project success. They have no dog in the fight. The only way they can secure more business from you is by being successful on one project, so you will give them another project to manage in the future.
This management resource will help you take the next step: distributing responsibilities. An advanced approach is to distribute tasks based on expertise, cost structure, chemistry with your team and others, and quality.*
(*As always, the most critical factor is the quality of resources. Vendors always have a mix of superstars, mid-level players, and seat fillers. Some of the best project teams I have seen were a medley of superstar representatives from many vendors. This is dividing and conquering by quality.)
Related: Managing Superstars
On the other hand, dividing responsibilities too much can backfire. The lines of accountability can get blurred. You can’t have two development vendors working on the same software module. If the module doesn’t work, they will point fingers at each other. A wise manager will make sure each component is clearly owned by one vendor.
“One throat to choke” is not a recipe for success.
Handing a technology project to one vendor in its entirety may be tempting. It can feel like a simple approach, but it introduces more risks than it addresses. The single-vendor approach is often a reflection of an organization that is trying to outsource accountability.
The true recipe for success is to divide and conquer. Assign the responsibility to manage the project to an internal resource or a separate vendor. Compile an effective team from individuals across multiple vendors based on their unique strengths.
