Should You Outsource Software Development?

Outsourcing by offshoring IT services has become a common phenomenon in almost all industries. More common is a growing concern, among the companies offshoring software development, around the quality of development done in such a model. Resulting conclusion is that software development cannot be offshored or even outsourced.................Do you agree?

To cut this long story short, this article is all about answering this question. I firmly believe that remote sourcing of quality IT services requires discipline and a structured approach in both client and service providing organizations. If the companies do not have that, outsourcing will not work well irrespective of the nature of service procured - stuff augmentation or managed services - OR the nature of contract - cost-plus, time & material, fixed-bid etc.!!

Having worked for services company as well as companies outsourcing IT services, I have keenly observed certain parameters of success and failure - some of which were sometimes learnt the hard way.

At the outset, I must say that the general uproar around the quality of outsourced software development is a manifestation of a much deeper problem of information asymmetry, expectation imbalance and distorted incentives.

Consider an example:

The client company wants to reduce software development costs. The higher management  invites bids or negotiates a deal with an IT service provider.

This specific example of a top down approach on both sides of the transaction results in an interesting dynamics:

The IT provider also has to think about profitability. This causes the provider to  include many less experienced professionals in its service pool - could be after adequately training them. But no matter how much training is provided to junior employees and how intelligent they are, it is mostly very difficult to substitute professional maturity, discipline, implicit domain knowledge, and communication skills of experienced professionals. This sort of decision may result in a very young offshore development team with all senior/experienced professionals taking up various delivery management positions.

Now, let us come back to the client side. What is the expectation here especially at the level where the service providing development team interacts with the IT Analysts of the client organization? One would usually find experienced to highly experienced professionals on the client IT side who would expect a certain level of maturity, ownership, self-organization, and obviously good technical skills from the external offshore technical team. Given the scenario I have just discussed do you think the expectations are easily met?

I do not claim this is the only scenario but this is definitely one of the many.

No one can deny the inherent benefits of agile and iterative development methodologies. But I have also seen such methods fail miserably when forcefully fitted into such an outsourcing model discussed above. Do you know why?

 One of the core principles of agile manifesto is: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." Ref: <http://www.agilemanifesto.org/principles.html>

It is said that as human beings we cannot master all of the following skills: reading, writing, listening, talking. One is always the best in only one or some of these communication skills. Now think for a second how you discuss and share requirements with your offshore development team? Do you send the requirements over email assuming  you have done correct requirement gathering and a perfect job of writing? And then do you assume that the offshore team has rightly read and understood the requirements? After all, the service providers are responsible for interpreting the requirements and asking questions if necessary for clarification.

Unfortunately this never happens and the entire house  of cards of assumptions collapses very subtly but very soon.

Outsourcing software development should not be looked upon as a simple risk transfer but more as a joint venture where you either understand the inherent negative dynamics and take measures to workaround them, or you make sure that you eliminate  all negatively impacting characteristics. Let me discuss some of these in light of the ideas I discussed in my previous post "Choosing Smart Development Frameworks":

Idea 0: Understand the big picture of what you need to deliver

Everyone in the development team needs to understand this - internals as well as externals (professionals from the IT service providing organization). The product owner and/or the architect should have one or more interactive kick off sessions to explain this.

Idea 1: If you get a chance to choose your team , choose well ! 

Do assess the required skills before choosing the team members. The project lead should decide the level of experience and skills  she or he should have in the team. One needs to make sure that there is always at least one external senior developer at onsite who works with the team in offshore. The position should be rotated with other external offshore team members so that everyone in the external team knows each other as well as the team members from the client organization.

If your project (or a sub project) is a very short one (less than 3 months with multiple developers), work with an onsite development team ONLY. It requires time and effort to develop and implement a structure compatible to offshoring. Short projects can often not afford that.

Do note that by onsite I am referring to the client office which can be anywhere in the world where you have some of the other core team members of the client organization. So if you want to reduce software development costs in the long term it is also helpful to consider building software development offices (sometimes referred to as captive units) in locations where your strategic vendors are. You can reap benefits of onsite development at a lower cost. However, this is another tactic by itself which has to be thought through carefully.

Idea 2: Even if you don't get to choose, make sure you spend time understanding the members in your team, stakeholders and processes.

It is important that cultural mix of the resulting global team is understood properly by the team itself. As discussed before, do understand the maturity and experience of the team you are working with. Do not walk in with assumptions.

Idea 3: As a team have the "same" understanding around the details of the deliverable.

This is the most critical piece as this is where we mostly fail. It is also recommended to have the core design or proof of concept done onsite involving both internal and external team members.

Developers working out of offshore in the subsequent phases should travel, at least on a round-robin basis, to work with the core design team over the course of the project.

Idea 4: Understand organizational bottlenecks

It is important to understand the bottlenecks in both the client and service providing organizations. Sometimes this cannot be immediately avoided, but if recognized early can be mitigated immediately and avoided in the long run.

Idea 5: Build a smart delivery framework.

If it is a big project, you can hire a software development coach who can help you to be as much agile as possible. The goal is to do a test driven development and be flexible enough to manage and quickly respond to end-customer needs which are sometimes evolving.

The above ideas are necessary but may not be sufficient to ensure quality software delivery. But they do help to address some of the lurking problems that make outsourced software development difficult. They help to facilitate quality development but definitely it is the team which delivers results!