How to Fail in Outsourcing Your IT Project

Subcontracting success stories are all well and good, but what about all those epic outsourcing disasters that you often hear about? According to industry watchers, IT outsourcing failure rate is staggering with roughly 50% of contracts ending up with time and cost overruns, poor quality, unhappy clients, and millions of dollars going down the drain. So, what is it that makes outsourced tech projects crash and burn? And more importantly, how can you avoid being one of these appalling stats?

In today’s business landscape, you absolutely must outsource to stay afloat. The allure of slashing costs while getting high quality work is just too strong to resist. As appealing as it seems though, software outsourcing is easier said than done. Many companies have found great success with it, but even more have faced business-sinking nightmares. Possibly some of them keep haunting you as well. Perhaps in the past you had bad run-ins with remote employees, or your project failed outright and got cancelled. So, you promised yourself that never again in a million years would you outsource your development to any WeAreTheBestDevsEver Inc. from some far-off land. Or maybe you haven’t even tried it yet, but all these horror stories about outsourcing fails and wrecks are, to put it mildly, not helping you to choose that path.

Outsourcing is prone to failure, but not doomed to it. To err is human, so it’s OK to fail as long as you learn from your missteps. Better still, as an old adage has it: “A wise man learns from his mistakes, but a wiser man learns from someone else’s”. There are many people who learned the hard way, so that you don’t have to. We have distilled some of the key takeaways into the list of wrong attitudes to guarantee your outsourcing fails (Hint: stay away from these pitfalls!) as well as fail-proof outsourcing tips to ensure that your project won’t turn into a boondoggle.

Not so fast! You may be treading on thin ice here! Sadly, in a panicked rush to save big bucks, businesses drown big time. Everyone says they are looking for the right partner, but it’s the lowest bidder who usually wins the deal. Too bad that an underbidding contractor may soon turn into an underperforming one, and the next thing you know you’re spending a fortune on getting your project fixed. Price is king only until … your app bites the dust. If software development is dirt cheap, it’s a red flag to look out for. It may well be that either the supplier overlooked something in the price assessment, or some hidden costs are lurking in your project, or the quality of work may eventually suffer.

Initially underfunded projects are often behind schedule, over budget, and have quality issues. Estimates are tough, so experienced contractors include possible risks into the price to recoup their losses. And it makes perfect sense. However, that pricing must be justified and transparent to the customer. Educate yourself about the potential hidden costs of the deal and make sure others who made business with the provider ended up happy with the bill. Also, award fair compensation to your employees. If you haggle too much over fees, you risk getting bargain work in return.

Note that not all programmers are equally good. Yes, those folks may be cheap, but how much real value do they produce? Putting more bodies on a project does not equal more value either. One coding nerd can push your project forward within a couple of days, while the whole team of the-bottom-of-the-barrel developers might waste time on things that later need to be improved or replaced. After all, “Every person you hire who is not a top player is like having a leak in the hull. Eventually you will sink” (Jon Soberg).

Magic doesn’t happen overnight. So, do yourself a favor, don’t rush things through!

Unrealistic client expectations around what will be delivered and when are usually set without considering the solution complexity and the volume of work that needs to be done. Rushed and overly ambitious projects put too much pressure on the team. Your provider might agree to an optimistic schedule and struggle to deliver on time, but this is where corners get cut, tempers become frayed, and issues crop up.

Keep it real. Don’t expect an 8-month schedule if the baseline for similar previous projects shows a 12-month lifecycle. If you set realistic timeframes, including buffers for testing, it will smooth the roll-out of the project and minimize the overall stress.

“Failing to plan is planning to fail’, so you’ll have a lot of planning to do. At the same time, you can’t map out every single detail, because you want to be agile. First up, to avoid an expectation mismatch, the buyer and the provider need to work towards a shared vision of the ‘what’ and ‘when’. It’s a good idea to start with a minimum viable product that has only the most needed functionality. It will help you identify the best direction for your solution development without falling into the trap of feature bloat. Next, divide your project into logical phases and create a clear milestone chart to fix goals and deadlines. Finally, set benchmarks and identify progress markers.

You can’t ignore someone you hired, and then tell them off for churning out shoddy software. You don’t want to become a seagull manager who will be gone for days and then suddenly flies in, dumps criticism and leaves never to be seen again for weeks or months. Keep tabs on your remote team. Don’t expect them to be totally self-directed and able to figure out everything on their own. It won’t bode well for a happy outcome. Instead, be there for your people whenever they need you.

Before your programmers write a single line of code, guide them through a discovery phase. You can’t really document everything about a system up front, but you can specify just enough to move your development crew in the right direction. A functional specification usually describes how you want your software to behave when your customers use it. Take the time to run through this document with your technical leads and see if they ask the right questions and clarify things when needed. And remember: It’s not what you say that matters. It’s what they understand.
Lastly, keep revisiting requirements, refining the process and reassessing expectations along the journey. Lack of dialogue between sourcing partners and their clients kills more projects than anything else. To safeguard against this happening, make regular and thorough communication a priority. It will help you stay on top of things and identify room for improvement. Encourage your team members to come forward, express their reservations and offer suggestions.

No, you absolutely cannot! All too often, testing takes the back seat to coding, which leads to sloppy code and buggy apps. Without testing being tightly integrated into the entire software development lifecycle, you’re not going to know what’s truly going on and how to handle newly arising problems.

Ensure that your vendor gives testing an equal importance and have them walk you through their product quality control processes. It’s critical to test not only the functionality of the software but also the quality of the code. Test your app thoroughly at each pre-defined milestone and rest assured that issues will get spotted and bugs worked out before the system is ready to go live.

Customers blame subcontractors for overpromising and being unqualified to do the job. Outsource vendors complain they weren’t given proper instructions at the outset or project requirements were changed mid-stream. Finger-pointing has to stop. When things go off the track, it’s easy to attack someone else. With so many project flameouts, suppliers may come across as irresponsible and incompetent. But can you blame it on the provider alone? At the end of the day, it is a two-way partnership in which both parties share responsibility for the project’s triumph or agony. More often than not, the onus is on the client to prevent the project debacle and facilitate success in any way possible.

Instead of playing the blame game, take a step back, sit down with your provider and do a post-mortem. In hindsight, what rocked and what sucked? Why did it go awry? What would you do differently, if you had to do the same thing again?

By no means is this list of wrong mindsets exhaustive, but it may serve as a good starting point for making your subcontracting experience more effective and hassle-free. Steer clear of these reefs, otherwise, they can cause your business to capsize. It’s true that outsourcing might hurt you if done wrong. But the good news is that the final outcome is within your grasp. With a competent partner on your side, proper planning and ongoing communication, you can overcome those odds and set your project up for success.

So, welcome onboard! Bon voyage!

For more outsourcing tips, check out our piece on building a better business with outsourcing.

READ ALSO

• In-house Development Vs Outsourcing: How To Deal With The Staffing Dilemma
• Outsourcing Vs. Outstaffing Vs. Development Center In Ukraine: Which Is Your Call?