The Case for Back-Shoring
By Michael Fields, KANA
(Continued)
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 re-engineering project which we spent the past three years completing would have taken only two years if we'd have done it in the U.S.
Our back-shoring efforts are only six-to-nine months-old. However the early results are compelling: for every 3 to 4 programmers in India, we are now able to hire 1 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 U.S. 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 lots 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, too much time to market and too much control over core intellectual property.
For another $50 to $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.
Pages: 1 2
-





