Going Abroad--Part II

[article]
Summary:
Many organizations currently experiment with offshore development, and Jochen Krebs is trying to find a good reason why the outsourcing trend has become so popular. In part 2 of his three part series, he explores the low-cost parameter of the offshore business model.

In the first part of this article, I wrote that building software is an engineering process, not a manufacturing process. IT is about creativity and innovation--not just the actual building process. An American software engineer is compensated $65 an hour on average, whereas offshore engineers can be hired for as little as $20 an hour. Somewhere in between must be the break-even point for companies to produce competitive IT systems or products.

Companies often are attracted by the low-budget hourly rate of software engineers offshore. However, the pricing model for a successful roll-out focuses on more than just wages. Usually top management onshore identifies, negotiates, and defines a partnership with an offshore vendor. Based on accounting principles, those costs need be allocated to the offshore endeavor. The project and the intellectual property need to be managed, and people need to be on site. Travel costs (flights, hotels, etc.), time spent for traveling, and all the additional administrative time to schedule meetings need to be included, too.

More important is what you decide to do after the system steps into the maintenance phase. Do you plan to take the developed system back into your organization, or do you keep the maintenance offshore? Are you confident that the same people who build the system are also maintaining it? Continuity in process and skills cannot be assumed, and an additional learning curve must be expected. Looking at recent developments, it would be foolish for an onshore IT company to even try to compete on a price model. The discussion, in my opinion, can only be around value, which is innovation.

In Part I, I also discussed the difficulties of software engineering, requirements management, and analysis and design. The actual step of coding consumes much less time.

Let's assume that a company delegates the entire engineering process offshore but manages the project and the intellectual property in the form of requirement statements under its own control. Almost every day the project manager and the business analyst will issue change requests. Like regular requirement statements, change requests need to be transformed through analysis and design into code. However, a change request might affect existing design and code, and it is therefore crucial that the software architecture can handle and deal with these changes. After the offshore-team completed the system, and it is operational the design of the architecture will show its real value during its operation and maintenance phase. Anyone on the team lacking architectural skills and a commitment to standards and guidelines could diminish the benefits of modern technologies during maintenance.

Another interesting aspect is how offshore companies are connected with each other using the same outsourcing model that is in place in the United States. Offshore companies hire contractors and resources on demand. For example, imagine that offshore company O1 wins a major deal with an American customer. It hires O2 and O3 to program the requirements given to it. O2 and O3 are excited to get a piece of the pie but need to outsource more pieces to other partners--let's say O4 and O5. This creates a network of contracts and companies, project managers, and software engineers. To understand and maintain these companies would be time-consuming.

In this model, every contractor in the offshore model makes a small profit from outsourcing and delegating. But back onshore, you might care less about how many players actually benefit from this model than you do about getting the entire system deployed as planned. Yet that attitude can change quickly when you decide to issue or locate a simple change request. Finding poor quality pieces of

About the author

Jochen Krebs's picture Jochen Krebs

Jochen "Joe" Krebs, www.jochenkrebs.com,  is a method engineer within the Rational Brand for IBM. He develops content for the Rational Unified Process, OpenUP, and other agile software engineering processes. Prior to his current role he was responsible for successful enablement of Rational products and services for clients in the financial sector. Before joining IBM Rational he worked as an instructor and senior consultant with a focus on project management, requirements management, software engineering processes, and object-oriented technologies using Smalltalk and Java. He holds his MSc in computing for commerce and industry at the Open University.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Oct 12
Nov 09
Nov 09