It’s time to face the facts: things with your project just aren’t going well. You brought on a vendor to help with software development or another business-critical IT task. You had a lot of optimism at first, but by this point, it’s all fallen well short of your expectations.  Maybe deadlines keep slipping while costs keep rising. Maybe email after email is going unanswered, except for the occasional vague reply that always sounds like a brush off. Maybe you’ve seen the code so far, and, well, it’s terrible. 

In a perfect world, you wouldn’t be in this situation. You would have seen the red flags coming a mile away when you were choosing your vendor, and you would have built in an agile development approach for a better chance of success.  

But, sometimes things still go wrong, even if you think you did everything right.  And so, one day, you start thinking… Should you pull the plug? Is it time to switch vendors, even though the project isn’t finished yet?  

Switching vendors mid-project is an incredibly complex and risk-fraught process.  Before you make the call, it’s important to be sure you’re making the right decision and not just reacting in the heat of the moment to a mistake or misunderstanding. 

Here are a few key points to consider when deciding how to handle a project when it’s not meeting your expectations: 

1. What else can you try to repair your current relationship and get the project back on track?

The first thing to determine before switching your vendor is whether there’s still a chance your project can be saved. Given the cost, disruption and risk associated with making a switch, it should always be your last resort. 

With that in mind, it’s important to ask: what else can you try to get things back on track? For the project itself, perhaps there are more project management strategies that can be deployed, from sprints to team redistributions or others. 

Make sure you’ve given your vendor a fair opportunity to make things right after a mistake or major slip up. In many cases, the mistake itself is not so much a big deal as the way the vendor handles it.  A working solution might still be possible, especially once any previous misunderstandings about requirements, capabilities or bugs have been cleared up. With a productive conversation, you might collaborate and find a new way to approach the problem. But if the vendor is showing a pattern of ignoring the problem, laying blame elsewhere or displaying a stubborn lack of flexibility, your problem may be bigger.

If the root of the problem is with your vendor itself, there are still strategies you can try to repair your relationship. Just as in people-to-people relationships, the key ingredients are communication and trust. Strong relationships work two ways, so make sure you’ve done all you can to communicate your goals, expectations and concerns with your vendor. And make sure you’ve given your vendor the opportunity to explain what they need from you to get back on track.  

Look beyond the frustrating contract details and metrics and milestones to the bigger picture. See if there’s a chance you can still work together to set new expectations, adjust plans as necessary and revise or put in new controls to avoid future problems. In some cases, especially when the costs and risks of switching vendors are steep, pursuing an option like third-party mediation might be easier in the long run than kicking your vendor the curb entirely. 

And, if you’re lucky, sometimes just the threat of switching vendors might be enough to help motivate your vendor to improve their performance. 

2. What will it cost you? And is it worth it?

Let’s face it: switching vendors mid-project is going to be expensive. And even after you switch, there’s no guarantee that a new vendor will deliver to your satisfaction, either.  

So, before you make the decision, you need to take a long hard look at the costs, risks and potential rewards of switching and make sure there’s a solid business case for the decision. If nothing else, this is going to be vital if you need to convince your senior managers or C-Suite on why the switch is needed. 

A few factors to consider when determining costs, risks and benefits include:

• What will it cost to break your current contract with your vendor?  Termination fees can be hefty, and often grow bigger depending on how far along the project is. And even if you believe there has been a breach of contract that negates the termination fees, your vendor may not agree. Dispute resolution processes will rack up a bill as well, so you should factor that possibility in. 
• How difficult (and therefore time- and money-intensive) will it be to switch over the project to a new vendor team? A lot of factors will go into this — everything from how well the source code was documented to the quality of that code itself. You’ll need to consider how long it will take for the new developers to get up to speed. There’s also the question of ownership itself — do you have full ownership of the software, system or app that the vendor created? Will you and/or the new development team be able to update or even access everything the previous vendor had?  If not, the transition process will be extremely complex. In the worst case scenario, the new development team might have to start over from scratch. (Many times, they may want to.)
• How will a lengthy/complex transition process disrupt or impact your business overall?  If switching vendors mid-project is going to suck up a lot of resources, or make some functions or capabilities unavailable for a time, then that may have a cascading effect on other projects or components of your business. 
• How willing will the old vendor be to cooperate with the new one?  Sometimes, things get ugly, and a vendor that is angry for being dismissed may be unwilling to help you transition smoothly to your new team. There are risks here you’ll need to weigh carefully. Thoughtful and strategic negotiation with the outgoing vendor will be key. For example, an angry vendor may be more willing to cooperate if your breakup won’t impact their reputation (for example, if you are still willing to provide a reference for them, or at the very least, agree not to post bad reviews afterwards). Some companies also negotiate bonuses to be paid to the exiting vendor if the transition is successful. 
• What additional or enhanced value could a new vendor provide that you’re not currently getting with your existing one? Here’s where you can consider the positive potential of a vendor switch mid-project. For example, a new software development vendor may connect you to a more skilled team of engineers or a broader set of capabilities, which will in turn lead to a higher-quality end product. They might even help you take your product in a new, more profitable direction. Most of these will be hypothetical benefits — you’ll be taking a gamble, but hopefully an informed one, if you decide to make the leap.  But if you put in the analysis to prove the benefits outweigh the costs, your chances for success will be greater. 

3. How have you contributed to the problem (and how can you learn from this experience for next time)?

The big reason why companies usually don’t switch vendors in the middle of a software development or other project is because of the risk involved. Even if you’re not completely happy with your current vendor, at least you know where the problems are. There are a lot of unknowns involved with making a switch. 

Before you decide to go with a new vendor and begin the process, though, you need to be reflective. This important because it will lower the risk of similar problems occurring with your new vendor. Make sure you understand what went wrong with your first vendor, when the trouble started and why it happened. Could you have seen the signs earlier before things escalated to this point?  Could you have handled things differently? Were your expectations as clear as they could have been? Were you giving constructive feedback when you noticed problems? 

These are going to be invaluable questions to ask as you begin working with a new vendor. And they’ll help guide you to the actions you’ll need to take to improve outcomes next time around. 

For example, if you’re in the process of switching vendors, now is the time for improving (or creating for the first time) your vendor relationship management strategies. This will not only help you identify, diagnose and fix problems earlier on with underperforming vendor teams — it will help you retain your best vendors. When you do find a great vendor, you’re going to want to keep them around and invested in a long-term and mutually beneficial relationship. 

One thing is for sure: if you find yourself in the painful and difficult position of needing to switch vendors mid-project, you’re never going to want to be in that situation again.  Weighing all these considerations may help you make the tough decision. They’ll also help you in the future, as well. You’ll be more likely to choose the right vendor for your project, more likely to have a successful relationship with them throughout the process, and more likely to achieve your project’s and your company’s goals.  

——————————

Can Genium help connect you with top-notch agile project management expertise?

Have a custom project in mind? Need some assistance assembling a team of world-class engineers to create a top-quality, innovative mobile app, web apps , or other cutting-edge tech endeavor? At Genium, we’re certified experts in agile development methods, with 30+ agile teams and a powerful track record of client satisfaction and success. Learn more and contact us today to see how we can help you innovate at the speed of light.