Sourcing Pitfalls
Last week in my Blog entry on sourcing, I gave a success story. This week I want to focus on some of the pitfalls of development off shore. No, this is not a failure story, but it expands on the explanation of some of the areas that are barriers that have to be overcome or avoided.
It is tempting to focus on the cost of development and look at the hourly wage of the resource. When you compare twenty dollars and hour or less to numbers four to five times that number, it is easy to set expectations for savings that are unrealistic. One of the consistent temptations for technologists is what Chairman Alan Greenspan of the Federal Reserve referred to as “irrational exuberance”. The times that I have gotten into trouble in my career are the times that I believed my own hype and oversold the benefits of a proposed project or direction. Kind of like the economy did back at the turn of this century when the bubble burst.
In many companies in America, change happens at a very fast pace. We, in America, pride ourselves on our flexibility. I remember my frustration thirty years ago trying to mange development projects in the then common “waterfall” methodology. For those of you that learned about the sixties and seventies in textbooks – or on the History Channel, the waterfall methodology was one in which projects progressed sequentially until they finished by “falling over the waterfall”. It was aptly named – often times it was like going over the falls in a barrel because the requirements changed over the lifecycle of the project. And they were discovered at implementation. It turns out that the requirements that were signed off on in the first phase of the project – the requirements phase – changed in the months (or years) that it took to get the product complete and installed.
Today, it is often easier to develop systems using a variety of iterative construction techniques – but these are best applied when the project team is very close to the users. In the fast pace change of America, it is common for systems to be changed significantly during the development effort – especially if the methodology supports rapid prototyping and extensive user reviews.
Implementing these techniques with facilities that are half way around the world and in which language and culture are different can produce business systems that do not meet the real user need – because that need was lost in nuance. We in America understand our culture – we understand that the newspaper headline of “Bucs bomb birds” during football season indicates a good day for the Tampa Bay Buccaneers (aka “Bucs”) and a bad day for Philadelphia Eagles (aka “Birds”). Of course if the World Series was going on and however unlikely it would seem right now, the Pittsburgh Pirates beat the Baltimore Orioles – what was the real story – football – or baseball? You have to understand the nuance of the comment and the context of it.
We in America, understand the nuance of the way that we communicate, people not familiar with our culture do not. They do not. Even here in the states, it is not uncommon for a new analyst or programmer to not understand jargon – I remember a new analyst in my own career in technology who did not understand what a PO (purchase Order) was and was afraid to ask. Here the answer was provided after the meeting and the requirements were captured. How does that happen off shore?
Well, it can happen, but it has to be planned for. We used a daily call to make sure that all questions are answered. Often times that meant that we had to create and answer the question. In America we are “in your face” people. Other cultures want to save face, and not look foolish. I learned that yes does not mean yes. In some cultures it means that the person understands – not that they agree. In other cultures – it can mean that they do not want to argue – they might not even understand. For an excellent primer on cultural differences the book Kiss Bow or Shake Hands by Terri Morrison and Wayne A. Conaway helped me greatly.
So in addition to making sure that we were clear in requirements, we avoided areas that were fuzzy. We created those components in the states where people were closer and could interact with the users of the products or services.
In order to put together a project team to support this type of project we found that we needed two teams in Asia of five to ten people, a full time manger in the states who worked across the two Asia teams and provided direction and issue resolution and a team in the States to define requirements, and test criteria as well as perform the integration testing and implementation. I would recommend that your on-shore team also fully understand the technology that has been developed so that critical issues can be fixed – especially during Asia holidays and weekends that do not map to our own. When a problem arises – make sure you have an answer to “who are ya goin call?”
All of this points to an interesting realization – if you do not have a large project – the cost benefit of going off-shore is not really realizable – perhaps savings can be had by engaging a company that provides local support in an affordable fashion. Next week we will look more closely at trends in this area.
Fred Geiger
www.dharacg.com
It is tempting to focus on the cost of development and look at the hourly wage of the resource. When you compare twenty dollars and hour or less to numbers four to five times that number, it is easy to set expectations for savings that are unrealistic. One of the consistent temptations for technologists is what Chairman Alan Greenspan of the Federal Reserve referred to as “irrational exuberance”. The times that I have gotten into trouble in my career are the times that I believed my own hype and oversold the benefits of a proposed project or direction. Kind of like the economy did back at the turn of this century when the bubble burst.
In many companies in America, change happens at a very fast pace. We, in America, pride ourselves on our flexibility. I remember my frustration thirty years ago trying to mange development projects in the then common “waterfall” methodology. For those of you that learned about the sixties and seventies in textbooks – or on the History Channel, the waterfall methodology was one in which projects progressed sequentially until they finished by “falling over the waterfall”. It was aptly named – often times it was like going over the falls in a barrel because the requirements changed over the lifecycle of the project. And they were discovered at implementation. It turns out that the requirements that were signed off on in the first phase of the project – the requirements phase – changed in the months (or years) that it took to get the product complete and installed.
Today, it is often easier to develop systems using a variety of iterative construction techniques – but these are best applied when the project team is very close to the users. In the fast pace change of America, it is common for systems to be changed significantly during the development effort – especially if the methodology supports rapid prototyping and extensive user reviews.
Implementing these techniques with facilities that are half way around the world and in which language and culture are different can produce business systems that do not meet the real user need – because that need was lost in nuance. We in America understand our culture – we understand that the newspaper headline of “Bucs bomb birds” during football season indicates a good day for the Tampa Bay Buccaneers (aka “Bucs”) and a bad day for Philadelphia Eagles (aka “Birds”). Of course if the World Series was going on and however unlikely it would seem right now, the Pittsburgh Pirates beat the Baltimore Orioles – what was the real story – football – or baseball? You have to understand the nuance of the comment and the context of it.
We in America, understand the nuance of the way that we communicate, people not familiar with our culture do not. They do not. Even here in the states, it is not uncommon for a new analyst or programmer to not understand jargon – I remember a new analyst in my own career in technology who did not understand what a PO (purchase Order) was and was afraid to ask. Here the answer was provided after the meeting and the requirements were captured. How does that happen off shore?
Well, it can happen, but it has to be planned for. We used a daily call to make sure that all questions are answered. Often times that meant that we had to create and answer the question. In America we are “in your face” people. Other cultures want to save face, and not look foolish. I learned that yes does not mean yes. In some cultures it means that the person understands – not that they agree. In other cultures – it can mean that they do not want to argue – they might not even understand. For an excellent primer on cultural differences the book Kiss Bow or Shake Hands by Terri Morrison and Wayne A. Conaway helped me greatly.
So in addition to making sure that we were clear in requirements, we avoided areas that were fuzzy. We created those components in the states where people were closer and could interact with the users of the products or services.
In order to put together a project team to support this type of project we found that we needed two teams in Asia of five to ten people, a full time manger in the states who worked across the two Asia teams and provided direction and issue resolution and a team in the States to define requirements, and test criteria as well as perform the integration testing and implementation. I would recommend that your on-shore team also fully understand the technology that has been developed so that critical issues can be fixed – especially during Asia holidays and weekends that do not map to our own. When a problem arises – make sure you have an answer to “who are ya goin call?”
All of this points to an interesting realization – if you do not have a large project – the cost benefit of going off-shore is not really realizable – perhaps savings can be had by engaging a company that provides local support in an affordable fashion. Next week we will look more closely at trends in this area.
Fred Geiger
www.dharacg.com
Comments