offshoring and outsourcing

The Case for Back-Shoring Software Development

  • author image

I am not against offshoring, outsourcing or globalization. These strategies have significant value in business today. Yet when I took the reins at KANA in 2005, I found a company with tremendous assets but many operational challenges. One significant challenge for KANA involved its development operation in India. After a thorough analysis, I chose to end the relationship with our vendor and bring development back to the United States.

The decision we made to “back-shore” our development was the best move for KANA. Other small to midsize companies may be similarly constrained by their offshoring strategy and may not have taken the time recently to reevaluate the value of their initiatives.

When I joined KANA as CEO, I immediately recognized the company’s strengths: a large, loyal customer base, significant technological assets and a great employee team. However, the company seemed to have trouble executing as a sustainable, profitable business.

We set about fine-tuning KANA’s three core assets.

  • People - During the “bubble” days, KANA had been a very large company. Though it had downsized, it had retained the large management infrastructure with the expectation that the company would grow again. Out of 142 employees, we had 22 Vice Presidents. In fact, KANA had only four field sales reps in the United States, but it had five VPs of strategy. We restructured the corporate management, including an almost-entirely new executive team. With only one exception, all of these new executives were found inside the company.
  • Clients – KANA has 600 clients – everyone from Best Buy to Verizon to IBM. These large firms utilized our technology to support call centers, email, collaboration and chat. Yet within our client base, we only had 20 percent penetration, a big opportunity for upselling and cross-selling.
  • Technology – KANA has the only multi-channel, highly scalable, enterprise-class solution for customer service. Our renewal rate on maintenance was 92 percent – a testament to the fact that customers were getting real value from our product. Yet the core product was being developed offshore with questionable efficiency.

The decision to back-shore

KANA was one of the earliest software companies to offshore its engineering and support. The effort began almost four years ago. At one time, KANA had 250 engineers employed in India and China through its vendors.

After analyzing the state of KANA’s development operation, we decided to put together a strategy to bring the work back inside the company. There are three main reasons KANA decided to back-shore.

1. Regain control of intellectual property

In my first days as CEO, we made an inventory of our core assets. KANA’s intellectual property was at the top of the list.

Yet the company had decided to outsource and offshore core product development. That was a major mistake, in my opinion. It is one thing to outsource porting or localization or special features and another to move core intellectual property offshore.

KANA is not Oracle. When a large vendor hires thousands of its own employees offshore, the company can manage human resources activities and ensure protection of these assets very differently than KANA can at its size.

As a small company, IP is a critical part of KANA’s asset base – one that deserves full control and protection. Globalization is a powerful force. But I believe it is important to outsource only those things that enhance the success of your product delivery without outsourcing the core product engineering.

2. Achieve a comparable R&D Total Cost of Ownership (TCO)

When we began the process to bring engineering back to the United States, I thought it would end up costing KANA more money. What happened, however, is that when we analyzed the costs, we realized that KANA hadn’t saved any money by offshoring.

Indian developers have a very high level of skills. It’s no wonder that executives become fixated on the fact that you can hire two to three Indian programmers for the cost of one U.S. programmer.

However, I would be willing to bet that few software vendors have an idea of the TCO of their offshoring operation. For KANA, the competitive labor market in India meant that we had little control over who was working on our projects. There was no way to curb high turnover rates, control labor cost increases or to hold onto key talent.

Another area of added costs involved significant management resources from the United States. KANA had to employ a program manager for every five engineers in India. These managers typically spent two to three weeks in India every quarter to ensure the development process was moving forward. This added travel, documentation and quality assurance expenses.

A factor that has improved America’s competitiveness is the readjustment of engineering salaries. During the “bubble,” developers were like “hired guns.” They could write their own ticket in terms of compensation – salary plus a demand for hundreds of thousands of dollars in equity. It was a seller’s market.

That’s changed dramatically. I’m not saying finding the right engineer in Silicon Valley is an easy task, but applicants have a more logical, realistic approach to the job. U.S. developers are simply not pricing themselves out of the market anymore.

3. Improve time to market

Software development is unlike product manufacturing in other industries. In a hard goods industry, a product architect writes specifications which are turned over to engineering and the product is built exactly as planned – without deviation.

Software development is really a collaborative process. Typically an architect sets forth specifications for development. Then as the programmer works, he or she thinks of new techniques to improve scalability and performance. The programmer and the architect come together, make changes and continue to work in such a cycle.

This process is very difficult to re-create when teams are interacting around the world. We found that our offshore developers often told us, “Here’s what we built, exactly as you wanted; but it won’t work, and here’s why.”

The significant cost of this long-distance, cross-cultural collaboration gets in the way of the offshore value proposition. I’ve been in this business a long time and there is nothing that replaces coffee room chat or walking across campus and having a discussion.

It is only possible to create a highly personal development environment onshore. By paying to attempt to recreate this dynamic offshore, at best, all you’ve done is add significantly to the cost and not changed the outcome.

Such communication inefficiencies increased time to market. Also, the regular turnover in staff caused the need for lots of retraining – another delay in progress.

In fact, I now believe that the major J2EE reengineering project which we spent the past three years completing would have taken only two years if we’d have done it in the United States.

Our back-shoring efforts are only six to nine months old. However, the early results are compelling: for every three to four programmers in India, we are now able to hire one American programmer to deliver an equal level of productivity.

Early results from back-shoring

KANA is only in the first phases of its strategy to back-shore our engineering. We’ve taken on 15 of our best offshore developers on a temporary assignment basis. These workers are currently focusing on knowledge transfer, working between the United States and India.

We are still in the process of shaking out the results. One thing is certain: we’ve reduced the management structure in the company, especially in engineering where there used to be four layers of management between the engineers and the executives running engineering. We’ll now move on to replacing the remainder of the engineering staff in India over the next two to three months.

And all of our cost improvements can’t be solely attributed to back-shoring. KANA now has a significantly lower cost basis because of its transition to a J2EE-based architecture.

I would urge other software CEOs to consistently test the results of their offshoring models. All too often, leaders make decisions using a tactical process rather than a strategic one. The decision to offshore must be constantly tested to see what value is being returned. Metrics that define success must go beyond the basic statistic that an offshore engineer costs 25 percent of a U.S. engineer.

Years ago at Oracle, Larry Ellison would say, “If you’re not writing code or selling product, then why are you here?” Clearly, there are a lot of good reasons for why a software company needs more than developers and salespeople. His point was to call for periodic re-evaluation of operations to be sure they are still delivering value to the company.

Would back-shoring be the right decision for other software companies? It is difficult to say. For KANA, back-shoring has helped rejuvenate its operations. For a company of our size and nature, offshoring costs too much money, delayed time to market and caused us to lose too much control over core intellectual property.

For another $50 – $100 million vendor, the situation may very well be the same. CEOs need to perform their own due diligence.

Michael Fields is Chairman and CEO of KANA.

Post Your Comment




Leave another comment.

In order to post a comment, you must complete the fields indicated above.

Post Your Comment Close

Thank you for your comment.

Thank you for submitting your comment, your opinion is an important part of SandHill.com

Your comment has been submitted for review and will be posted to this article as soon as it is approved.

Back to Article

Topics Related to this Article