Infomation Technology

Email This Author Comment On Article About The Author More Articles By This Author

The software industry has sharply declined in the markets over the last three years. Software development companies departments saw a severe drop in their revenues and corporate IT budgets were reduced drastically. At the same time, the user base grew and the requirements for more software infrastructure and applications increased. These opposite trends forced executives to look for cost effective solutions: build more for less money. In a move similar to the manufacturing industry during the 80’s, executives in the US began looking overseas to find lower-cost labor to help answer this problem. Currently, the most popular countries for offshore software development are India (with 85% of the offshore development market), China, Philippines, Russia, Mexico and Eastern Asia. Offshore development used to be viewed as little more than a tactic for reducing the costs of software development. However, things started to change drastically in the early 2000s as companies, pressed by an imminent recession, began outsourcing more strategically significant functions such as software design, architecture, prototyping and of course: code development. Now, offshore development is regarded as a critical management tool essential to improving IT’s ROI. CIOs and CTOs sent clear directives to begin the process of integrating their companies with offshore personnel to be able to scale and compete in today’s industry. However, offshore development, so simple in theory, is tough to execute well. The challenges can range from problematic project management to cultural miscommunications. The hunt for reduced costs, scalability and improved quality comes at a price: risk. In most cases, companies fail to anticipate what they must do to minimize the dangers of integrating with an overseas vendor. Here are some best practices that should help you build an offshore strategy and reap full benefits of the large high-qualified, low-cost labor outside the US. Offshore outsourcing is a process, not an event Executing successful projects offshore can be very rewarding, but this is a process that your company must learn. There are multiple intricacies when sending projects overseas. Let’s face it. It is hard enough to manage projects internally where you can meet with your people on a daily basis. How would you manage a team 9,000 miles away to get exactly what you need? A great way to get your company trained for working with an offshore team is to start with small projects and then grow into larger ones as your processes mature. For example, a first project with an offshore partner may consist of executing an 8-week pilot project fully managed internally where the architecture and design teams have representatives from both companies. Then send pre-defined components overseas and make sure that the code is reviewed by a joint quality team when it comes back. This gives both companies a good overview of a full cycle offshore development process as it is executed at either end. The risk is controlled very well and the cost savings of “offshoring” make up for the extra overhead of learning how to work with offshore. After one or two pilots, expectations ought to be in place and the teams should be ready to work on larger projects. To be successful, you must make offshore outsourcing a process, not an event. Find company with a proven track record to help you set up your offshore processes I started working with offshore resources during the dot-com boom. Our main application was outsourced to three relatively small companies in India and each got about one third of the development work. This was done to keep them from increasing prices quickly and to avoid reliance on one company. After all, they were 9,000 miles away and nobody really knew whether they were going to be around the next year. When we got the results and looked into the code of the applications sent from all three companies, we found some serious issues:

• First, the architecture was fatally flawed. The programs worked miraculously with bugs that could not be resolved because fixing them would create bugs in other parts of the system.
• Second, maintenance was a nightmare. In order to make simple changes to the application, we needed to run batch programs that took hours. The risk imposed on the application when making such changes was enormous. One night, these batch files wiped out key data for half of our customers (fortunately, everything was backed up).
• Because the companies did not communicate well with each other they built duplicate and triplicate components and each would bill us accordingly. Our onshore developers would spend “all-nighters” chatting with their offshore counterparts in each company trying to figure out how the application was coded. In essence, our offshore vendors did not really know what they were doing. They staffed their facilities as quickly as they could and, they learned on our dime.

To effectively send work overseas, you need to find one offshore partner that has a proven track record in the technology you are using. Be willing to negotiate long-term contracts and rates to provide incentives for them to train their people in your company. Before choosing a partner, shop around and for each prospective vendor, find out what other companies they are doing business with and what results they have achieved. Make sure that they have competent resources in the technologies used by your company. Look at their credentials. A good starting point is to find out what IEEE standards follow. In addition, find out their Capability Maturity Model (CMM) level, published by Software Engineering Institute (SEI). Companies with a CMM level 3 and above have documented processes in place to ensure the training and effectiveness of their resources. CMM level 5 is the highest level; less than 100 companies in the world have this status. CMM level 5 companies have the foundation, structure, maturity and experience to execute software projects effectively. For more information about CMM certification, you can visit http://www.sei.cmu.edu/cmm/cmm.html. Develop overseas, but manage locally
Manage locally — period. It does not matter whether you or your vendor play the role of project managers, perform project management locally. IT projects have vast interactions between users and analysts, comparing existing systems and functionality with desired results. Important decisions happen in meetings where all the stakeholders are present. Local project management (a vendor supplied project manager is OK) will give you the visibility and control you need throughout the life cycle of the application. Moreover, in large projects with sizeable teams overseas, insist also on strong offshore project management. Make sure that they have a clear direction and unambiguous set of goals and deliverables. Ask for offshore team leads for the different components and an overall offshore project manager responsible for the offshore deliverables. Offshore management onsite is crucial. It is hard enough to control projects in house; offshore scope control without strong direction is a nightmare. As part of your evaluation of an offshore partner, consider where their company is based. A company based in the United States offers great benefits from a project management standpoint, including the availability of experienced onsite project managers and technically competent resources. These will help you ensure a smooth knowledge transfer and scope communication with offshore. Another added benefit of a US based company is that if needed you can have their staff onsite very quickly without having to wait weeks for visas an other official paperwork to be processed. An effective management team structure and escalation process is similar to the one in Figure 1, where there is a clear set of roles and their equivalent in the offshore vendor. This team structure allows a clear escalation process. Furthermore, it ensures proper risk management. The key shown in the chart below is to have US-based account and project managers who can address issues without delays. By being so close, the visibility that the offshore teams gain is enormous. They are prepared to make appropriate changes as required by the projects. In contrast, if you opt for having pure offshore management, not only you may lose a shift in every issue because of time and space differences, but you will have to provide pristine communication and hope your instructions are not misinterpreted overseas.

Deciding What to Send Offshore
In theory, deciding what send offshore is a simple: companies can outsource non-core development applications, and boost their return on capital by using third-party development centers. But in reality, things are more complicated. First, it is not trivial to figure out what's core and what's non-core. For instance, building robust software applications may seem to be a non-core activity for a large supermarket chain whose revenues come from selling items in their stores, but in reality some of the most important competitive advantages in retail come from cutting edge software-based item management. In order to take full advantage of offshore development, think of new paradigm: define what your company and IT department needs to deliver and, wherever possible, break it down into modules that are measurable, trackable and quantifiable. A project consisting of a ‘PeopleSoft migration to Oracle Financials for Accounts Receivables’, for instance, matches these criteria, whereas the ‘construction of an Enterprise Midrange System’ does not. Once you have componentized these projects, regardless of whether they are core or non-core, go through that list and determine the feasibility of its offshore development with your offshore partner/vendor. Great offshore development componentized activities are:

• Rapid prototyping of unknown/unproven technologies. This frees resources internally to evaluate results and determine their usability in the Enterprise
• Reverse engineering of legacy and/or undocumented applications. Every company has those skeletons in the closet… sooner or later they need to come out.
• Code Migrations. This requires an enormous amount of time to analyze cryptic data, set up the transfer process, test and perform the migration. In addition, offshore works great for setting up and cleaning up data to prepare the migration.
• Your classic software development projects. Here it is strongly recommended that your offshore partner is part of the team as close as possible to inception. This helps to clearly define the scope of the offshore responsibilities.
• Testing and maintenance. These are major areas for effective use of offshore resources.

Use Design Patterns within a Framework and Enforce Tight Standards A myth in offshore software development is that you will get “spaghetti” code or monolithic applications that are hard to extend or scale. This myth is not unjustified. Poor offshore executions give offshore software development a bad name. “Offshore development is cheap, but of low quality“, was the opinion of a project manager in a small integrations firm in Irvine, CA. “We had to spend as much time fixing code as we would have building it ourselves”. Instead of managing the project, the entire application was “dumped offshore” In order to avoid bad code, some companies enforce very tight coding “standards”, such as indentations, naming conventions and modularizations. However, this is just one of the many practices that need to be present as part of the process. These represent coding “style”, not standards. A key practice for allowing offshore scalability and compatibility is the use of design patterns. Using design patterns is a great practice for IT enterprises. But when going offshore it is a must. Before sending any components overseas, architect frameworks using design patterns that can be repeated and replicated over and over again. It is recommended to either build the framework locally, or have a very strong presence onsite. Proper design patterns help to break the tasks into manageable units, which is perfect for offshore development and onshore implementation. Tim Sakach, an IT veteran with 30 years in the field observed: “By creating a solid framework with a proper design patterns, it makes the whole design reusable. The reusability of the actual design helps even more than reusability of code. The framework allows for development of major applications by making the development process follow the actual structure of the framework.” An added benefit of using design patterns is risk management. An onsite team of architects can easily and quickly test and validate the solutions created by offshore teams and ensure that they are in line with your enterprise.

Do not treat offshore as just plain staff augmentation: use it as part of your organization. Don’t think that offshore resourcing is good only for staff augmentation. During the high-tech boom, there was an incredible development backlog. This motivated companies to try offshore development overseas. A classic picture of the offshore development used for staff augmentation of a large IT department looks like figure 2, where offshore was used to alleviate the peaks and valleys created by the beginning and end of new and existing projects. If chart shown in figure 2 reflected a person’s heart rate at a hospital, it would not be long before this patient gets a heart attack! While this strategy works fine in the short-term, if you place these peaks and valleys on your offshore partner, it will not be long before it starts to not function properly because new resources will need to be trained, retrained, hired and laid off. Sooner or later it will also affect your organization. If this is your offshore long-term strategy you are going to hinder your offshore partner’s ability to properly train resources to fit your needs and ultimately, your culture. Fortunately, Figure 2 shows only a myopic view of the IT organization as a whole.

A broader view of this IT organization and the offshore staff augmentation is displayed in Figure 3. Notice how the overall picture looks ok because the scale has changed. Still, the ups and downs are taken by offshore and essentially your savings amount to the difference in cost between US resources and offshore resources in the shaded area. Once your organization learns how to effectively leverage offshore resources, you will obtain the real savings by reducing your full time US-based IT staff and enlarging your offshore resources accordingly, as shown in Figure 4. Ideally, a true offshore integration consists of using your people as leaders who manage small offshore teams, the latter being responsible for developing the actual work. Remember the statement that offshore is process and not an event? Start this process by changing the hiring process.

For instance, if you need 10 Java developers, allocate budget for 2 US-based employees. How is the work going to get accomplished? Well, instead of hiring 10 Java developers for your needs, pick the top two of the ten you would have hired and have those two lead a team of 10 developers offshore. The rule-of-thumb used in the industry for a project with medium complexity is a blend of 1 (US) to 5-6 (overseas). You will get more resources with less money and you will obtain the true scalability of offshore development. Now, your savings are much larger as illustrated in Figure 4, where the shaded area shows the cost savings associated with a fully functional offshore Enterprise process. In some cases, you will need to buy a dedicated resource pool as an extension of your IT department – and then reduce your US-based IT staff. Conclusion
The software industry has shown a clear shift into sending software development work abroad much like the “maquiladoras” in manufacturing. If you are considering offshore development, now is the time to start looking into it. Offshore development is a process that must be melded into your company and a new set of development paradigms must be adopted. “Offshoring” will provide US software companies with a competitive edge only if they learn to execute properly. This execution consists of building an internal foundation, so that culture, architecture, design patterns, frameworks and company-specific processes can be conveyed and learned mutually between you and your counterpart abroad. References:
"How to Think Strategically About Outsourcing," Harvard Management Update, Vol. 7, No. 5, May 2002.