http://video.yahoo.com/watch/6157291/15991610

i invite you to watch that video.

Thanks for the great discussion…

The main point I want to make is in the title: you can make use of globalization and virtualization to create resilience in the process, to make it more adaptable to changes in the environment.

Cost is not a element in my argument. (of course it is for a lot of companies). But I agree with all of you: “if you pay peanuts, you get monkeys”. But this is valid in any country.

Yes, the process creates challenges, but also opportunities. It can be done. And in some cases, it has to be. I live in a small country and we will be running out of IT people in a couple of years. We need the additional workforce for example, but we cannot support everyone living here.

A long way to go, for sure

Cheers
Bas

If you want to be closer to your new market, to understand the customer better and to serve them better, then you may want to offshore some part of the work. But hoping that you can save on the development cost is not safe because you are going to increase the cost in communication and in quality as you correctly pointed out.

However, what I have learned is that saving on cost comes at a cost:

- Your on-shore project managers will work longer hours because of the need for increased project coordination and project communication. This will increase your cost.
- Your business analysts have to be more detailed in their analysis because the developers cannot just walk over to them and ask “What exactly did you mean on page 20?”. This will increase your cost.
- In every case of sw development offshoring that I have witnessed the quality of the returned code was below expectations. This lead to the increased need of on-site code reviews, more communications and and additional rework. This will again increase your cost.

So based on my experience, I would have to say that following the sun to save cost doesn’t work.

Until Next Time,
Cornelius Fichtner, PMP
The Project Management Podcast

Pawell and you both highlight the problem of degraded communcaotins within the team. you’ll get faster and better results if you put the whole team in one room.

Everything that moves away from this principle must be weighed against an expected diminshing speed and quality.

I recommend readon some of Graham Durant-Law’s blog on networks of people and how layers and network nodes increase complexity – which we all know is a killer to software prjects.

We should instead be looking at what we can do to maximise communcation and minismise interruptions nad mis-interprestations.

Step 1: Team in the same room.
Step 2: Team working at the customer’s site

You can work 24h a day and be able to produce less than in standard workday. That’s the same situation as sometimes happen with experienced specialist who can’t be replaced with 3 newbies.