A vendor back-out cost us 6 months of delay in a project and close to 500k USD due to increased project costs. In large enterprise IoT projects, there is a dependency on external vendors to provide hardware, software, and solutions.

Recently, a vendor back-out cost us six months of delay in a project and close to 500k USD due to increased project costs.

In large enterprise IoT projects, there is a dependency on external vendors to provide hardware, software, and solutions. Even with the modular and extensible systems we design today, these external systems create some dependencies in application functionality.

What happens if your chosen vendor decides to back out of your project?

Top reasons for vendor back-out

The reasons could be different. For example, they may have been acquired by another company, their strategy may have shifted, or this kind of business may no longer align with their long-term strategy. It could be that your project is not exciting to them because of low volumes or low-profit margins or because too much customization is involved. Your project may not fit their product strategy, so they may not want to work with you.

Of course, we will try to prevent such eventualities while selecting a vendor. Proper vendor selection will help us choose a partner who will align with our long-term goals and stay with us long-term. It is a given that we will evaluate vendors holistically and try to identify a long-term partner.

However, there can be circumstances that are unforeseen and events that are out of our control.

Also Read: Risk Mitigation in IoT: 6 Tips from Avigna Experts

Corrective actions in case of vendor back-outs

What do we do if such a situation arises and a vendor partner backs out?

It will depend on what offering the vendor partner is providing to you and what the dependency is.

If the dependency is on software provided by the vendor, things are easier because transitioning software can be a more straightforward process than, say, hardware or platforms.

If the dependency on the vendor is for providing hardware devices, it is also possible to look at alternative vendors who can offer the same or similar types of hardware. In such situations, looking for a new hardware vendor is crucial because distribution, local support, troubleshooting, and upgrades are all important activities that cannot be done with just an in-hand stock of devices.

However, if the vendor partner provides a complete solution for a hardware cloud, connectivity, and cloud platform, and our integration with the vendor is at different points in this entire value chain, the transition becomes more difficult. We must look for hardware, connectivity, and platforms; finding alternatives for multiple aspects will take a lot of work.

Getting partners who provide a broad spectrum of services is extremely useful for an IT project because it increases the value addition and reduces the time to market. So, such types of vendors are common and also welcome as partners.

On the flip side, it increases the contractual obligations and long-term relationship we need with such a vendor partner. Hence, evaluation, understanding, and contracts need to be more thorough in such a situation. They should, of course, be fair.

Contracts with neither party should be forced into doing something that is loss-making for them and will endure in the long term. That means it should be a win-win situation, even with changing circumstances.

This gives a framework for taking corrective action when something goes wrong.

Another action that you definitely need to take is to understand why the vendor partner has changed their strategy. For example, if they have concluded that some of the technologies you are using in your stack are not viable long-term, then that is something you need to know. If they feel that some aspect of your value chain is not profitable, you must know.

Whatever other reasons the vendors have for changing strategy and not being part of this ecosystem anymore will be essential for you to know because, ultimately, they are part of the same game that you are. If the rules of the game are changing, then you need to know them to sustain and win in the long term.

Such an incident is a setback to our IoT project development. However, the impact of this setback can be controlled by making the right decisions at different stages of the project.

Have you ever had an incident where a vendor backed out from a project? Did they stop supporting an aspect of your project? How did you deal with such incidents?

I regularly write such articles, but you might miss them if you don’t subscribe! Below is an eBook I’ve written for your IoT success. I hope you find it useful.