There are two different worlds when it comes to outsourcing. One requires software development to be a creative process and the other treats it as a financial transaction governed vigilantly by a service level agreement (SLA).

Yet most companies I talk to want an offshore partner that can collaborate and innovate – not just be told exactly what to do. Woe to the company that tries to get both in the same deal.

This point was driven home for me in reading the What Does It Take to Get IT Outsourcers to Innovate? article in CIO Magazine this week. Here is a quote, “Indeed most outsourcing SLAs and pricing models deter innovation.”

For example, a recent Accelerance client wants to use Web 2.0 interactive user interface elements to an online document management system. They don’t have a detailed specification of exactly what they want, just “make it more interactive” by using pop-up previews of documents and folder expansion that don’t reload the web the page.

Is that so hard?

No, not really. But why should your offshore partner explore innovative ways to enhance the user interface of your application if you have negotiated a stringent fixed-price deal that caps their profit? Why do the extra work and not get paid for it?

The article has an answer.

Hire a large firm to do the work, but split the engagement into two deals. The first one is for the mundane tasks you can easily specify. The article suggests this can be $16M of your overall $20M outsourcing budget. Then you “keep them hungry” and “give them the opportunity to earn that [last] $4M by coming up with innovative project ideas.”

A better way is to hire another, smaller outsourcing firm that specializes in innovative software development and to whom a $4M (or even $400K) deal is huge. They will jump through hoops and pay the extra attention you need to come up with the ideas to make your software special.

These are the kind of offshore companies you will find in the Accelerance Global Partner Network. They are the leaders of the “outsourced innovation” software development niche. The big guys will be too busy making sure they fulfill the “letter of the law” of your SLA so they can make sure they get paid.

Bookmark to:
          

I moderated a roundtable discussion at SD Expo – Best Practices in Boston on Thursday. This is a major professional software development conference in the U.S. with session tracks including:

• C++
• Design & Architecture
• People, Projects & Teams
• Process & Methods
• Requirements & Analysis
• Testing & Quality

These sessions covered mostly the technical side of software development and the roundtable discussion (in the People, Projects & Teams track) was the only one that dealt with offshore outsourcing.

Most sessions at the conference were lecture format and covered topics of the software development process, aimed mainly at attendees developing software in IT departments and software product companies.

In contrast, the roundtable format was an open discussion between the all the attendees. All I had to do was get the ball rolling by introducing what I consider the five areas of mastery required for successful global outsourcing of software development. There were about 40 attendees.

We did not discuss the technical details of software technology and process. After all, software is developed pretty much the same no matter where ever you happen to be on the planet.

Or is it?

The attendees brought up the problems, issues and challenges of offshore outsourcing. Some wanted to know what to watch out for if they start offshoring. Others were looking for solutions to problems they have encountered. Problems like these:

• Too much project management overhead outsourcing to India – the vendor had a layer project managers managing other project managers!
• Attrition too high in a team of over 200 engineers in India
• Senior programmers are really junior – 3 years of experience is considered senior in India.
• Friends & family subsidiary not getting good results – want them to be more agile

One attendee wanted a Senior Java engineer but was given candidates with no EJB or database experience.Another had a Friends & Family subsidiary created when an existing employee decided he wanted to go back to India. Rather than loose the employee, the employee goes back and hires a small team. The company keeps the employee and gains an offshore operation at with programmers at a lower cost.

But problems can emerge when it becomes difficult to attract engineers to work for such a small operation in a country like India where good engineers want to work for a larger company. The original employee may be a good programmer but not an experience manager. The company is left with an offshore operation with inexpensive programmers but not delivering the software needed.

Another attendee had a Friends & Family subsidiary in Bulgaria that worked well with 2 engineers doing QA of their software developed in the U.S.

The bottom line of the discussion was that many companies are already offshoring their software development because of the cost savings. Some felt that the cost savings are overstated because of the problems and issues that are encountered.

Were you at the roundtable? Enter your own comments if you were there or if you have encountered similar results with your offshore outsourcing of software development.

Bookmark to:
          

Do you ever feel like your offshore programming team just gave up? Have they stopped asking questions or don’t have answers to yours? The problem may not be laziness but cultural.

Over the weekend I finished reading the hugely popular novel The Kite Runner by Khaled Hosseini. It is a story about several boys growing up in Afghanistan before the Russian invasion, how one named Amir comes to the U.S. during the war and then returns during the rule of the Taliban.

At one point near the end of the story Amir consults an attorney named Omar Faisal in Pakistan about adopting an Afghani child and returning him to the U.S. Omar had spent a considerable amount of time in both Kabul and the U.S. and was raised in Berkeley. He explained several times that it was extremely difficult to adopt a child and bring him to the U.S. without any paperwork when dealing with the INS.

Here is a very small part of the story:

“You’re telling me to give it up?” Amir asked, pressing his palm to his forehead.

“I grew up in the U.S., Amir. If America taught me anything, it’s that quitting is right up there with pissing in the Girl Scouts’ lemonade jar.”

That really struck me. Americans just don’t quit! It’s interesting to hear how Americans are perceived in other cultures.

It also reminded me of a personal incident while working with an Indian engineer at one of my startups about 15 years ago. It was late at night and we had to configure a couple of computers for a big demo the next day. I asked the Indian engineer to move a disk drive from one computer to another.

There was some problem like a missing driver or a wrong cable – something that was challenging but certainly could be fixed. But an hour later I found the Indian engineer working on some other small task. “What about the disk drive?” I asked.

“Oh, I couldn’t get it to work.” He said it with no shame or concern. I was shocked!

“So what did you do – just give up?” I was mystified by his lack of urgency.

After all, we couldn’t tell the prospective customer, “Sorry. We had this really cool demo lined up for you, but we couldn’t find a cable.”

Since then that engineer has become a U.S. citizen and settled in San Francisco with his wife and two daughters. His career has advanced quickly and he now works for a major strategy consulting firm in the U.S. We are still great friends and were recently reminiscing about the old days. “Do you remember the time you asked me if I ‘just gave up’ when were hooking up those computers? That really made an impression on me.”

I don’t think my friend would have ever peed in a lemonade jar, but he certainly learned how Americans feel about giving up on a major task that night before the demo so long ago. You may need to gently teach your offshore team the same lesson to get the results you expect.

Bookmark to:
          

Estimating the amount of effort needed to create software can be a difficult problem. It depends on a clear understanding of what the software should do, the objectives of the users and the skill of the programmers writing and testing the code. When outsourcing it is tempting to just “throw it over the wall (or ocean)” and let estimation be the problem of the offshore vendor.

But how can judge the quality of their ability to estimate? Even if the write your software for a fixed price bid can you tolerate a huge delay in its completion?

Now Steve McConnell has a new book out called Software Estimation: Demystifying the Black Art that I am presently reading. It is a terrific overview of various methods of estimating the effort needed to write software.

I recommend to clients that they become familiar with these techniques. And if you do throw your project over the ocean at least ask what technique was used to come up with the estimate.

To learn more about the book, check out the transcript of a chat with McConnell printed in the CIO magazine blog.

Bookmark to: