This Is What Multi-Vendor Support Looks Like

Multi-vendor support isn't for every organization. But as your business evolves technology requirements and software support needs change. New business necessities surface which require you to have specific software features, a new platform or hosting setups, or updates which have to be deployed.

Once they are deployed, this software requires support. So you move to partner with specific support multi-vendors and sometimes your organization might have several support vendors. Each vendor might handle the uptime and performance of various software implementations, web applications, and related hosting environments. While it might have solved your immediate technological challenges to have these partnerships, organizations must review their multi-vendor support arrangements. Decision makers need to ensure that business needs are met by support providers efficiently.

There are many reasons why organizations have multi-vendor support setups. Some companies do not want to be in a single-vendor lock-in arrangement, which decision makers fear work more in the favor of the vendor than the company. Transparency, service quality issues, hidden support costs are some of the risks companies associate with single-vendor contracts. Therefore, for some, a multi-vendor support strategy has a lowe risk.

Strategies like this aren't limited to large enterprises. Any growth-oriented business or organization that leverages technology would often be in a situation where a multi-vendor support strategy is required. From non-profits to universities, from high-growth startups to mid- size enterprises in various industries, a multi-sourcing strategy for support can be leveraged. When done well, a multi-vendor arrangement can become a collaborative effort to tackling complex or extensive application development, or platform support and maintenance. It can also bring cost efficiencies and different types of skillsets to the table.

What is a multi-vendor strategy for?

A short-term requirement

 When you have to transition from an existing support team to a new one, you would need some overlap that enables painless and thorough handover. You could be completing a development project with one vendor, and then transitioning to another for maintenance and support. Or you could be moving to a new vendor for reasons such as cost-effectiveness, specific technology expertise requirements, quality issues, etc.

Different support for different purposes

 You could have multiple departments that prefer to deal with separate vendors. However, you might still need some overlap due to a common platform or technology being deployed.

More capabilities

 You might have a vendor who is your primary partner. But when you have new requirements coming up, or new launches planned, you might need additional manpower to effectively support the primary vendor.

All vendors aren't alike, obviously. Leveraging differences in such a way that helps you meet your business goals effectively is just smart business. Here are some reasons to go the multi-vendor way. You can:

• Pick and choose the technology expertise, the type of service, and the tool sets
• Secure the best mix of resources within your budget
• Get dedicated teams for distinct functions
• Have task delegation between vendors to manage overflow or workloads
• Achieve quicker and more sustainable delivery of solutions for your business needs
• Mitigate the risks associated with program failure by splitting it up between multiple vendors
• Provide a clear line of responsibility, minimizing functional overlaps and dependencies 

Make multi-vendor support work for you.

There are risks and rewards. Multi-vendor support setups bring a slew of benefits but they also bring challenges. Who handles what? Is your web application down because there has been a Denial of Service (DoS) attack, or has your server crashed for some reason? Why is there a timeout when some queries are being run? Is it a hardware issue, or is there a bug in the software, or is it a database issue? Whom should you call? Who can fix it right away? Do you have to go through your list of vendors, one by one? Imagine a vendor pointing fingers at the other vendor. Not hard to imagine, right?

Meanwhile, your web application users are waiting for the site to be back up. Do you have time for all this? This is a scenario that is often played out in companies with multiple vendors.

Or take another scenario. You want some new features built in two different applications through two different vendors. For your project to start delivering results, both applications with the new features have to be working in tandem. Except that one vendor has not even started on this, as it not in their priority task list!

Immature IT processes can be the cause of such issues. Either your own processes are not clearly defined or your vendors are too immature to understand and adopt those processes. Often, vendors start competing and try to pull each other down to win more accounts. This can happen because of blurred responsibilities, or a lack of accountability, goals and success metrics. So how you make multi-vendor support work? 

This is what successful multi-vendor support looks like:

Agile multi-vendor approach

 An agile approach to platform or web application support encourages collaboration among multiple vendors. With constant collaboration among your various vendors, you can get the right momentum in place to reap the business benefits you have envisaged from your project. You can set up the sprint backlogs for all vendors, and set priorities as per your project requirements.

Agile support offers a structured process to approach maintenance and multi-vendor support and ensures that the stories get completed, and the features or updates are ready to be deployed within a specific time period. In a scenario like this, all your vendor teams keep deploying new features every week or two weeks—speeding up your project processes.

Build in ownership

 Multi-vendor setups fail, or at the very least deliver slow results, simply because no one owns the problem. In many cases, it is not even clear whose problem it is to own. So while you have a set of vendors who are meant to support you, you might often find yourself solving issues that you are already paying for. For example, improving your website’s uptime or solving the login error in your application that’s annoying your current customers.

Not having clarity in ownership can prove to be too expensive for a project and has implications for its successful delivery. You could have delays and downtime that your users and prospects refuse to suffer. Worse, you will spend your productive time in fighting fires that you should not even be involved in, thus forcing you to take your eyes off future strategies.

Build in visibility

 Operational-level agreements (OLAs) define how multiple vendors will interact with each other while providing their services. With multiple dependencies, it becomes difficult to clarify responsibilities between vendors. Thus, businesses require OLAs to define how interactions will take place among different vendors across functions like work planning, information and deliverables reporting, service integration, etc.

If OLAs are driven by the IT processes of a business, they can act as a guidebook for different vendors, ensuring smooth operations and enforcing a resolution mechanism in case of any dispute. If they are not, vendors can start developing their own ad hoc interaction rules based on how the relationship progresses. Such rules may not be in the best interests of the business.

Who owns your platform right now?

No doubt, you own the platform or application and its business goals. But you also need to be supported on the technical side with as much ownership. This could be an internal person or an external vendor who acts as Product Owner (PO). Their job is to be completely aligned to the business objectives and then go about planning what needs to be done on the application/platform to achieve those objectives.

For this, the PO can have conversations with all vendors and work out possibilities and scenarios. And then, after consultations with you, they can come up with a plan to execute the ongoing maintenance and support. The PO can use an agile approach to get things going, in sync, and in the right order of priority (with realistic timelines) so clear expectations are set. The PO ensures that the multiple teams with support talent work in sync, in line with project goals, schedules, and budget. In addition, clearly defined OLAs would aid vendors in keeping performance at the top of their minds at all times.

With this kind of collaboration, visibility and ownership built in, the vendor teams are also motivated to think proactively about improving pieces they own. This effectively brings in a customer success approach to agile multi-vendor support. You get a team who owns your application and also thinks beyond support. The current issues are taken care of and the needs of the future are addressed as well.