Bringing software development back in-house

I’ve written so many columns about offshore outsourcing that I never thought I’d do another. Then I met Mike Fields, the new CEO at CRM vendor Kana Software, and I changed my mind. This time I want to talk about what Fields calls “backshoring.”

At the peak of its offshoring initiatives, Kana had more than 350 software developers based in India and China. Now, Fields is reversing direction, bringing it all in-house to Kana headquarters in Menlo Park.

When Kana went offshore about three years ago, the reasons were typical: to save money and to allow for a quicker product development cycle. This was especially true in Kana’s case, because, like many high-tech firms, it had grown through smaller acquisitions and so found itself with pockets of development teams all around the country. If Kana could bring it all under one roof, it would be a far more efficient operation.

By the time Fields arrived on the scene three years later, however, he noticed that for every four or five offshore engineers, there was someone stateside whose responsibility was to manage that group and insure they were doing what the company wanted.

It wasn’t because the engineers lacked skills. Rather, IT wanted to track the processes the company thought were necessary to successfully deliver a product.

Beyond the top-heavy management structure, Fields also saw that the offshore development process was taking more time, not less. “If your team is not closely bonded, you will see more rewrites, more time and performance issues,” he says.

Fields believes that software technology is a collaborative process among designers, architects, and programmers. In other words, in software development, the architectural decisions made may evolve based on what the programmers learn.

But even that wasn’t the major reason for Fields’ decision to “backshore.” Fields says Kana had no business outsourcing software development in the first place because the company was not large enough to open a division offshore, where the programmers would be Kana employees.

“Companies our size should not take their core IP [intellectual property] and have it essentially owned by individuals of another company,” Fields explains.

So, at the end of the day, when Kana looked at the large component of program managers in the states managing the Indian process, the disconnection between architecture and design, and finally the fact that they had to give up their IP, the decision was made.

“Too many companies,” Fields tells me, “just look at the cost of one engineer here and compare it to the cost of an engineer -- say, in China -- where the ratio in comparable wages might be as high as ten to one.”

What they aren’t considering, he says, are the associative costs.

 Kana’s decision was based on time to market, quality of the finished product, and the company’s uneasiness about handing over IP to an outside company. But, let’s face it; for many, especially the larger ISVs, cost is a major factor.

I couldn’t help but notice that Henning Kagermann, CEO of SAP, went on record last week that India was getting too expensive for outsourcing of software development and that SAP would be looking elsewhere, such as China and Eastern Europe.

But I wonder, then: What will we do when there is nowhere and no one left in the world to exploit?

Who knows? Maybe we’ll have to use robots.