Quite interesting article. I agree very much many points of the article, especially the point that failure is not only on the vendor side. Managing the offshore development effort is quite challenging at times. Many development managers feel that they can "throw the requirements" over seas and expect magic.

I believe that one of the important aspects of managing the offshore relationship involves doing the indepth architecture and design onshore. This way the offshore developers do just that "develop" based on the established design.

In implementing over 2300 (twenty-three hundred) projects (about 60% have been sent offshore), I noticed that sending off "just the requirements" offshore is very dangerous and has decreased the success factors.

Great points. Here are some tactics that have worked for me:
i) I prefer to outsource projects that can be easily specified in an unambiguous fashion (example: UI design) rather than projects where it can be difficult to measure the output (example: algorithm design where it can be difficult to evaluate whether the algorithm is efficient enough).
ii) I prefer to chunk up projects. This way I end up with weekly deliverables that my team can evaluate on an ongoing basis and track success. This approach also has some IP protection advantages. I recently chunked up a project and different parts of it got done by 3 different vendors in China, Brazil and Canada. The core algorithms got done by my own team. This way, none of the outsourcing firms gained access to any valuable IP but we were able to significantly accelerate our development.

One missing point seems fundamental to me, and that is communication. I assume that you are implying it in "vendor management", but it deserves a paragraph, if not a post or even a full Blog!

My observation is that the communication should be established at two levels:

- Formal one, through the usual tools, for managing the project, etc. In our company we are using wikis and blogs, which “force” the parties to communicate in a more interactive way. We found that emails and other structured software were inhibitors
- Informal ones. There is much more than a time difference problem between the clients and their offshore centers; the difference in culture is way bigger, and the ability to communicate in English is not sufficient for people to truly understand each other. We have developed internally some tools and techniques that help people understand each other’s culture and behavior better. We found it a very efficient way to get all parties involved to accept the cultural differences more easily.

Hi Mike,
Great Article! Thank you so much!!!

I'm the CEO of a company consulting our clients (large OEMs in US and EU) in how to make off-shore engineering and TechPub projects successful. We are dealing with exactle the same issues in engineering as you explained with your 3 case studies. TechPub seems to be a little easier and more mature, but it is still difficult to get the deliverables on-time and on-quality.

A lot of our clients only look at the hourly rate when they try to quantify savings. We have implemented several FFP projects and had excellent experience with this. How do you normally structure payment in IT? Do you guys work on a FFP or T&M basis?

Again - Thanks for your article!
Oliver