Managing outsourced teams. Balancing innovation with predictability.
December 19th, 2006
In the old days, when people talked about remote engineering teams, the first image the came to mind was a group of engineers in India that would use BBS to download the source code produced during the day in the US, then worked on the project and send back the source code to the US. This process created an illusion of parallelism. People would work regular ours in both offices and still be able to produce code up to 24 hours per day.
Then the Internet boom came along and the telecommunication market was operating with the assumption that the demand for Internet bandwidth would continue to grow indefinitely. At the same time, the need for engineering talent increased rapidly. This need, was addressed initially by importing brains and in a second phase by the explosive creation of remote engineering teams everywhere.
The so called “offshore teams” offered access to engineering talent with promises of substantial cost savings. The main force that kept these teams together was the hope to convert company stock options into cash. In many ways, if you had a team, it was relatively easy to keep it together. Today most organizations have to assume that the engineering team will be distributed geographically. However the old “two work shift” model is not as effective when we use more dynamic engineer life cycle models like Agile and RUP.
Suddenly, the time zone difference that allowed India to flourish as the Mecca for remote teams becomes a serious limitation when iteration is possible and desired.In normal market conditions engineering organizations can benefit of a more comprehensive long term engineering planning regarding managing remote teams. In this context, let’s define the problem. Nowadays, cost reduction is the prominent factor that motivates having an offshore engineering team.
In order to reduce cost we have to avoid turnover and plan for long term relationships. We also must manage risk by reducing the financial impact in the event of turnover. We need to have a consistent metric to evaluate performance of these remote engineers. On top of all of this, it’s important to realize that there is an additional constraint imposed by the limited communication channel between these two points either by distance or by time zone difference. We could restate this objective goal in a more condensed form like:
“Our goal is to reduce cost by creating less expensive engineering operations that will be managed remotely across a limited communication channel”.
Let’s now list the key factors to be managed:
- Communication efficiency
- Intellectual property risk
- Turnover risk
- Consistent metrics
There are two classical approaches in creating remote engineering organizations: “Assembly Line” and “Extended Team”.
1. “Assembly Line”
System requirements will be created in great detail and sent to the remote office that will assemble the software artifacts according with the specifications defined. This approach focuses on risk control and consistency by creating a very formal and predictable communication channel with the remote team. It also uses objective metrics to assess performance.It is the simplest model to configure and the most time consuming to maintain.
It requires impeccable requirements prepared by experienced professionals on the more expensive side of the fence. It can potentially create finger pointing situations where the implementers argue that the spec was wrong while the other side argues that the requirements were not followed.
2. “Extended Team”
Functional requirements will be defined and sent to the remote team that will come up with a system requirement document and/or prototype to be approved by main office.This approach values collaboration and long term relationship with the provider by changing the type of information that needs to flow through the channel and also by creating a more trusted environment.
This adjustment is made by communicating guidelines instead of rules and letting the provider derive the rules and be part of the group that innovates.
If the remote team is has similar capabilities when compared with the local team, Risk can be also reduced by having a backup organization operating remotely. On the other hand it Intellectual property risk have to be managed in order to keep the “company jewels” safe. This approach creates a more sustainable model for the remote team since there is a career path on the remote side.
Based on my experience managing high tech offshore/outsourced projects in the last fourteen years, I believe that the best way to go about this problem is to create a remote engineering organization is by starting on the “Assembly Line” mode and transitioning to the “Extended Team” mode as soon you feel confident on the capacity of the remote team.
Entry Filed under: Ideas, Outsourcing
1 Comment Add your own
1. Mohan | December 27th, 2006 at 8:10 pm
Interesting viewpoints, very succinctly put!
I have also expanded the concepts of Communication efficiency and Extended Teams in detail in my recently published book “Offshoring IT Services”
Leave a Comment
You must be logged in to post a comment.
Trackback this post | Subscribe to the comments via RSS Feed