On March 30th CIO magazine published an article titled Do’s and Don’ts of Outsourcing Benchmarks. The article spurred us to write about outsourcing models for product development – it is otherwise unrelated, but interesting. [2015 Edit: The CIO article has been removed, check out these lessons from successes and failures instead]
Explaining Four Application Development Outsourcing Models
Outsourcing software development is different than outsourcing services like call-center operations. There are people who interact in several different roles in software development.
There are two distinct types of outsourcing. Bringing experts into our company, or sending work out of our company. Experts who join our team are “temporary team members” not “outsiders.” Sending work outside requires that we address several issues in communication, expectations, and accountability.
We will focus on the models for sending some of the work outside our company, to a team that operates in a very distant location and timezone.
We’ve described the software development process (from market opportunities to delivered software) in several posts in detail including Software development process example and Where bugs come from. We’ll provide a brief overview of the flow only in this post, with some simplified versions of roles in the process. This post is focused on the communication elements of handing off responsibility.
In the following diagrams, each area (dashed-line border) is the responsibility of the person within the area (developer, QA, etc). All of the maroon arrows represent transfers of information or responsibility within the organization. Any blue arrows represent communication with outsourcers, who are accountable for the next step in the process. Outsourcing rectangles have a light blue shading. Note that feedback loops are not drawn, but are important to success. Details on feedback can be found in the previously linked posts.
In each model, we list a key to success which targets the largest additional challenge of each model. Each model still otherwise faces all of the challenges of developing great software. As such, we don’t list a key to success for model 1 – that’s our baseline.
Model 1: Insourcing
Keeping all of the work in house, and in nearby timezones (geographic split of the team is ok, as long as they have >75% overlap in working hours). Communication between members of the team is important, and clear lines of responsibility are drawn.
Model 2: Low-level outsourcing
The first step most companies take to outsourcing is to send the “boring” or “unchallenging” or “low risk” work to an outside company. This model is shown in the following diagram, with QA and development outsourcing of the implementation and testing steps.
The key to success with this model is in execution management. Code reads and validation that everything designed has been implemented.
Model 3: High level outsourcing
Additional responsibility (design) and more abstract tasks are transitioned to the outsourcing firm – usually after they have demonstrated the ability to execute on lower-level tasks.
The key to success with this model is the technical communication and interaction between the architect-level developers and testers who are responsible for interpreting the PRD, and their outsourced counterparts with design responsibility. These in-house technical people will approve the code-design and test-designs proposed by the outsourcing team.
Model 4: Complete technical outsourcing
Companies sometimes establish a mantra like ‘All technical work will be done in India’. Their process model looks like the following, where documented requirements are delivered to the outsourcing team, who interpret them, design and implement.
The key to success with this model is having a trusted partner, a great PRD, and extremely good communication in the validation of the interpretation of the specifications.
The best process will vary depending on the makeup of the organization, the goals of the business, and the nature of the project. There is no single right answer.
[Update] Follow-Up Articles
We’ve written some additional, in-depth articles specifically about how to make these different models work. These articles focus on actionable strategies for making the models from this article work for your team.