Outsourcing Tips: What Not To Do

There’s tons of advice on how to successfully outsource. But what about outsourcing tips that tell you what not to do? With years of experience, Accelerance can advise on what not to do when it comes to outsourcing software.

One major mistake is a lack of good collaboration. While companies do their due diligence in setting up goals for their outsourced teams, many just supply the requirements and walk away hoping the code that comes back is what they wanted. No collaboration is a recipe for disaster.

Define "Done"

You should stay involved in the software development process at all times. After delivering the requirements, check in frequently to make sure your outsourced team is on track. In an earlier Accelerance video, outsourcing gurus Steve Mezak and Tom Cooper talked about treating your outsourcing effort as a covenant rather than a contract. To be successful, stay involved in the entire outsourcing process

“If you're not clear about what exactly you want, if you're not communicating clearly about exactly what you want, if you have this us versus them, then you have to be careful, because it's pernicious,” Tom says.

Although we do our best to set goals for the software and manage our teams effectively, there’s always the risk of micromanagement. The process of coding is creative, and if your requirements are too specific, you limit creativity.

Both Steve and Tom warn tech leaders against limiting the creative process. With the sheer amount of software out there, creativity is key to creating successful software. It might actually be more important for both sides to define when “done” is done, meaning the software is a finished product.

“I think the biggest issue in any software development effort is when you're talking about an outsource arrangement. When I think done is here and you think done is there, and I'm saying, ‘here, let me hand this to you, it's ready’ and you look at it and you say, ‘Tom, it's not ready,’” Tom says.

Although you might have almost completed the project, wrapping it up could become complex if you don’t have clear end goals. “It has to be some sort of minimal acceptance test or a smoke test. Don't even give me the code until it passes these basic tests,” Steve argues.