Offshore Development Model - Factors to Consider

Transcription

1 INFORMATION MANAGEMENT: STRATEGY, SYSTEMS, AND TECHNOLOGIES OFFSHORE DEVELOPMENT: CAVEATS AND CONSEQUENCES Vijay Bhima Rao and Rajaguru Periaswamy INSIDE Factors; Location/Infrastructure; People; Establishing a Development Model: IIS 70/30 Offshore Development Model; De-risking the Model: Addressing Cultural Differences INTRODUCTION As the technological boom began to transform the U.S. economy in the 1990s, the shortage of people and organizations to handle critical software projects manifested itself. American companies realized that they would have to look for answers beyond their own shores. It was during this time that a few Indian companies started arriving on the scene, offering what later came to be termed as the offshore model. This broadly meant that the Indian organization would send a team to the U.S. for initial study of the problem and discussions with their American counterparts. Once the problem domain was established, most of the Indian team would return to India and start working on a much larger team for developing, installing, and maintaining the solution. Note that we use the term India generically, al- PAYOFF IDEA India has gained a justifiable reputation in software development, and it is almost inconceivable to think of any major U.S. corporation that does not outsource some of its software work to India. That said, offshore development does not provide sure-fire success; it comes with its own inherent risks. This article stresses planning and overcoming the cultural gaps as the key factors in avoiding failure. It does not consider technology as a factor because Each area of technology has its own risk factors and considering them here would move this article from its moorings. Indians have established competence in most of the cutting-edge technologies; in most cases arguably as good as their American counterparts. Thus, technology is not usually a stumbling block for offshore development. This article should serve as a guide to software professionals and IT managers who are planning on doing some parts of their work offshore. The article introduces the process of offshore development and then describes a 70/30 offshore/on-site mix of resources to ensure that quality applications are developed in time.

2 though it could equally apply to other countries. India, however, has taken the lead in this segment. Offshore development grew from the initially more prevalent practice of shipping bodies (engineers) who would do the work completely at the customer s site. Restrictions in space and cost (and visa restrictions) meant that offshore development was a natural corollary to on-site body shipment. Also, the offshore companies moved up the value chain, from merely being body shippers to organizations that could offer the entire solution, at a much lower cost, thereby leveraging India s cost advantage. In addition, over a period of time, the quality offered was comparable to solutions developed on-site. In the mid-1990s, when Integrated Information Systems (IIS) was establishing itself in the U.S. markets for a wide range of software services, it faced competition from Indian software development companies that promised to deliver quality products and services at cheaper rates, due to their offshore model. Encouraged by IIS management, we tried to look beyond our competitors, and focus instead on the entire gamut of the offshore model. We asked key questions on this issue, such as: Does this model lend itself to replication? What are the critical factors at play in this model, leading to its success? And, conversely, what are the pitfalls to avoid? With regard to the first question, we felt confident that we would be able to replicate and even better the existing offshore model because we had people with background in India and work experience in the United States, through IIS. This, coupled with our organizational backing, would give us the best of both worlds. The second question is answered in the subsequent paragraphs, and the question of pitfalls is addressed in the cultural differences and conclusion sections of this article. FACTORS Our research determined that the following key factors were to be considered if we were to integrate the offshore development center with IIS current U.S. operations. They were: Location and infrastructure People Establishing a development model De-risking the model by addressing cultural differences If these factors could be addressed effectively then it was evident that a strategic advantage would accrue by combining IIS project manage-

3 ment skills and knowledge of the U.S. client base together with Indian software resources. Thus, in the summer of 1999, a business plan was developed to successfully implement the offshore model, the key features of which are discussed below. Location and Infrastructure A good location is a sine qua non for putting the other pieces in place. Therefore, it was decided to establish the center in the southern Indian city of Bangalore. There were many reasons for this. Historically, Bangalore was in the forefront of offshore development, with many large U.S. companies either setting up their own operations or getting their work outsourced. Bangalore, also known as the Silicon Valley of India, has ties with all the major software vendors, including Sun Microsystems, IBM, Motorola, Cisco, and GE. Due to this critical mass of technology companies, Bangalore attracts India s most talented software engineers. A decision was made to place our operations in the International Technology Park Ltd. (ITPL). ITPL provides a world-class infrastructure, with central air-conditioned office space and impressive telecommunications network and recreational facilities. ITPL also has its own captive power generating stations that ensure around-the-clock availability of power. The infrastructure provided IIS with a hassle-free work environment and ensured employees the best facilities. People The argument that software development is a people-intensive segment is a no-brainer. India is reputed to have the third largest pool of technological manpower. Some of its technical and management institutions are on par with the best in the world. If we add to this the familiarity with English, because of India s colonial background, it makes India a perfect market for those hunting for a huge group of skilled software professionals. However, getting the correct match of skills is a difficult task. While the Indian market boasts an abundance of skilled manpower at competitive rates, it was quickly found that most of the skilled resources reside in a few companies or have relocated to other countries. Therefore, getting the right resources is (and continues to be) a challenge because the demand is greater than the supply in India. The recruitment process started early even before the center became operational. Although newspaper advertisements generate interest, we preferred to work with reputable placement agencies to get the resources with the skill sets needed. We were looking for quality over quantity. In working with the top 10 placement agencies in Bangalore, it was possible to attract excellent talent from the market. The thrill of setting up an offshore center

4 from scratch enabled us to recruit highly competent employees from established organizations. IIS India operations opened in December 1999, with 20 full-time, highly skilled employees. Establishing a Development Model: IIS 70/30 Offshore Development Model After putting the initial pieces in place, it was necessary to develop a plan of action to ensure that the model was now implemented. To this end, we have developed (and over the last year and a half, perfected) several models to suit the needs of different clients. These include a 70/30 model for Fortune 50-type U.S. companies, and a continuous and seamless development model taking advantage of the 12-hour time gap between our U.S. and Indian offices. In addition, for other types of clients, there is a 24 (hours a day) by 7 (days a week) production support model. The 70/30 model is based on a split between offshore and on-site consultants on a project team. Seventy percent of a project s consultants are based offshore in Bangalore, while the remaining 30 percent of the staff is at the client s site in the United States. The project s technical lead consultant and the entire application development staff are in Bangalore, while the project manager and, if necessary, an additional technical lead remain on-site with the client in the United States. The task-flow for the above model is depicted in Exhibit 1. On an overall basis, the steps involved in successfully implementing a project offshore are depicted and described in Exhibit 2. Project planning. The business problems are identified and the results needed are discussed between project team and client. The responsibility and process leadership for all involved parties are identified and placed into a document for everyone s use. Analyze. In the analyze phase, the U.S. project manager and business analyst(s) are identified. The India technical lead goes to the United States to help conduct a requirements analysis. Regular conference calls with the India office are scheduled. The development team is assembled in India. Design. While in the United States, the India technical lead drafts a high-level design document and receives the client s approval. The U.S. project manager prepares a detailed project schedule, and the deadlines are mutually agreed upon with the client and IIS project team. The India technical lead returns to Bangalore and completes the detailed design. During this time, any client requests for changes in functionality are captured by the U.S. business analyst(s), and are then communicated to the India technical lead. Build and test. The India technical lead oversees the development effort in India based on predetermined coding standards. The development environments reflect the final implementation environment for the application. Test plans are created and testing results

5 EXHIBIT 1 Establishing a Development Model: Implementation Task Flow Resource Allocation Project Planning Analyze Design Build and Test Production Production Support - Requirement analysis IIS Account Management Team Involvement U.S. India U.S. India - Assemble - 1 tech lead tech team - 7 developers U.S. - PM manages deployment along with the help of India tech lead - 1 Project manager - 1 Business system analyst U.S. India U.S. India - High level initial - Detail design in - PM and analyst - Tech lead goes design India remain in the U.S. back to U.S. - Technical - Tech lead in India architecture design drives the design in conjunction with the U.S. U.S. India India - Entire build happens in India - Set Entry/Exit criteria - QA Audit #1: Pre- Integration Testing - QA Audit #2: Post- Integration Testing - PM stays in the U.S. to coordinate direction and manage relationship with the client U.S. - PM manages deployment along with the help of India tech lead and one other resource - Tech lead remains in India - QA team is assembled - 7 developers are in building process U.S. India India - Client sign off - Post production support - India support team takes over

6 EXHIBIT 2 Implementing a Project Offshore Project Planning - Establish project and team identity - Identify key goals and success factors - Start resourcing process in India Analyze - System and requirements specification - Early involvement for U.S. and India teams - Start quality control processes Detail Design - Done in India - Regular conference calls and status reports - High level project management High Level Design - Critical India Tech Lead participation - Expectations set for U.S. and India teams - Use standardized templates for all Build and Test - Entire build in India - Code review processes - Internal Quality Audits Production - India team flies to U.S. for implementation - India team in U.S. until application stabilizes - IIS India to provide production support

7 documented. Constant communication between the India technical lead and the project manager in the United States is critical at this stage to ensure that project deadlines are met. Production. A team from India visits the client s site for deployment. It is important to note that for this model to work successfully, processes and methodologies for design and development must be identical in both locations. De-risking the Model: Addressing Cultural Differences All the best-laid plans for the offshore model could come unstuck (despite good development models) when up against key cultural differences between United States (and other Western nations) and India. There are a few key generic cultural gaps that commonly arise between offshore development centers in India and their counterparts in the United States, as well as with clients. These generic culture gaps include: Authority/failure syndrome. Indian culture, being hierarchy driven, tends to instill deference to authority. Often, personnel will not disagree or contradict superiors, particularly in the presence of third parties, and will say what they think their superior wants to hear rather than the truth. For Americans, this means that their Indian counterparts require closer supervision and explicit instructions. Many a time, Indian employees will not take the initiative at work for fear of doing the wrong thing. This would be unlike American employees who tend to work with minimal supervision and are generally averse to micromanagement. English. Although English is the language of communication, the manner in which it is spoken lends itself to misunderstanding between the offshore and on-site client teams. This is compounded by the tendency of Indian employees to remain silent rather than ask about phrases they do not understand, although the client assumes they have been understood, and there is increased potential for misunderstanding. To reduce this, organizations should: Distribute the agenda before the meeting/call to enable your Indian counterparts to gauge the subject. Distribute the action items/minutes of meeting after a meeting/call. Time. Indians have a fluid notation of time, compared to the more fixed orientation of their Western counterparts. In India, deadlines and schedules are considered as guidelines and not as fixed endpoints. While increasingly Indians are beginning to understand that the Western world has a fixed orientation to time and that deadlines are critical, it is best to specify the importance of deadlines and schedules up front.

8 Do not shoot the messenger. Do not assume that Indian staff members will volunteer information when there are unresolved problems. Often, they do not like to be the bearers of bad news. Americans need to ask questions that do not result in yes or no answers, listen to what the staff members are saying, and ask more questions. Indian employees should try to volunteer relevant information rather than just answer questions. Body language. While body language conveys a lot in different cultures, the manner in which it is done differs between American and Indian cultures. The practice in the Indian culture is to stand closer when discussing something important. The speakers may shake their heads from left to right to indicate yes, and are not accustomed to direct eye contact. These actions can easily be misinterpreted by American customers. The best way to resolve miscommunication is to state what you are interpreting to the Indian employee for clarification. To address the above and other cultural problems, for IIS in India and the United States, cross-cultural training programs have been organized for all our consultants. Once the teams understood each other s cultures, they noticeably worked better together. CONCLUSION Over the last year and a half, those at IIS have been able to successfully establish an offshore model. The key thing is that we have been updating our knowledge continuously on all aspects of the model, as discussed above. In conclusion, we would like to emphasize the following: The offshore model, by its very nature, is complex and unpredictable. So, what works in the United States does not necessarily work in India. Therefore, a well-laid-out plan is a must, right from the beginning. Companies should factor in cultural differences because they can derail the project by themselves, even more than technology can. Organizations should ensure that they are aware of the roadblocks along the way. They should check and ensure that they are understood at each stage, and document every step, however small. Organizations should ensure that they have the correct offshore model for different projects. For example, a model for legacy system migration might look a lot different than Web-based development. While Indians have been able to cover almost the entire breadth of software development, it is still appropriate to adopt one correct model because there is no one size fits all strategy. The offshore model may not be appropriate where knowledge is domain specific,

9 where there are frequent changes in design, or where the project delivery period is very short. Vijay Bhima Rao is the general manager at IIS (India). He may be reached at Rajaguru Periaswamy is a project manager at IIS (India). He may be reached at Rajagurup@iis.com.