|
One of the most controversial and polarizing topics in this U.S. election year is the so-called 'jobless recovery'.
In a recent Gallup Poll, 'the economy' and 'unemployment' were voted the top two problems in the U.S. By some estimates more than 2 million jobs have been exported offshore during the past few years, and are unlikely to ever come back. Hundreds of thousands more are expected to go every year for the forseeable future.
These exports have largely been routine service functions like call centers, help desks and other back-office operations, but the poster boy for this displacement seems to be the unemployed IT software guy, a highly-skilled and highly-paid U.S. developer that unknowingly trained his offshore replacement last year, and then suddenly found himself on the streets this year.
Skip the background, and take me to 'the Answer'
The advocates argue that offshore outsourcing of software is not only good for the global economy, it's also good for U.S. business and the U.S. economy.
Cost savings: The most obvious argument for offshore outsourcing, of course, is labor cost savings. The average programmer in India makes about $8,000 per year, almost an order of magnitude less than a comparable programmer in the U.S. This programmer is just as smart, industrious and well trained as their U.S. counterpart, and tends to be even more meticulous and process-oriented. This helps their U.S. customers build products less expensively, which helps these businesses and the U.S. economy grow.
Focus on Innovation: Furthermore, the argument continues, this helps U.S. businesses focus their resources on what they do best, which is to innovate and create new products. Even today's most innovative companies spend only about 1/3 of their R&D budgets on creating truly new products, and the rest on testing, maintaining or making incremental improvements to old products. If this work is sent offshore, more R&D budget is freed up for more U.S. workers to focus on creating new products.
Time Zones and Time to Market: In theory at least, software can developed more quickly by taking advantage of time zones. For example, a software development team can send their code to a test team on the other side of the planet at the end of the day, and then come in the next morning and find the code tested and possibly even corrected.
New Markets for American Products: Of course outsourcing is also beneficial for the receiving country. In India, for example, about 25% of the population still lives in poverty, but contract software programming has become the symbol of a modern, emerging middle class. And this trend, repeated globally, can help create a whole new markets for American products.
Free Trade: And isn't this what globalization and free trade is supposed to be all about? The more we help other countries elevate themselves out of poverty, the more we help break down the barriers of ignorance and intolerance, and the more we help raise the prospects for worldwide prosperity and peace, right?
Of course, opponents of offshore outsourcing have a very different point of view.
What Cost Savings?: First of all, they will argue, the cost savings aren't nearly as significant as they might appear on the surface. There's the overhead of the offshore development company, and then the extra burden of communication and project management.
Cultural Barriers: Not only is there sometimes a language barrier, there may also be a cultural barrier. Americans and northern Europeans tends to think and communicate in highly linear way, while people in other parts of the world (like the Asia/Pacific region) tend to think and communicate in a highly contextual manner. Neither is superior, but they are very different, and few Americans are experienced at working with these differences.
Human Cost: Of course, a major factor is the human cost, the trauma to the laid-off IT workers and their families, and the effect of demoralizing the surviving workforce. After all, if we can export such essential, high-level skills, who is safe? There's also the potential cost of bad PR for the company.
'Free' Trade?: Opening new markets for U.S. products sounds great, but the opponents of offshore outsourcing argue that this only works if exports are actually paid for. The Business Software Alliance reports that more than half of all business software in Eastern Europe, Latin America and Asia/Pacific is pirated, with some countries like Russia and China approaching or even exceeding a piracy rate of 90%. This amounts to many billions of dollars of lost revenues for U.S. software companies every year.
Intellectual Property: Copyright and intellectual property laws in many countries offer little protection compared to those in the U.S. While the majority of offshore developers may be ethical, a U.S. company may have little legal recourse if software they outsourced mysteriously shows up in a competitor's product in a foreign market.
"Hollowing Out": Furthermore, the argument continues, offshore outsourcing is contributing to the "hollowing out of America", the diminishing of the working middle class, leaving only the very poor and the very rich - just like a 3rd world country. And in doing so, we're also exporting our tax revenue base, which only diminishes our ability to help those that need it most. It's great to want to help people in other countries, but should we do so at the expense of our own people?
Of course, the U.S. has gone through workforce transitions before. During the past century, we've gone from an agricultural economy to an industrial economy, and then from an industrial economy to an information economy. Each time we adapted, and although there was massive displacement and retraining of workers, on the whole the U.S. economy emerged stronger every time.
What makes this upheaval so different and so troubling is that it's not so clear what we're making the transition to - exactly what follows after we export our information and knowledge work? In addition, this transition is happening much more quickly than any that came before - not across decades, but within months and years, leaving little time for those directly affected to react.
This is not without irony. As software types ushered in computers and the Internet just a few years ago to automate mundane and repetitive office tasks (remember "Internet time" and "the Internet will change everything"?), how many IT types could have anticipated how quickly the Internet would enable the outsourcing of their own jobs?
In any case, there is a long history of companies that underreact during times of transition, and then overreact after it's too late. We all know manufacturers in the automotive and electronics industries that stubbornly refused to outsource even the most mundane manufacturing tasks on even the oldest products, despite clear advantages in doing so. Then, after finding themselves left behind by competition, management (often new management) rushed to outsource everything, creating a whole new host of problems.
Like it or not, there are powerful, natural economic laws at work. We believe that, for companies with a significant volume of software work, the best answer is to find an intelligent balance somewhere in between - a balance between inhouse development, local outsourcing, and offshore outsourcing.
How to split up the work? Lines can be drawn between products, projects, or stages. We contend that the latter usually makes the most sense.
Software development comprises many stages, including requirements gathering, design, development, documentation, testing, release, maintenance and revision. These different stages require very different skills - for example, a person that is great at defining requirements often makes a lousy architect, and a great architect often makes a lousy tester.
While the labor of developing software may be distributed over these stages more or less in equal share, the real costs are weighted heavily towards the earlier stages. There's an old rule of thumb in the software business that a bug (or missing feature) that costs $1 to catch in the requirements stage will cost $10 if corrected during the design process, or $100 to correct during the development process, or $1000 to correct during the testing process, or $10,000 to correct if it isn't caught until the software is released.
While a bit simplistic, it isn't far from the truth, and it illustrates the importance of getting things right as early as possible - and that the labor cost of writing and testing lines of code is just a small fraction of the real cost of developing software.
For every business, it's critical to identify the software projects and stages that are 'Core', 'Strategic' and 'Tactical'.
CORE:
To be successful, each business needs to clearly understand it's core competencies - a very short list of skills that allow it to grow and differentiate itself from the competition.
If a company is in the business of providing software products or services, or if it uses business software in a way that is unique and provides a key differentiator from the competition, then at least the 'up-front' work involving requirements definition and design should probably be done in-house. It might make sense for a startup company to engage a trusted and closely-held consultant, but over the long term it usually makes sense to bring these skills into the company.
For most companies that are outside of the software business, the use of software may be important but not 'core', and it often makes sense to engage outside but local expertise. A high level of trust, communication and mindshare are essential, and a good subject matter expert is more than worthwhile for the industry awareness, experience and efficiency they bring to the job. More importantly, this allows a company to focus it's best and most creative energies on its real core competencies.
STRATEGIC:
A large body of software work is less than 'Core', but more than routine or 'Tactical'. For this class of software, there is necessarily some degree of flexibility on how the software should be implemented, there will be some give-and-take and creativity during the development process.
This type of work is usually defined by a 'Market Requirements Specification' which spells out what the software is supposed to do, but not down to the fine details of how the software should be implemented and tested.
A somewhat iterative or circular development process (following the 'Prototype' or 'Spiral' models, or the like) may be used, in which prototypes or alpha software are developed and reviewed, and then used to finalize the details of the final product. It will require frequent communications, shared creativity and the ability to have impromptu face-to-face meetings to resolve issues as they come up.
For example, this is appropriate when the product has a high level of user interface, there are some technical or market uncertainties, or early versions of the product are needed to resolve technical risks or for end-user market testing. Any of these are good candidates for local outsourcing.
TACTICAL:
A large remaining body of software work is more precise and routine in nature.
This type of work is typically defined by a 'Functional Specification' which was derived from the Market Requirements Specification, and spells out in detailed terms every function and feature of the software, including details on the testing process. It's a direct step to software coding from here, with relatively little room for interpretation.
These projects are usually well suited for the classic 'Waterfall' development model, in which the project flows linearly through the stages of design, development and testing, with little or no backtracking.
For example, these may be classic IT projects, internal projects that are heavy on data processing and light on user interface, with little technical or market uncertainty. Or they may be maintenance releases or incremental revisions to old or existing products. Any of these are potential candidates for offshore outsourcing.
Yes and no.
At the back end, where business information is handled behind company firewalls, the work generally resembles classic IT and tends to be mostly 'Tactical'.
At the 'gateway', the transition between business information and wireless network, local knowledge and relationships with wireless carriers are very useful. Wireless carriers use protocols that are defined by industry standards groups, but each one interprets these specifications their own way. This tends to be a moving target for each network as they evolve to implement new features or fix old bugs, and they can change without warning. Mobile data applications that use these networks for transport should be handled by a local mobile data expert.
At the device level, the user interface is usually critical to achieve high end-user acceptance, and the development environments for wireless devices tend to be relatively immature and evolving. Again, close relationships with the device manufacturers are very useful, and it's worthwhile to engage local mobile data experts.
Some of the older 'thin client' technologies, like WAP, are relatively mature and are essentially driven by code at the server, so development is somewhat similar to classic web development. However, the real challenge here is configuration management, as different devices implement these technologies differently.
While the testing stage is often a good candidate for offshore outsourcing, and a lot of wireless testing can be done anywhere using simulators, it's important that final testing be done by local QA teams on the actual devices and networks that the application will see. For example, a GSM application that works perfectly in India may not work properly in the U.S., and vice versa.
One of the most critical decisions a business leader needs to make is which operations to keep inhouse, which to outsource locally, and which to outsource offshore. It's much more than a cost issue, it's also a human, political, IP, and strategic issue.
Business history books are filled with post mortems of companies that didn't respond to times of transition. Those that 1) understand that developing software comprises many different stages requiring very different skills, and 2) then figure out how to achieve an intelligent balance between inhouse development, local outsourcing, and offshore outsourcing will create a distinct and sustainable competitive advantage.
Written by:
Kim Spitznagel
President
Outr.Net, Inc.
Comments on this newsletter? Please let us know.
I'd like to subscribe to the Outr.Net newsletter.
| 
