Four outsourcing models for software development

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.

This post is about outsourcing software product development

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.

Process overview

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.

insourcing

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.

low level outsourcing

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.
high level outsourcing

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.
complete technical outsourcing

Conclusion

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.

source post [tyner blain] 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: