Think you are saving big money by offshoring? Think again. You always get what you pay for.

Yes, in the short run, paying offshore developers 25$/hr may seem like a great deal.  However, companies must be aware that there are a number of hidden costs.  Some are avoidable if you know the cause.  For example, you might have an on-shore person spending a lot more time managing the engagement, taking more time to detail requirements - as much time as they may have previously spent on building the application in-house.   There could be costly errors if the offshore developers do not understand the business needs and requirements; this can be corrected if you have an on-site business analyst and/or if you can connect your off-shore team with your stakeholders.  However, the problem that many US managers complain about  is Quality - whether the off-shore developed code is maintainable and working - or is it spaghetti code and full of bugs?

If there are any quality issues, your on-shore resources will be discovering them, spending their much more expensive time debugging, reporting issues, and so forth. 

I'm currently managing a project where a vendor is developing customizations off-shore.  I'm not sure what kind of testing they are doing, if any.  I do know that we get their code deliveries, myself and a number of other highly paid business people are spending many cycles testing and reporting issues.  I know the vendor was selected because of their low prices.  But if I had it to do again, I wouldn't.  In fact, I'm incredibly overjoyed that by a stroke of good luck, my other current project has gone from off-shore resources to - not only on-shore but on-SITE resources.  The progress that can be made when the developer can show his prototypes and talk directly with the stakeholders is well-worth the cost.  It all comes down to - you get what you pay for.

I don't have a problem with non-American developers, as some do.  I'm not xenophobic and I'd be happy if other countries reached our same standard of living.  But over the years I have been a consultant or have been  managing projects, I have seen that on-site, co-located development teams are far more effective.  It doesn't matter what their background, race, or ethnicity is - it's all about whether you can talk face-to-face, be on the same timezone, and - in the case of quality issues - can make them accountable for their work. 

If you really want offshoring to work, there are a few things you might want to pay attention to:

• Make sure your offshore team has really good phone connections.  Even with the best English, if the phone connection is poor, communication will suffer. [Insert your language where I used English, which is the language I use to communicate.]
• Invest in good online meeting technology, such as WebEx.  The ability to share screens and voice conference is so important, whether you're sharing your requirements, or seeing a demo of something they have built for you.
• See if you can establish at least some shared hours, if your on-site and off-shore resources will be working together.  It can be so frustrating waiting 12 hours for an answer, or if you can never talk real-time at all.
• Try to have someone from the offshore facility come to your site, meet the people s/he will be working with, and learn about the business.  It will personalize the people that are working together, increasing cooperation and communication. And obviously if your off-shore people are working on or supporting business applications, it helps if they have some context.

And remember - contrary to what I recently read in a business textbook - programming is not like digging ditches.  One programmer cannot simply hand off his train of thought, creative process, and so forth to another programmer at the strike of the clock.  You are not going to have a magical 24 hour development cycle.  Instead, you will have various 8 hour development cycles going around the clock.  Now, if you have a service desk, you might get this.  But not with software development.

I have trouble keeping up with this blog, although I have so much to write about.  I have switched to a new group within my company, the newly formed Program Management Office.  I am back at Brandeis again, taking a class in Agile Project Management, which has proven very interesting - and inspirational.  Now, recall, I thought I hated Agile because I thought it was all about lone cowboys and no planning.  Finally, I have a new project in my life for about the six months, and the iterations of this project stretch far into the future, with no end in sight, and plenty of features on our product backlog.

This little dude came into my life in August of last year.

& of course I put him right to work.

It's been a whirlwind!

I've been at my new position for several months and I've been so caught up in learning new things that I haven't had a chance to update. However, many of the things I've encountered are article-worthy.

Some highlights of my last three months:

• Learning ASP.NET and SQL Stored Procedures so that I could make enhancements to an application that has been sitting on the shelf ready to go out to users, but had no one to take care of it since the last guy left.
• Learning how to write Transact-SQL for a project to customize Infor's Datastream 7i, a product usually used for managing facilities plants.
• Project Management - how it works in the real world! I took the classes, but now I'm managing, let's see, 3 projects at once.
• Managing! I am the supervisor of one employee, which may not sound like a lot, but I'm glad I'm starting with only one. Being a good manager is like being a psychologist and an educator as well as a "boss".
• Upgrading three different servers to ARS 7.0 has been an adventure. I can tell you that I've run that upgrade script no less than 100 times.

To that end, I picked up a few excellent books, and I'll do a little capsule review in the meantime.

The Art of Project Management - Scott Berkun

This is an O'Reilly publication, although it lacks their characteristic animal on the cover. It is a fabulous book. While most Project Management books focus on helping you pass the PMI test, this book is focused on real life and has extensive chapters on dealing with difficult situations and so-called "difficult people".

Getting Past No:Negotiating Your Way from Confrontation to Cooperation - William Ury

As the author points out, most interactions we have in life end up being negotiations. We cannot provide everything for ourselves, so we have to work with others who may not have the same motivations and goals as we do. This book was an excellent resource when I was struggling with a particular person on one of my projects. It helped me understand that this person had his/her own understanding of the situation, different from mine, and wasn't just trying to be difficult. I believe I will return to this book again and again for guidance. I liked the fact that it wasn't about tricking the other person into doing what you want, but rather about finding a mutually beneficial solution.

Just Promoted!: How to Survive and Thrive in Your First 12 Months as a Manager - H. Betof Edward

This book is geared more towards the executive manager, but it has some advice that is useful for any new employee. Some of it talked about the importance of first impressions, and what you need to achieve in order to earn credibility in a new position. It also wrote about the psychological effects of going from an individual contributor position to supervisory/management position. Overall, it hasn't been that helpful to me but I will keep it on my shelf for the future.