Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Programming IT Technology

Managing a Global Programming Team? 737

Posted by Cliff
from the telecommuting-taken-to-the-extreme dept.
cwimmer asks: "I work for a technology company in the United States who survived the economic slowdown by trimming fat where necessary. Unfortunately, it seems that my small programming team must've looked like mostly fat to management: it has been trimmed from a high of 5 to the current 2. We have been given a very large programming project that we estimated would take 4 coders (the size of the team at the time) 6 months to deliver. I have been given deep pockets with regard to moving some or all of the project to an offshore partner, and I can probably get 4 or 5 programmers in India. Does anyone have any pointers on managing a team of programmers on the other side of the world?"
This discussion has been archived. No new comments can be posted.

Managing a Global Programming Team?

Comments Filter:
  • Yes. (Score:2, Funny)

    by Wakko Warner (324)
    Learn to speak Hindu.

    - A.P.
    • Re:Yes. (Score:3, Informative)

      by BluedemonX (198949)
      Don't you mean Hindi? Hindi's the language, Hindu the religion.
      • by 56ker (566853)
        But on a more serious note I would've thought there are plenty of available programmmers in the US since the dot com crash. How about getting in touch with the programmers that used to work in your team and seeing if they're available?
    • Re:Yes. (Score:3, Informative)

      by 2br02b (448267)
      It's Hindi, not Hindu. And programmers from the south of India (where the IT boom is mainly concentrated) are likely to be more comfortable with English than Hindi.
    • by 56ker (566853)
      But on a more serious note - what's to stop you hiring more programmers on short-term contracts or freelancers instead of out-sourcing to a foreign country?
    • Re:Yes. (Score:3, Informative)

      by durdur (252098)
      English is commonly used as the language of instruction in Indian universities. Assuming you are hiring college graduates, they will likely get along ok in English.

      India has 14 official languages. Hindi is widely used but is not the native language of many Indians and is not even related to the languages spoken in South India.

      So, while it would be commendable if you learned an Indian language to communicate better with your staff, you might have to learn several if they come from different regions of India. Not very practical IMO.
    • Re:Yes. (Score:2, Funny)

      by viperstyx (578360)
      HEY! im indian! and the dot is just jewelry. its like earings, just a dot instead. and yeah dont ask about it. since every body decided to tell you that its hindi not hindu im not gonna tell you too. well, just a tip for managing programmers. you could setup a web server and use a bunch of microsoft tools that come with winxp to setup a vpn and have your entire project on the web. of course it could be secured using all kinds of stuff. then users can make updates etc. also, you could use remote desktop to do stuff from long distances with eachother, like looking at other peoples code etc. aim could be used for conversations. it can get pretty intricate if you want it to be but if you really really wanna do this it would not be hard to make it seem that you guys are just a block from eachother rather than 4k miles. i suggest consulting with an msce or someone who is certified with networks and communication using computers. i garentee you can find a way to do it easy. -aroon
    • by dahlgren (579679) <kentNO@SPAMcascadia.net> on Wednesday May 15, 2002 @06:58PM (#3526737) Homepage
      Bottom line: if you do it right you get what amounts to near-round the clock development at a fraction of the price. If you screw up, even as little as twice a week, you lose a week of development, and sometimes more.

      Background: I've invested five years involved in the management and growth an Indian engineering team, and spent one year working for an engineering company based in Bangalore. I'd like to share some real experience and raw numbers for educational purposes.

      First off, two things compel management to explore Indian development as a viable option:

      1.) Cost savings
      2.) They speak English

      First, cost. The burdened rate for your average full time US software developer currently runs around $30-$50 an hour. (Burdened rate= hourly expense to the organization, which includes hourly wage, PLUS hourly breakdown of benefits, PLUS hourly breakdown of an individual's share of the operating expenses, calculated roughly as "AnnualExpenses / NumberEmployees / 2080", 2080 being full time work including vacation and all that.)

      The burdened rate for your average web developer in Bangalore India runs anywhere from $6.50/hr USD for entry level engineers to $20/hr USD for intermediate host software end embedded engineers. Note that Bangalore is perhaps one of the more expensive markets for developers, certainly more so than Chennai and in Hyderabad (see below for regional discussion).

      Quick - do the math. From a cost accounting perspective this makes loads of sense. The devil, of course, is in the details.

      Next issue: "they speak English." That is true, but in the south, where the "High Tech Triangle" is defined by the cities of Bangalore, Hyderabad, and Chennai, often they speak Kannada or Tamil first, THEN they learn Hindi and English in school. Sometimes English isn't even their second language.

      At this point many laugh and point out that there is then no way one could hope to understand these people, but that's an oversimplification. I've yet to have an experience where I've been unable to understand what an Indian Engineer is telling me.

      Where this becomes an issue is where communicated expectations and requirements are sloppily conveyed verbally or through informal channels, such as Email. This audience of any should know to manage requirements well, but I've seen this mismanaged repeatedly.

      Number 2 on the aged list of "Sex Best Practices of SW Development" states one should "manage requirements." Working with teams in remote locations, regardless if they are across the country or around the world, will fare far better if you nail this essential rule.

      What happens if you don't manage your requirements? I encourage anyone to try working for a US company while located in a remote office...or even managing your project while on the road and working out of a hotel room. Working in India is often like working at the end of a 10K mile whip. Most people forget that hallway conversations don't make it to your remote office.

      One more point on requirements: make sure your specifications include a definition of UI, preferably developed in the market where the product will be used, and look into using a string table to manage your strings, which helps greatly in your localization efforts. I actually make these recommendations regardless of where the SW team is located. Since when have traditional SW developers created winning interfaces?

      If an Indian engineer has been toiling to get into SW development since they were 13 years old, how would they gain the experience to know what UI is intuitive? And even though developers have a good command of the English language, don't expect them to fix typos in your strings...which is why a string table is often better.

      This is actually a huge issue, but in summary, nail your requirements and you come close to nailing this whole "they speak the same language" deal.

      Finally, don't be shy to call during their operating hours, which on the west coast is 11.5 hours off. The work day typically begins at 9-10 am, and continues till 7-8 pm. Lunches are at noon or 1, and there is a coffee time taken at 3 or so. A phone call will nail close to every issue, far more so than an Email.

      Finally, know your regions and how to take advantage of them. The "High Tech Triangle" is getting pretty sophisticated and therefore expensive, relative to other developers in other areas in India. Step outside this triangle and find some fat development deals, such as Profluent (not the one in San Jose), who is located outside this region and therefore hit even harder for business than those within, but my getting access to Profluent came through a strong personal relationship I have there. It pays to network.

      Bottom line: process exists to negate risk, so evaluate the risks, then staff and define processes as appropriate. If I were to do it all over again, and I am, I'd invest in a project manager whose not afraid of 36 hour flights and 2 am calls, and I'd work with a smaller development shop before I'd work with a large one, for reasons I'll not enumerate here.

      I'd like to end by sharing why I continue to chose native Indian developers for personal start-up ventures involving my investments: the developers I know there exceed the technical sophistication of domestic US resources. Too many American engineers smugly avoid cramming on diverse topics, a skill learned in the high-stress schools that weed our slackers. If I want good engineering work I call my friends in India.

      I hope this has helped.

  • by FortKnox (169099) on Wednesday May 15, 2002 @12:06PM (#3524155) Homepage Journal
    This is a good time for OSDN to push their "Sourceforge 3.1" software! Unite everyone globally with one piece of software!

    Keep click "refresh" on this story (don't forget to use those slashdot subscription pages) and see the advertisement for sourceforge!!!


    *ahem*
  • regardless. (Score:3, Insightful)

    by raindog151 (157588) on Wednesday May 15, 2002 @12:07PM (#3524164) Homepage
    regardless of costs, there are a heck of a lot of talented programmers here in the US who would take work.

    hire american.

    • Re:regardless. (Score:4, Interesting)

      by Telastyn (206146) on Wednesday May 15, 2002 @12:13PM (#3524236)
      Perhaps you could use those deep pockets to hire back the 2 fired programmers? 2 programmers you can actually talk to and design with are probably as productive, if not more, than 4 you can't communicate well with.

      • Re:regardless. (Score:3, Insightful)

        by jnana (519059)
        i agree with your sentiment, but in reality, 2 US programmers' salaries could get you at least 10 Indian programmers on the Indian subcontinent. That's hard to sell to management who only see $ signs and think that a programmer is like a lego block that you can interchange anywhere, all working as well as any other.
        • I guess nobody figures in the price of travel, communication, and coordination it would take to hire these 10 programmers. It is also risky since India is a third world country, and its neighbor is about to launch a nuke at it. I bet it will take a year or longer to deliver it just due to the coordination difficulty.

          The project manager at the place I work said he had to manage an Indian team while working at a previous company. He said it ran him ragged. If I were you, I'd tell management to just get the 2 guys back and forget the India idea. If they only care about the $, you might as well quit because you'll either die of a heart attack or will likely miss the deadline and get fired anyway.

          Or set it up so the management has to move to India....now that would be fun.

        • 2 communicative, accessible programmers are much more productive than 6 noncommunicative ones. We hired someone from China and someone from India and doubled our team size. Our productivity as a department hasn't changed one iota, because a lot of their time is spent trying to communicate ideas, make their documentation readable, and in general trying to cope with a foreign language and culture. We're no better off than we were before.

          If you had an entire team from one country, that would be different. Even more so if they had a spokesman who spoke english well. But mixing and matching with people that don't speak English well is really stresfull.

          My advice is to take your money and hire a starving college student or two. Hell, set up an internship and have them work for free (or give them ~$10/hr. They'll still love you). You'll get about the same quality code, much better documentation, and a lot less headaches.
    • I see them every day. Standing there with a "will program for food" sign.
    • by Anonymous Coward
      Why?

      Why should the nationality matter to me? All I want is the optimal price/skill ratio. I couldn't give a fuck if you're from bumfuck Somalia if your code is good, you finish it on time and don't ask for too much pay. Isn't that's what the free market system is all about anyway?

    • YES EXACTLY (Score:3, Interesting)

      by HanzoSan (251665)


      So why should we answer this guys question, Its just helping him fire us!! Let him go to indias version of slashdot and ask THEM!

      I'm sorry but I'm not stupid enough to help my boss figure out how to replace me.

      This is why I'm so against globalism, this kinda thing will happen all the time as globalism becomes standard.
      • by Anonymous Coward
        So why should we answer this guys question, Its just helping him fire us!! Let him go to indias version of slashdot and ask THEM!

        There is no India slashdot -- that's why they're more productive. Maybe you can keep your job by reading less slashdot and writing more code.
  • Its simple (Score:4, Funny)

    by Kenja (541830) on Wednesday May 15, 2002 @12:08PM (#3524169)
    You just need to learn how to shout "do it again but do it right this time" in several languages.
  • Effective Recourse (Score:3, Insightful)

    by ciole (211179) on Wednesday May 15, 2002 @12:10PM (#3524198)
    Either trust them or ensure that you have recourse against them. I've seen outsourced teams from India sign the NDAs, take some money, and walk away with the IP.
  • "Trimming fat". (Score:5, Insightful)

    by Gannoc (210256) on Wednesday May 15, 2002 @12:11PM (#3524211)
    I wish corporations had the balls to call it "Keeping money for ourselves" instead of "trimming the fat".

    Trimming the fat implies that everyone who was laid off was useless. Just globs of ugly fat slowing down the company. We were glad to get rid of them anyway. Thank God this financial crisis came along so we could get rid of those chunks of lard clogging the arteries of efficiency. Whew!

    It makes them feel much better about destroying lives.

    Plus, the people who remain feel good about themselves, because they were the "lean" not the "fat". They're so important they didn't get fired!
    • Re:"Trimming fat". (Score:4, Interesting)

      by SirSlud (67381) on Wednesday May 15, 2002 @12:20PM (#3524296) Homepage
      Consider this. If minimum wage had followed the meteoric rise of the CEO/Exec salary from the early 80s at the same rate, min wage would be 25$.

      Ever wonder why downsizing/timming the fat, etc, etc seems to be much more common these days? Well, the overhead for paying management is much higher, and as usual, the middle to lower tier pays for it by being subjected to trivilizing and belittling buzzwords designed to protect people from having to swallow the 'reality' pill.
      • Do you have a source/citation for that statistic? It would certainly make a nice little conversation-killer or rant ingrediant, and I'd like to be able to back it up with some cold numbers.
        • Do you have a source/citation for that statistic?

          It's most likely a simple transformation of the stats for the gap between the lowest and highest paid people in large multinationals (usually a minimum wage mailroom drone and the CEO). Observe how the gap has changed (possibly going from a factor of 40 to a factor of 200) and multiply that change by current minimum wage.

      • Consider this. If minimum wage had followed the meteoric rise of the CEO/Exec salary from the early 80s at the same rate, min wage would be 25$.


        I usually don't post twice in the same thread, but this needs to be commented on.


        If it HONESTLY DID cost that much to hire the best CEOs, then great. Good for them. They're worth it.


        But it doesn't. The salaries have grossly inflated in an "i'll scratch your back, you scratch mine" kind of way over the past few decades. CEOs of one company are on the board of directors for other companies and they've steadily upped their compensations.


        They're simply taking money away from the company and the stockholders at the price of their employees.

      • There have been a lot of mergers and corporate consilidation over the past 20 years. Is it possible this statistic is a result of new positions being created at management levels that previously did not exist? Let's say company A headed by Bob and company B headed by Alice merge to create company C. Now we require an entirely new layer of management. Eve is brought on to manage the joined companies and her salary is a good deal higher than that of Alice or Bob. As more and more companies merge creating more levels of management, isn't an increase in the disparity between upper level management and minimum wage workers going to naturally increase?

        • > isn't an increase in the disparity between upper level management and minimum wage workers going to naturally increase?

          Interesting thought. I suppose if you believe in that 'the more money you are responsible for generating, the more you make' rule of thumb, it makes sense from the stand point that as single entities take on larger market shares, than the dude at the top is entitled to make more, while the production line (well, if stuff was still produced on western soil ;) worker, the scope of his job not having changed, is paid the same.

          It could explain it, to some degree, although I'd argue that it doesn't make these people intrinsically deserve a disproportionately higher piece of the profit pie. And think that is responsible for only a percentage of the reason the disparity continues to increase. But thats another argument ... :)
    • Unfortunately, it seems that my small programming team must've looked like mostly fat to management

      Of course they did. I mean, all those penguin energy caffeine mints and bottles of Mountain Dew go straight to your thighs.

    • by asmithmd1 (239950) on Wednesday May 15, 2002 @01:02PM (#3524629) Homepage Journal
      With CEO salaries going sky-high it seems the market is sending us the signal that there is a severe CEO shortage. Why aren't we hiring CEO's on H1-B visas? I am sure we can get very talented managers from overseas for only $300k to $400k-the average CEO salary in Europe
  • Not too hard (Score:3, Insightful)

    by ebh (116526) <ebh-slashdot@hy p e r r e a l . o rg> on Wednesday May 15, 2002 @12:12PM (#3524222) Journal
    a 24-staff-month project is not what I'd call "very large", and that will affect how you manage it. The problem is that you don't have the calendar time it will take to get things running really smoothly.

    If you're treating the overseas programmers as an outsource, then the hardest parts will be nailing down the requirements, accepting code drops, etc.

    If you're treating them as staff with a really long commute, then the biggest problems will probably be language barriers and time differences. (Get REALLY GOOD at IMing!)

    In either case, it may also be tough to get test environments set up for the foreign staff, if it's not feasible for them to use your machines over a VPN or something.

    At least, this has been my experience, in a place that does both (development staff in three countries, and outsourcing from two offshore companies).

  • by Anonymous Coward on Wednesday May 15, 2002 @12:13PM (#3524230)
    Go to Slashdot, where there are undoubtedly a whole lot of North American coders looking for work, and ask them about some good ideas for getting cheaper labour overseas.

    No offence, but I hope you understand if some of us offer you NO HELP.
  • Look for a new job (Score:4, Insightful)

    by technomancerX (86975) on Wednesday May 15, 2002 @12:14PM (#3524237) Homepage
    I would suggest you start looking for a new job.

    How long before your firm realizes that they can hire a manager on-site in India for a fraction of what they're paying you and not incur the language barrier and communications problems?

  • Do not do it! (Score:5, Informative)

    by Ted V (67691) on Wednesday May 15, 2002 @12:15PM (#3524248) Homepage
    For the love of God, DO NOT DO IT! I've worked with or interviewed for positions at 3 different companies/departments that used off-shore india programmers. It was always a horrible experience. In each situation, after 6 months they said that hiring the offshore team actually hurt progress. That is to say, X programmers on site would have made more progress than X on site and Y offsite.

    I'm not sure what all the root issues are, but the time difference is huge. Get used to 9pm phone conference meetings. It was horrible explaining the software needs to the offshore groups. And fiunally, it's much harder to do quality control with people who aren't actually there. It's much harder to get them to fix problems when you don't have an in-person presence. Most programmers by nature get things done in the worst possible long term way. In the offshore situation, you will have almost no power to encourage them to create code that's built to last.
    • One more thing... (Score:4, Insightful)

      by Ted V (67691) on Wednesday May 15, 2002 @12:25PM (#3524337) Homepage
      One more thing. I agree with the others that suggest looking for a new job. If your management
      is giving you money to complete the software but then telling you how you should spend it (ie. india), that's a sign they don't really respect your management decisions. If they really empowered you and had trust in you, they would say, "Here is $X. It's your responsibility to get the project done."

      It seems like they won't accept any situatuion except one involving India programmers, and that is 99% guaranteed to fail. The failure will be blamed on you, you'll be out of work, and have trouble finding a new job (because of the previous failure which wasn't your fault).

      The mere fact that they fired your team when you said you had just enough for the project should let you know they don't really value your opinion. Find a company that respects you. They do exist.
  • International Teams (Score:5, Interesting)

    by glenstar (569572) on Wednesday May 15, 2002 @12:15PM (#3524249)
    I have had extensive experience with offshore development in Russia, India, Indonesia (don't even ask), and various Latin American countries. If I had to do it again, I would go with a Russian team over any of the others. A business associate of mine does a lot of work in Vietnam (he has a couple hundred developers there) and he seems pleased with the work quality and the *much* lower bottom line. Indian firms are now almost on par with American teams in regards to rates, so why even bother?

    But, as has been pointed out here already, there are thousands and thousands of US developers out of work, which makes it a buyer's market. To put it into perspective, a top-gun Russian developer is going to charge 25/hr. I am certain that you can find a comparable US developer right now to do it for approximately the same; plus or minus 10% or so. It's amazing, but even software developers like to pay their mortgage... ;-)

  • flamebait? (Score:4, Funny)

    by tps12 (105590) on Wednesday May 15, 2002 @12:15PM (#3524252) Homepage Journal
    Let me get this straight.

    You are asking a bunch of unemployed programmers how to best manage the foreigners you hired to take their places?

    Hope you brought your asbestos suit.
  • Yes. Don't. (Score:2, Interesting)

    by bratgrrl (197603)
    What a crock of shit. There's an abundance of able developers right here in the good old US of A. I hate this kind of crap, it doesn't work anyway, you'll spend the same or more money, with ten times the headaches. I've been through this twice- never ever again. It does not work.

  • dealing with an offshore programming team is no different than dealing with any other consultancy.

    Agree on the statements of work
    Make sure that the statements of work are adhered to.
    Smile and enjoy the fact that you're helping keep americans unemployed by implementing a plan which will not bring the savings you were hoping for.

  • Budget for travel (Score:2, Interesting)

    by MountainLogic (92466)
    Budget for a lot of travel on short notice. You will need "face time." Expect the trave to exceed what you will save in salary for such a small project. If you are hiring 20 or 20 programmers you might see a real savings if it comes out right. Also, plan on switching your US team to the graveyard shift so you can have enless phone calls with them. Been there, done that.
  • Quit (Score:4, Insightful)

    by 0xdeadbeef (28836) on Wednesday May 15, 2002 @12:16PM (#3524257) Homepage Journal
    Seriously, the people you are working for are incompetent. If you said it would take four people six months, then they should believe it would take four people six months. Whatever immediate savings are to be had by laying off three developers and hiring Indian contractors are going to be lost in the loss of experience with your product and the overhead of managing developers on the opposite side of the world. Give up, now.
  • by Anonymous Coward
    Slashdot is a wrong place to ask that.

    Over here everybody is a code-monkey who hates the managers because they have a (completely unnecessary) university degree, get paid better and are, in general, smarter and equipped with a better human-to-human interface.

  • (good?) Advice (Score:2, Interesting)

    by new_breed (569862)
    As a programmer whose company is thinking of hiring help from a local company that uses Russian programmers, I'd say: don't do it. The amount of complications possible by far outweighs the advantages (cheap!) in my opinion.. Like: -You've got your working program. But hey! there are two major bugs in it..but the offshore team is too busy with some other job, or are not reachable for some other reason. -From experience, everything you buy that is cheap at first, might turn out te be quite expensive later. I'd say, that might as well be true for hiring programmerskills. You're gonna need people to communicate to those programmers, even if they speak english or not. That person will cost money as well, unless you're willing to give up 70% of your own time to integrate, test, debug etc. the code you're getting from them. -Losing control! What you don't make, you cannot control easily..i.e.: you can check the code itself, but not how it was manufactured, or what kind of design decisions were made. I'm sure other /. will have better stories on why you should / should not do this..Basically, I'm just saying: don't make this complicated. If you need more manpower, try looking around in your own country first. My 2 cents..
  • by rufusdufus (450462) on Wednesday May 15, 2002 @12:18PM (#3524278)
    While I havent done it myself, I worked with others that have, and seen success and catastrophe. Whatever you do, don't hire somebody who is going to hedge the truth about progress. Ive seen projects completely cave in when the found out that their oversees components were months behind schedule, but the managers lied and said everything was going great. Remember they may not have the same American get-it-done attitude you have.
    Also, make sure they have the same scheduling paradigm you have; for some reason a lot of people think that estimating a schedule means padding by tenfold, others think it means come up with the shortest conceivable timeline to please the boss.
  • Suggestions. (Score:5, Informative)

    by glh (14273) on Wednesday May 15, 2002 @12:19PM (#3524286) Homepage Journal
    My company has hired "off-shore" programmers, however we have always brought them in. You tend to get a really good rate even bringing them in (much cheaper than typical $200/hr consultants.. I think we pay around $40-80/hr for the off-shore ones), and I would wager that you would more than make up for it in the problems that would arise doing off-shore. The other thing with bringing them to where you are is, they tend to be more willing to work (what else are they going to do, hang out in the hotel?).

    In terms of working with them off-shore.. You have the time-zone differences, which could be a potential headache (not sure exactly what the time difference is). Most Indians would already speak english (with decent clarity) so that usually isn't a problem.

    I personally enjoy working with the Indian co-workers (off-shore or H1B's). The Indians that I have worked with have always been very productive, friendly, and don't slack off as much as their American counterparts. They almost always have better education backgrounds (due to the need for visas) but conversely have less real-world experience. Granted, I don't exactly like the idea that they are taking jobs away from Americans, but I can understand why companies will hire will hire them. Especially in this economy, where they are very excited about being able to get a position and will typically take a lower wage to work.
    • I suppose it varies on the skillset needed and your location, but $40-80/hour is a wage that a lot of American contractors would happily take, even the more experienced ones (at the higher end of that spectrum).

      The real issues are communication ones, which I've seen a few people address. Of course, the funny thing is that most of the suggestions are things that should be done anyway - like nailing down requirements.
  • Deep pockets, but only if it is to hire someone in another country.

    Now, I'm all for free and open markets, but this doesn't sound like a choice.

    What's the motivation? What's the benefit to not hiring someone here? Could it be that management is still having a tantrum about having to pay a living wage for a few years? Programmers gettin' too uppity?

    It's sickening.


  • Dear Slashdot,

    Since i'm the kind of guy willing to cut corners and drive nails with a socket wrench, i'd like to hire some Hindu guys to code for me. The 12 hour time difference means i'll never have to talk with them, and whenever they call, i'll be out of the office. This is great. Who cares of Indian coders know they'll never be held accountable for their mistakes, being half a world away? I dont want it done right, I just want it done. Who cares if they dont have indoor plumbing? I want 500 lines of code per day for 3 Rupee an hour, or i'm outtahere. What should I do?

  • Here's one opinion (Score:5, Informative)

    by gwernol (167574) on Wednesday May 15, 2002 @12:31PM (#3524384)
    My limited experience of this makes me suggest the following guidelines:

    • Choose the work you farm out carefully. Because of the communications issues you can't expect the offshore team to work well on innovative software. If what you are doing involves building new technology or using known technology is an innovative way, you need to have onsite people. If the work is well understood and predictable, offshore can work well.

    • Over-communicate and formalize communication. The time shift makes it hard to make sure that you get back what you wanted. So write detailed formal specs. and make sure you keep them updated as the project progresses.

    • Build a trust relationship with the team manager. If the guy leading the offshore team is on your side you have a much better chance of success. Ideally travel out to the offshore location before the project starts to meet and shmooze him and the team. This is only possible if those pockets are really deep...

    • QA at home. The offshore team should be doing their own QA of course, but you need to run your own QA operation on all offshore code. Don't skimp this, or you will never have confidence in your product.

    In general I wouldn't recommend offshore development for a small company. The overheads of managing the operation will kill you, and you will typically be doing exactly the sort of work an offshore team is less suitable for. It is much more suited to a large company that can build a long-term relationship with the offshore team and use them to help out several different projects. This allows you to amortize the overhead costs over a number of teams and projects.

    Good luck.
  • by wcspxyx (120207)
    Connectivity there sucks. Connections can be down for many days at a time and no one there thinks anything strange is going on. Getting any kind of response from the local phone companies can be nightmarish at best. And assuming you partner is large, and they have a dedicated line to the US, then be prepared for a VERY small slice of the bandwidth pie. We're talking 14.4k equivalent.

    Be prepared to document more than you've ever documented before. You can't 'wave your hands' and get the point across. You have to do rather formal and complete documentation for any portion of the project that you would ever want them to do. You can't do small-group programming, like when your programming partners are staring over your shoulder, when the rest of your team is 10.5 timezones away. This may seem obvious, but a lot of folks miss this one.

    Nail down your code/source/project management tools, and choose ones that can work in a multi-master (when more than one server can maintain data for the same project) or disconnected mode (see note above about connectivity).

    I don't know if this is cultural or just a bad experience, but it seemed to me that there was no reguard for schedule or deadlines. Trying to get folks to actually attempt to meet a deadline was difficult most of the time. We had to go to India and sit on some of the people to get anything out of them. What's the ROI on that?

    English is one of the official languages of India, but you'll still have language issues. Usually not too bad, but can be humorous at times. I remember once a sever was taken down for 'upgradation'. If you are having them document any of their own code, have it proofread by a US tech writer.

    Be prepared to go nocturnal at times. There are times on any project when all folks have to be available at the same time. You will have to match your schedule to theirs.

    Good luck.
  • by ThomasMis (316423) on Wednesday May 15, 2002 @12:35PM (#3524428) Homepage
    As an unemployed American programmer (with CS degree in hand), who is desperately trying to land anything from a small time contract work to entry level full-time work, I'd like to send a big "Fuck You" to your company.

    Enjoy!

    Can't wait to see how far this get's modded down!!

    • I'll 2nd that "Fuck You"

      So much for american pride.
    • Get used to it. 1999 is NEVER coming back.

      It'll be interesting to see how the US manages things though - sending all its high paying jobs overseas and then wondering who's going to buy all the $200K houses, $20K cars, taxes, etc.

      I left Canada cause the major employers were all gung ho to send all the jobs away. Now it looks like the USA is doing so, too.

    • by perky (106880) on Wednesday May 15, 2002 @07:24PM (#3526846)
      I'd like to send a big "Fuck You" to your company.

      Simple question. Why? America has done more than any other to usher in the era of glabal markets and global business. Someone in India offers the service for less cost, then I say all credit to them. America delegates almost all manual labour to the far east - where are your clothes made? Now they are handing out contracts for skilled work, and because many asian contries have excellent numerate education they are kicking ass. The same will happen in russia when it gets in gear.

      The Indian guys we shipped in at $ORK[-2]were a fuck of a lot better than me, and as good as most of the rest of the group. Bear in mind that this was in a research group where the average PhD count was still above one despite two secretaries and a student on work placement. These guys are for the most part _good++_. I don't know where your degree is from, but they probably have two. And cost half as much. Put yourself in the position of the manager - If the project is reasonably atomic and QC isn't going to be a problem then shipping out contracts is a no-brainer.

      now watch _this_ get modded to shit.

  • My experiences (Score:5, Insightful)

    by Saggi (462624) on Wednesday May 15, 2002 @12:35PM (#3524431) Homepage
    In the company where I work we have a partner in India that we can outsource to.

    A few important rules do apply.

    1) Projects should be of a fairly large size. Don't try to outsource a small part of a project.

    2) Be precise in you specifications. We typically document and develop the architecture and design of the system together with management consultants and our customer.

    3) Send you architect to India. When your architect (or lead programmer) has got a firm grip of the project, send him to the development team in India. You may loose a lot if you try to do everything by email, notes etc. You don't need to move project managers etc, but architecture is critical.

    4) Make sure the outsourced parts can be boxed. I.e. develop in components, and specify and test each component individually. This should be done in most projects, but when you outsource, keep focused on splitting down the project in small (and easy to solve) components.

    We work with a partner company in India. This provides us with project management of the remote team. It might be difficult if you try to have freelancers spread over a large area. Try to take contact to one or more companies over there and establish control of the project that way.

    Many comments are about the language. We have not had many problems with that. The employees we work with in India are all fairly good to speak and read English, and I think that goes for most Indian programmers. That will be solved, as you will be able to determine their language skills when you talk (or write) to them.

    In regards to tools there are many. Most of our contact is done by email, word documents etc... The issue about managing the versions of source code require tools, but there are a lot of good tools out there. The most important rule is to define the handling, updating and deployment of code. (Did I mention you should build often?)

    When outsourcing don't underestimate the importance of quality control (testing etc...).

    Hope it gave you some ideas.
  • Is the answer to this question.

    If you find you are still having troubles working with programmers that are difficult to communicate with (language/time zone), then you're programming methodology is insufficiently eXtreme.

    .
  • by geekoid (135745) <dadinportland AT yahoo DOT com> on Wednesday May 15, 2002 @12:38PM (#3524458) Homepage Journal
    ..I gaurentee you hiring someone local will save you money, and seriously increase your odd of it being done on time.

    Beside having people just walk away with your initial money, you have a language problem, a different work ethic(niether better or worse, just different),you'll have to juggle time zxone issues, you have no legal recourse when they tell you it will be another 4 months. When you get the code, and get it working, you'll need someone to maintain it. Hopefully its written in a way that keeps that in mind. After the project, you'll have to fight for documentation.

    again, after all is said and done, hire locally. It seems you'll only need contractors, and nows a good time because a lot of them are hungry for work.
  • Something worth considering: if you have deep pockets with respect to hiring off-shore talent, you might actually save money by hiring American talent. The overhead is significantly cheaper, and these days, you can probably get experienced, quality coders for a fraction of their pre-bust salaries. Plus you have everybody on the team operating in the same time zones, and the face-to-face communication is better. Just something to consider.

  • So, we've done this with off-shore contractors. The tips I have are...

    1. Hand over independent projects. The more interaction their part has with everybody else, the greater the chance of problems. The communications differences are going to cause issues if there's a lot of interaction with the rest of the project.

    2. Be very explicit on requirements. Nail down the exact behavior of what you want their software to do. Be explicit about the development environment and the target environment.

    3. Avoid giving them tasks that you'll need to modify heavily for the next release, because they likely won't design with the next release in mind (the next release's requirements are likely not explicit yet. See #2 above.)

    4. As much as you can, try to interview the people who you'll be dealing with. With remote development, it's all the more important that you get smart people.

    5. frequent milestones -- since you're not there, you have no real way to tell where they are on your schedule, unless you have a set of milestones that they need to meet. Build meeting the milestones into the compensation plan.

    So, the point is to segregate their development from the US development as much as possible. Work to minimize communications problems. Take strong measures to measure progress.

    It's quite possible to get good work out of off-shore development. But, it'll take a lot of work on your end as well.
  • I will happily entertain any employment offer. There's a certain number below which I can't go, obviously, because I have to make mortgage payments and put food in my fridge. But I won't send you a shitty resume and then demand $100,000 a year.

    Set up a temporary email box and post the address here. Sure, you'll get a lot of crap, but you might just find a few good US-based programmers, too.

    Like me! Like me!
  • by John Murdoch (102085) on Wednesday May 15, 2002 @12:43PM (#3524490) Homepage Journal

    Software development--particularly business software development--isn't about computer "science" or "engineering." It is about communication--communication amongst your team, communication with the computer, and communication through the computer with the end user. Communication is the key.

    In hiring offshore developers you face substantially more complex challenges than you do working with a telecommuter. People who telecommute have established relationships with their employer--so they already know the implications of the tone of your voice, and what you mean when you preface your sentence with "I don't mean to be rude, but...." An offshore development team doesn't know that--you don't have the kind of relationship, based on trust, common bonds, and plain old time, that are necessary to make a team work.

    There is a simple way to deal with that problem. It is called an airplane ticket. You go to them, or they (all of them) come to you--naturally that means you're the one on the plane. You can find a whole range of airfares, and a whole range of hotel prices, and a whole range of expenses involved in traveling literally halfway around the world. And unless your project is huge, you'll blow any conceivable cost savings on the travel.

    You have other options
    One (warning: self-serving promo coming) is to outsource to a consulting firm [windgap.com]. They'll charge you a fee--but at the end of the project they will go away. You don't have any overhead costs, you don't have any headcount, and you don't have costs for machines and toolsets that you no longer need.

    Another option is to consider outsourcing to an "offshore" country that is considerably easier to get to. If you're in the United States, you might look very carefully at consulting firms in Canada: the Canadian exchange rate makes tech workers up north very attractive. And Canadian "offshore" development avoids a lot of the problems with outsourcing to the Indian subcontinent: Canadian firms are (mostly) on the same time zones as U.S. firms; Canadians and Americans share a common language--most of the time; and Canadians and Americans share a common cultural heritage (most of the time). In general Canadians are more polite than Americans, more funny than Americans, and perhaps more serious about their work than a lot of Americans.

    Believe it or not, sometimes outsourcing deals don't work out....
    An old dictum of business law says that you don't need a contract when everybody is making money. You only need the contract when things go bad. That's true--and that's why you'll need a solid contract before you start any project with any outsourcing firm. It is a lot easier to find legal help with contracts between U.S. and Canadian firms than it is to find legal help with contracts between U.S. firms and Indian firms. And--(look for articles on this subject in Fortune [fortune.com] or The Wall Street Journal [wsj.com]) the legal climate in India is not as stable as you'll find in developed countries. Long before Enron hit the headlines with its accounting problems, Enron was embroiled in a long-term dispute (see this BBC article [bbc.co.uk], for instance) with the government of India. There are all kinds of charges and counter-charges, but many in the West have viewed the debacle as proof that in India contracts are not nearly as ironclad as we view them to be. If it comes to it, it is substantially easier to litigate in Canada than in India.

    Bottom line:

    • There is lots of outsourcing talent here in the U.S., and your total project cost with a small consulting firm [windgap.com] can be surprisingly affordable.
    • There is loads of talent in Canada where time zones, language, culture, and ease of travel are not problems.
    • The costs of outsourcing to the Indian subcontinent include a lot of travel, a fair bit of legal and contractual complexity, and a potentially ugly downside in the event of a project failure.
  • ..but I can bet money that the "fat" that got trimmed from your department would be quite incensed to learn the company just turned around and outsourced their jobs a few months later, probably paying out more money in the long run than it would have cost to keep full time employees.

    If you've been granted "deep pockets", why not just rehire the guys that got laid off? Or hire a new crew of US citizens. Companies farming out their cash to foreign sweat shops isn't going to do diddly SQUAT to help the tech industry recover.
  • Yep (Score:4, Funny)

    by llamalicious (448215) on Wednesday May 15, 2002 @12:44PM (#3524494) Journal
    Send me a check for $1195.00
    Include with your check all external telnet, ftp, vnc http ports and usernames/passwords you need to use for the project.

    We'll take care of ya.
  • by cafebabe (151509) on Wednesday May 15, 2002 @12:44PM (#3524495)
    I'll concede that when US companies pay workers who live and work in another country lower wages than a worker who live in the US, it could be a beneficial situation for both. The worker (hopefully) is getting a higher paycheck than he could get from a local employer and the US company saves on labor.

    What I think is disgusting is how many US companies cheat foreign workers who come to the US on H1-B visas. I helped one of my coworkers with his taxes because he had never filed a US tax return before. We have similar skills but our employer was paying him a third of what they pay me. Apparently, this is very common and I think it's wrong. Salaries for visa workers should be determined by the cost of living of where the employee is working and living, not his country of origin.
  • Does anyone have any pointers on managing a team of programmers on the other side of the world?"

    ...You need to be pointed at a few "help wanted" sites!

    Seriously, don't burn your brains out (or sport-death your team-mates) to meet this fabricated emergency. If you complete the task, but wreck somebody's health, the senior management will most likely see this as a success, and an endorsement for chopping geek staffing beyond rational levels.

  • by kvnmcsc (244897) <mcisaac@nospam.hotmail.com> on Wednesday May 15, 2002 @12:45PM (#3524503) Homepage
    Canada has highly talented and educated programmers. Many of them, like myself, back from stints in the Bay area.
    The price is right. Typical rates for Canadian consultants are 10 - 20% discount on US rates and then discount a dollar that only worth $0.65 US. No time zone issues or language barriers. Frankly, I don't understand why a US company would consider going anywhere else.
  • Don't. (Score:3, Informative)

    by ceswiedler (165311) <chris@swiedler.org> on Wednesday May 15, 2002 @12:45PM (#3524511)
    In my experience, I have never, ever seen the "farm it out to cheap foreign programmers" dream work. When the code comes back it's worthless. Programmers that far from the project, with no emotional, financial, or professional involvement, have no reason to write quality code. They have every reason to churn out code which barely conforms to the specs. And if the specs are faulty at all, you're screwed.

    To make that sort of operation work, you'll have to write such detailed specifications that you'll practically be coding it yourself. You're much better off with a couple of coders who will look at what you're trying to do, and make it work that way.
  • I used to work for a company that has offices in India. As a project manager and QA manager, I can assure you that it can be tough. If you're going to hire off shore, don't do contractors, hire a company. That's the only way you'll have accountability. They're like used car salesman, though. You'll want 5 basic developers and they'll try to sell you 5 here, 5 there, and a PM. Stick to your guns. They need the business either way.
  • Long-Distance Teams (Score:2, Interesting)

    by SilverThorn (133151)
    I run a online game development business (www.murpe.com [murpe.com]) where most of my development and support team are found all around the world (England, India, Russia, Japan), so we had to look at a common place for having meetings and discussions. There are times my adminitrative staff cannot connect to our online games (due to firewall restricts on telnet), so using web interfaces was an option we considered.

    Since we are primary an linux-run development business, we found that using phpBB's (www.phpBB.com [phpbb.com]) web board system we could keep things private and moderated, then we also utilized a few web based project management suites (you can find these through freshmeat.net [freshmeat.net] easier) for delegating tasks and having a calender available to everyone for upcoming milestone meetings and what not. Overall, the web boards/suites allow us near real-time interaction for discussing issues and for working on other problems when they arise.

    -- M
  • by Damon C. Richardson (913) on Wednesday May 15, 2002 @12:55PM (#3524575) Homepage
    Oh it just makes me sick. If you are a american you should quit your job and find a company where the owners care a little more about their employees. I've left companys for less. For instance I quit a company because they wanted to fire american workers and run the software on Citrix clients in Mexico. Rather then help them I left. Left them with out any developer support for the 450+ user system and laughed my ass off when they tried to call me for help. In this country we don't have any type of labor party to look after national IS workers interests and it is starting to show. From what I understand about 6 out of 10 projects that try to use overseas programmers fail for one reason or another. Mostly not being able to convey the business logic to the overseas developers.

    If only you could tell us the name of your company so we can boycott it.
    • Labor union for IT/IS workers... Good idea. How much effort would this take?

      I have to believe there are a large number of Americans who would love to see an organization of this sort spring up. Perhaps if there was enough force behind this organization it could help to lobby congress against all of this bulls#%t technology legislation they've been passing.

      Where do I sign up?
  • My experiences (Score:5, Insightful)

    by yamla (136560) <chris@@@hypocrite...org> on Wednesday May 15, 2002 @01:01PM (#3524623)
    These come from my experiences working with Indian programmers off-site. I am making no claims wrt Indian programmers on-site at your location as, in my experience, things work much better in that case. Furthermore, I am not saying Indian programmers are useless, only that the culture and language barriers make them much less productive than on-site developers.

    Assuming you have four people including yourself on-site and, say, four developers in India, you will need to dedicate at least one of your developers (probably you) to managing the Indian programmers. This will be a full-time position. You probably will not do this and as a result, the productivity of the four Indian programmers will be approximately that of ONE of your on-site developers, and that is optimistic.

    With a person full-time on managing the Indian programmers (and please note, an Indian manager in India is not the same), you will find that the four Indian programmers can develop at the rate of two to three of your on-site developers. This is because, in my experience, they are never willing to work overtime and also, because of the rather extreme language barriers, infrastructure problems, and culture differences.

    Note that you will likely also need someone to do design for this project and furthermore, the design for the code you are shipping out to the developers in India need to be much more detailed than that you give to your on-site developers. In my experience, this can only be done on-site.

    Add in a manager as you have a team of eight and you are now looking at:

    - One manager
    - One liason with the Indian programmers
    - One (or two) designers
    - One (or zero) local developers
    - Four Indian developers, producing approximately 2 - 3 on-site developers' worth of code (and no design)

    So your eight person team will be, optimistically, as productive as a four-man local team. Pessimistically, they will be half as productive.

    You are likely to become slightly more productive with eight Indian developers and four local people.

    For every four developers, you need one full-time person locally to do detailed design documents. For every eight or so people on your team, you need a manager. And you need one person solely managing the off-shore developers, assuming you keep their number down to reasonable numbers.

    That means that with three local people and four Indian developers, you will achieve roughly the productivity of two local developers.

    With four local people and eight Indian developers, you will achieve roughly the productivity of five local developers.

    With five local people and 12 Indian developers, you get productivity of approximately 7 local developers.

    It is rarely worth it to do development like this.
  • by Kefaa (76147) on Wednesday May 15, 2002 @01:01PM (#3524625)
    Having done several of these, as your first project, with deep pockets and a compressed do date, you are going to have problems. Major, miss the date, lose your job type problems if you attempt to remote source it.

    Oversea outsourcing has problems beyond the traditional remote support. I have and continue to be a strong proponent of remote support. You get the benefit of hiring expertise that may not want to locate near you. For example, I work remotely for clients where the cost of living is easily three times what I pay here. And they do not offer three times the compensation. It sounds like that is what you are after. A win-win.

    Here are just some of the issues:
    - Time zones are more than inconvenient. If a question does not get answered by 8 a.m. , it will sit until the next day. Picking up the phone sounds easy, but will not be. How many issues can pile up before the communication is complete or they stop asking and just begin assuming? Who gets to call meetings and who attends? As the person leading the project, are you ready to work day and night? Team, status, and planning meetings need to be held with everyone so when?

    - Code is not code. Simply put, cultural differences create issues in code. If you wish to own the code when you are done, both parties need to understand what is acceptable standards and what will happen with code that needs to be reworked (do you still pay while they rewrite it?). Standards for names, fields, tables, access types, how and what type of inheritance is allowed, etc. Assuming they will be coding in English (yes, you do need to make it a requirement), unless you all agree (or they have worked extensively in the US), someone will be rewriting the code. Or you will need to look at it like generated code. It does the job, but you never want to maintain it.

    - Cultures different. As Americans, we tend to be naive in the assumption of cultural neutrality. And while many organizations do their best to be neutral, language continues to be a barrier. Consider how difficult it can be to understand someone with a varied US dialect. Add the phone, email, and 5,000 miles and a simple statement "You wish the account number removed, no?" takes on a whole new meaning. My unscientific number of 30 -40% redundant communication will work to minimize these types of issues.
    Some companies put an American in charge from your side. You work through them and they make sure the details get hammered out with the team. This helps a little, but sounds a lot better than it works in practice. I was approached by a company to have mine work as that front. I passed when I saw the only difference was I would now have all the issues the client had, plus my own.

    - What if it fails? This is the one that can be a stickler. Suppose you are being told that your project is on schedule and all the areas are coming together. The status reports look good and the code is getting delivered right up to the point everything stops. What are you going to do? While this problem exists in many contractor type arrangements, these folks are overseas in a country where use of the legal system is unknown. I hate to say it, but at least here you can sue someone if for nothing else but to get the code that was created.

    At this point, I foresee a number of people reaching for the "reply - he's a bigot button." Hardly. These are business decisions and people make them from the cost/benefit. Often the price appears cheaper, because the assumption is made that given any programmer "X" they will generate lines of code "Y" and the result will be the same. That is not the case and is simple as the difference between hiring a person out of school and one with 10 years experience. The both know C++ so the results will be the same, correct?

    Finally, consider the current economy. You did not say where you are, but I am willing to bet you could get the project staffed locally (or even US remote) for less TCO than you think. If they insist you use off shore help, then research carefully and find out the number of oversea projects done by the firm managed from the US. Of that total, how many were on time and on budget when complete. Then contact those customers and get their input. If their references are not glowing consider what the unhappy customers would be saying.

    You may be the one that kicks the trend. However, I would be careful about putting your career on the line for it.
  • Canada (Score:2, Informative)

    by duke_trinity (228663)
    Why go all the way to India when you could move to Toronto or Vancouver and take advantage of the Government of Canada's "scientific and experimental development" tax credit program (see Revenue Canada's SR&ED website [ccra-adrc.gc.ca] for more info). For every dollar you put in, you could get forty cents or more back... with respect to your project, this might mean an extra coder for free.
    -Duke
  • bridging the gaps (Score:3, Insightful)

    by waldeaux (109942) <donahue@skep[ ].com ['sis' in gap]> on Wednesday May 15, 2002 @01:17PM (#3524737)
    #1 - send the person who is telling you to sub-contract in India TO India.
    He'll be able to manage both of your offices more efficiently from there! :-)

    #2 - move the company HQ (incl. all of the top brass, finance, marketing,
    and HR) to India and sub-contract the tech jobs to the US. Think of
    how much $$$ your company will save then!

    There are far too many people out of work in the US to be doing this right now.
    I took a 20%+ pay cut after being unemployed for several months.
    I lucked out because I REALLY like my new job, despite the cost adjustment,
    and I'm sure that many people who are out of work would dearly LOVE the
    opportunity to apply for the positions you have at a reduced cost.

    Your company is not helping itself if it shortchanges US workers, unless
    what you're selling is for a nearly 100% foreign market - if we're all
    unemployed, how can we afford to purchase it? Another way to look at it:
    how many Indian companies are contracting out to US workers?

  • I agree, asking such a question on /. is like asking a Vegetarian's forum "how do I gut a deer, and which pieces are the best tasting?"

    Having said that, I'd recommend that if possible, go with well-known companies like InfoSys, Wipro and Tata. They have extensive offices in the US and Canada, and in the unlikely event that legal recourse is needed, you can drag them into court.

  • Danger (Score:3, Funny)

    by room101 (236520) on Wednesday May 15, 2002 @01:17PM (#3524742) Homepage
    Danger, Danger!! [robot swings his arms in terror]

  • Do you expect to get very much in the way of insightful, well-reasoned, and objective comments on this forum ? Nope. You'll get a lot of mindless blithering along these lines:
    Indian programmers are inferior to their American counterparts; hell, they lie, cheat, don't wash often enough, and don't speak English ! Your project will go to hell --

    Unless you hire Americans (and NOT H1Bs) .

    There are a lot of serious issues to consider, but you're not going to get much in the way of answers on slashdot.

  • (Outsourcing to a team of 3 in India) for 4 years now. The answer is simple -- spend much time getting the technical and functional documentation together!!! Main problem: In order to have the kind of documentation it takes to make it smooth and productive -- the time involved from your team in the US to prepare the kind of detailed details -- (in a lot of cases) you could have spent that time doing the actual programming....because the design, specs, examples, revisions, etc, etc....usually are akin to the end product minus the time it takes to type the code in.

    P.S. -- make sure they have a fast connection direct into your network.
  • Yes, Don't. (Score:3, Informative)

    by kevlar (13509) on Wednesday May 15, 2002 @01:33PM (#3524841)

    Unless:
    - Your 6 Month deadline is flexible to ~ 9 months (b/c it'll take a loooooooooong time to get in sync)
    - You know of specific competent people there that you know you can rely on (b/c mostlikely you cannot)
    - You have specific requirements spelled out precisely how you want it implemented
    - You do not need to worry about performance and memory (b/c mostlikely you'll take a hit there)
    - You can't just hire another American employee and try to sweat it out... (b/c otherwise you're obviously working against the common good of the programmers in this country)
    - You can deal with severe communication barriers. Lets face it, I know of PLENTY of H-1's that have lied about having a college degree to get a job here. Its obvious when they don't: they can't speak or write english well! You're mostlikely going to hit this problem!
    - There's nothing preventing these people in India from blackmailing you for more money by not providing what they promised (its happenned to us!).

    Need more??
  • by ghengismcbangus (201239) on Wednesday May 15, 2002 @01:49PM (#3524964)
    I work for a west-coast U.S. company. Three years ago, we aquired a company in the Netherlands. All of the employees there are fluent in English, and the developers are mature and skilled. They had an existing product which motivated the sale, and the developers there were very familiar with it.

    The Dutch product is supposed to integrate with the product I work on, but in more of an inter-process-communication way than a codebase-integration way. That is to say we collaborate on interface, but implementation is generally determined locally.

    Even so, the geographic separation has been a nightmare! At the very least, the nine-hour separation makes the round-trip turnaround for an email Q&A one full day: (I ask a question at 9AM PST - which is after quittin' time in Holland - so they don't see it until 8AM their time (11PM here) - and I don't get an answer until I come in the next morning.) And these are locally-managed developers with an execellent existing infrastructure. The problems would increase exponentially with the required granularity of long-distance management.

    A recent assesment of the problem by an outside consultant suggested that the only cure for this problem is a large increase in spending on plane tickets. Our developers will have to fly there, and vice-versa, for face2face communication far more often than the semi-annual visits we currently do. If we had hired the Dutch developers just because of their lower cost/hour, we would have seen the savings completely blown in the additional travel costs (not to mention the lost productivity from jet-lag - you're not going to get anything useful done when you hit the tarmac at Schipol at 8AM local time, but your body is telling you it's bedtime.) This problem would only be worse if the remote office were in India, with a 12-hour separation.


    Summary: The overhead of long-distance management will far outweigh the savings realized in hiring cheaper developers. Don't do it.

  • by crovira (10242) on Wednesday May 15, 2002 @02:37PM (#3525312) Homepage
    Start with a really good CVS (Check-out check-in.)

    Make everything and I do mean everything a configuration item:

    configuration management documents,

    object repository
    class/method code, (The CVS itself)
    data instance (data sources & sinks)

    project & subproject
    tasks & milestones,
    configuration item production and consumption
    (critical) paths,

    human resource experience set
    skill inventory
    task experience requirements,

    design specs,
    analysis docs,
    layouts of
    files,
    tables,
    object models &
    relationship models,
    presentations (screen & report),
    system architecture documents,
    strategy documents on
    database,
    middle ware,
    business logic &
    presentation layers components & reuse
    coding specs,
    reusable components
    code classes and methods/functions,
    test plans,
    test runs & results,
    implementation/deployment plans,

    migration paths from
    development, (stages and what
    testing,
    production to
    final deliverable packaging.

    Then, maybe, just maybe, you may be able to create something and deliver something that won't make you want to stick your head in a bucket in shame, at all, never mind on-time or under budget.

    There's a lot more to managing a project than inspirational speeches and waving "The One Minute Manager" around and failing to remember Brook's "Mithical Man Month."
  • by tarun (83353) <tarunupadhyay@yahoo.com> on Wednesday May 15, 2002 @03:53PM (#3525801) Homepage
    Well, I have been managing off-shore projects from India for about 5 years now and here is some advice rare on this board.
    • first of all cheer up. It is not as difficult as most people make it out to be :)

    • start by choosing the RIGHT company for the project. A right company is not necessarily big or small but one which has a similar style of functioning as yours. As you probably understands different companies have different levels of processes, different way of working essentially different cultures. Chose a company that is closer to yours. Ask bidding companies about their processes and cultures and to show you samples of their design documents, SRS, use cases, QA unit tests and whatever they have in their SE processes. And yes, it is possible to find companies in India with cultures not much different from American companies (not all of them are sweatshops).
    • There are lot of cheats and low-quality firms out here to swindle you. Look for references. Call your friends. When companies come to bid, ask them to give references you can check locally. Talk to american project manager of reference in detail (buy him/her lunch!!).
    • To be candid, in India level of professionalism is lower but value for human relationships is higher. Insist on talking to the actual project manager in India responsible for delievery IN PERSON before you give out the project. Ask the company to fly him to US.You only want to find answer to one question: CAN YOU TRUST HIM? (with your money? your kids?) If he is a trustable person then only give the project. (this point is impossible for an american to understand - they cannot make out why trusting your software is not very different than trusting your money)
    • Once you have awarded the project, consider your Indian partner as an extension of your company. Involve them in each stage of the project. Include them in requirement gathering and design stage. Ask them to fly-in at least some of their main guys and be a part of the process. Then, during the development stage chose a hybrid model. Have some (at least 20% of off-site) of the people from the Indian company work at your site while the rest work off-site. This will help ease communication barrier and help both companies understand each other cultures better. Indeed communication is the key to the project, insist on lots of email exchange, standardise on an IM client(yahoo, jabber, groove whatever) for the entire project team


    P.S. contrary to opinion expressed in most mails. Time zone difference is an asset. I do most of my client calls from 7 to 11 pm India time which is early morning in US. Also, most of our first-time clients are pleasantly surprised to find that 40 bugs they reported last evening have reduced to 2 by today morning !!

I've never been canoeing before, but I imagine there must be just a few simple heuristics you have to remember... Yes, don't fall out, and don't hit rocks.

Working...