Going Abroad--Part II
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 code and even brainstorming ideas are now a challenge. Even more challenging is the work of the project manager. How do you report the real progress on a project that is so decentralized and divided?
Similar issues arise for risk management and resource allocation in scheduling when things are not experienced firsthand. When isolated from the project team, how do you report progress and achievements to your peers? In such situations, you are dependent on other's guesstimates and opinions.
As a German living and teaching in the United States, I've noticed the culture and work ethic is defined through the values this country was built upon. I see this in discussing ideas proactively, promotions for good work by a team, and financially benefiting from that good work. It impresses me how fast Americans build new work relationships to form a team and how fast those ties are collaborated with the spirit to win. The courage to make things better is honored by the society.
Your partner offshore might have a different culture and work ethic--defined by hierarchy and top-down communication, executing orders rather than inventing things. It will cost your project to promote team spirit overseas so that all participants can identify themselves with the product.
Be prepared for ongoing interpersonal communication. The easy part is to draft a requirements document and ship it offshore. The hard part is to get what you want, which is not necessarily what you drafted in your first version of the requirements document. There will be change requests and renegotiation of scope and the project management for those requirements. To forecast local developments, project managers need to meet the team in the same way the business analysts need to communicate business requirements. To do this, the onshore team needs to go offshore in the same way the offshore team needs to come onshore periodically. Travel costs and time need to be incorporated into the pricing model on both shores. For larger endeavors, representatives of each partner communicate, collect, and request information from their shore. This go-to point of contact also can act as the funnel to the offshore team when pieces of the project are outsourced even further.
Be prepared for more detailed standards, guidelines, and procedures. If you expect that Java code will be written following a particular format, you will need to be specific about it. Casual internal reviews onshore that were just fine for internal development efforts are not sufficient for offshore development.
In the third and final part of this series, I'll provide you with guidelines to implement a different shore model, the smart-shore approach.
Click Here to Read Taking Off to the Smart Shore Part 1 of 3
