15 Tips for Outsourced Software Development Success

These tips might keep your outsourced or packaged solution projects from winding up in litigation.

Image by wirestock on Freepik

Many companies outsource their software development projects, often to offshore suppliers. Others are replacing custom green-field development with commercial package solutions, which they — or the vendor— must customize, extend, and integrate into their application environment. Failed outsourced or contracted package projects sometimes result in lose-lose litigation. Lawsuits often indicate that the acquirer failed to act on early warning signs, instead simply hoping for the best.

Here are several practices that just might keep you and your supplier out of the courtroom. I’ll use the fictional acquiring company Unfortunato Ltd. to illustrate experiences that I’ve observed on real contract development and package solution projects.

Define Expectations

The ultimate cause of a project failure is that one — or both — party’s expectations are not satisfied. The acquirer has expectations regarding the solution’s capabilities and quality and the project’s cost and schedule. The supplier has expectations regarding the information and materials that the acquirer will provide. Both parties have expectations about the nature of their collaboration. Unstated expectations can lead to erroneous assumptions, unfulfilled dependencies, unexpected risks, and disappointed customers.

To lay the foundation for an effective outsourcing experience, document the requirements thoroughly and precisely. Real-time, face-to-face interactions are ideal, but this is less feasible when acquirers and suppliers are many time zones apart. Requirements will change as your mutual understanding evolves, so a written specification cannot replace regular communications. However, many projects stall because of vague, incomplete requirements and the unplanned time that’s needed to clarify ambiguities and close the gaps. To maximize communication effectiveness, have both acquirer and supplier staff participate in requirements definition and review.

Try to avoid implied or assumed requirements, which rely on telepathy and clairvoyance — not a sound foundation for requirements…