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