Let the world work for you – how to manage global talent for your IT needs
Port of Seattle Sea-Tac capital improvement program (CIP)
Outsourcing business functions to third-party vendors who are better equipped to perform them undoubtedly adds a great value to the competitiveness of the firm. Historically, the manufacturing firms have developed a mature outsourcing and contracting program, which spans international boundaries. The current generation of manufacturing technology defines a strategic framework that, based upon business objectives and technological expectations, contracts out processes for product build, process deployment, testing, and even research and development tasks.
Firms can obtain a competitive advantage by appropriating resources from several global partners and thereby shortening the development times and the payback periods. A prime example of such a globalization trend is outsourcing IT functions such as software development, providing back office service, etc. to offshore vendors.
This paper discusses the major problems faced in a typical global outsourced IT engagement and some possible means to resolve them.
Global IT Outsourcing
Historically, IT organizations have been contracting out some or all IT functions to a more specialized service provider. However, most outsourcing vendors are within the national boundary because global IT outsourcing was not seen as a worthwhile option to consider. The major reasons include understandable doubts about the quality of service and project management issues. But, if properly managed, global outsourcing can result in superior service coupled with reduced costs and turnaround times.
During the past few years, the offshore vendors have been able to substantially enhance their skill and productivity levels. Such productivity increases coupled with advances in telecommunication and software development technology has yielded an opportunity that can be capitalized by competing firms. Today, typically, back office operations, level II and level III support activities and system development life cycle processes are entrusted to offshore service providers.
However, it is also true that several such offshore engagements are fraught with problems and only a small percentage of them result in a successful outcome. Over 85% of outsourced assignments are not completed in time, within budget and with an acceptable quality. Such engagements fail for several reasons. The major reason the full benefits that are promised by offshore outsourcing are not realized is due to the challenges faced while managing the operations. Some of the common reasons are setting unrealistic expectations, lacking a formal vendor selection process, not being very specific about the execution details, assuming without validating and failing to manage the relationship once the contract has been signed.
Selecting the wrong vendor is a major reason for the low success rate of offshore engagements. Large projects have a high switching costs associated with changing vendors. Vendor related problems due to errors made in identification of qualified vendors, communication and verification of requirements and standards, and periodic review of vendor performance contribute to the failure of offshore projects.
Scope related issues are one of the major contributors to the failure of outsourcing projects. Sometimes, IT organizations fail to clearly define, specify and communicate the services they require, when is it due and how will it be delivered. Unless the requirements are clearly expressed, the finished product will not match the original objectives. Because of physical separation and communication problems, issues due to scope changes are extremely magnified.
Exhibit 1. Project Management Areas
In global projects, communication issues take on dimensions that are unknown in single country projects. Regular and formal communication is critical to a successful global engagement. Failing to proactively identify and manage the risks peculiar to globally executed projects may result in rude shocks with the project progress taking unexpected turns.
Selecting a Vendor
Choosing the right vendor is, by far, the most important task that will decide the successful outcome of an outsourced assignment. Some of the factors in initial vendor selection are vendor's commitment to quality, competence of vendor's resources, contract terms, level of flexibility offered by the vendor, additional value-added services the vendor can provide, cultural compatibility, and the experience of the IT organization in outsourcing.
Typically, the IT organization should look for three areas of expertise from the vendor: development skills, industry knowledge and customer-specific application knowledge.
The development skills of a vendor should include a specific and defined methodology for system development, existence of and adherence to standard procedures and processes, third-party certification for vendor processes and programming skills that closely match the strategic direction of the IT organization. In today's competitive environment, there is a plethora of such vendors who can provide an equally effective development and services solution. The other criteria for evaluating the vendor would include the education level of the vendor staff, competitiveness of wages offered by the vendor, and English language competency of their staff.
Vertical industry knowledge of the vendor is another factor that determines the suitability of a vendor. This knowledge is essential for transferring any firm specific skills. If any activity other than simple programming and unit testing is outsourced, the industry knowledge of the vendor becomes a crucial factor in choosing a specific vendor.
Customer specific application knowledge is hard to find, and choosing a vendor based upon this criterion may actually constrain choosing the best vendor. However, the IT organization should plan to transfer specific customer application details to the vendor who should have a learning mechanism built in into their internal processes.
Conflicting objectives of the vendor and the IT organization will hinder the progress and effectiveness of the offshore assignment. The vendor selection process should ensure that the selected vendor is strategically placed to meet the IT organization's long-term goals and has similar growth plans.
Once a successful vendor has been identified and the required knowledge transferred to the vendor, the IT organization should allow the vendor to have more control over the internal processes. The primary tasks of the IT organization should be to manage the relationship and to ensure that the results are up to the set expectations. The vendor should be responsible for the setup and maintenance of all internal processes necessary to complete the outsourced assignment. However, this transition should be made over time as a result of conscious confidence building actions. Once a level of trust is built between the parties, joint and collaborative efforts can be planned for several senior management tasks like forecasting, strategic planning, etc.
One activity to be performed even before the start of the outsourcing engagement is to define the boundaries of the tasks to be outsourced. This will help perform a feasibility and total cost analysis of the project. There are various additional cost elements specific to a global outsourcing engagement like the required travel to the offshore sites, management of communication and logistics, maintenance of additional quality control procedures, etc. A decision to outsource should consider all related cost elements determined by the scope of the projects.
This initial project definition will help develop the possible outsourcing scenario and perform a risk assessment. Based upon the feasibility analysis, the project definition will narrow the major focus areas and determine the specific interfaces with other systems.
To manage and execute the project effectively, the project's overall scope, objectives, dependencies, interfaces and exclusions should be clearly documented and agreed upon by both the parties. The project scope definition document should also include the application areas covered by the project, the priorities, the approach, the transition methodology, procedures for reporting problems, service levels, metrics and an outline of QA process.
The application areas covered by the project should be clearly identified and priorities set, based upon the workflow details and discussions. At this stage, the performance factors constituting service levels should be identified, quantified and finalized. The measurement procedures and monitoring processes for service levels should be finalized and documented.
Setting up internal as well as exchange SLAs is an activity that must be a part of the initial planning process. The metrics and measurement tools should be identified while the scope details are finalized, because “what cannot be measured cannot be managed.” In order to ensure that the service levels are met, procedures for proper measurement and evaluation of performance should be defined. Several benchmarking standards are available, depending upon the type of tasks that are outsourced. Such benchmarks provide a mechanism for setting up specific and realistic service levels and performance goals. They can also help in assessing cost and quality issues.
Scope changes are hard to implement in offshore engagements, as there are more chances of a communication breakdown. The original requirements should be kept static as much as possible. Communicating requirement changes is considerably more difficult than communicating technical changes (such as design, standards or testing changes).
Managing Project Resources
An outsourced task typically is managed with two project organizations. By necessity, a globally outsourced project is executed at different times, due to the time zone differences. For a successful outsourcing engagement, two independent project teams should be setup, one at an onsite location accessible by the IT organization during the regular working hours and the other at the offshore location charged with managing operational issues. When working with developers in Asian countries, it may not be possible to find a time window wherein the two teams can interact during their working hours. This makes it more important to clearly define the interfaces between the teams.
Each project manager manages a different but interrelated set of tasks. It is essential to have an onsite team of the vendor locally as a part of the project office. The onsite team should be made up of resources from the IT organization as well as the vendor, and will have both functional and technical responsibilities. This team will provide all customer support as well as quick fixes to simple problems. This team will coordinate with the offshore project team for general support tasks and should preferably be setup physically close to the IT organization. The responsibilities of such a team are to define methodologies and procedures, assure system quality, plan/estimate project costs, ensure adherence to standards, support strategic planning, improve general processes and client relationship management
The offshore team should be made up mostly of vendor resources. This team will be responsible for the technical core of the outsourced tasks like design, development and testing, defect rectification and maintenance, ongoing quality assurance etc. The organization and management of the offshore team and the assignment of project roles and hierarchy within the offshore team should be the responsibility of the vendor. The IT organization, if possible, could choose to have an expatriate manager to coordinate the offshore activities. This person should have access to the offshore teams, should be involved in every decisions of strategic and tactical importance to the engagement and should be responsible for the review of the offshore processes and methodologies.
The offshore project team should include a small supplemental group, which will work during U.S. work times. This team will yield support coverage when the U.S. team is working and will act as a back up to the main offshore team during U.S. work hours. This organization will help in ensuring appropriate actions are taken when critical issues arise.
There is no unique way to ramp up the project resources at the offshore location. Normally, during the initial phases of the project, the total staff will increase as the onsite and offshore teams are added to the project. As the vendor team acquires an understanding of the business processes, the IT organization's staff is gradually removed from the project, until the vendor's on-site and offshore teams are at full strength.
Exhibit 2. Typical Project Team Interactions
The risks faced in a typical offshore engagement can be broadly classified into two types: the competitive, technological and legal risks that has far reaching implications and the operational risk, which is confined to the scope of the outsourced assignment. Risks of either type can be managed using appropriate risk management tools.
The transfer of knowledge to the vendor and hence the diffusion of technology may be used by the vendor in a competitive situation against the IT organization. Having such knowledge also increases the bargaining power of the vendor. Some techniques to handle the possible loss due to this are to continually evolve the local technology, use patent and copyright protection and to incorporate appropriate legally binding and enforceable statement in the outsourcing contract.
The vendor may not be competent enough to perform the outsourced tasks better than the internal IT department. Vendor incompetence is hard to detect when the executing team is on the other side of the world. However, if not detected and managed, it will manifest in terms of poor quality outputs and schedule outages. Carefully choosing the vendor during the initial selection process, educating them on the business functions and strategic directions and continuously monitoring the vendor performance can minimize such risks.
It is much harder to make strategic decisions, based upon outsourced offshore IT capabilities. This is because the strategic outlook of the vendor may not be in line with that of the firm. It may become difficult to lay out the IT and business strategy of the organization, when some business critical functions are outsourced. Loss of power is a covert result of an ill-placed outsourcing engagement. Timely and accurate availability of relevant information may be jeopardized if crucial functions are outsourced resulting in a loss of control.
Some possible ways to mitigate such vendor related risks are by continuously updating the technology of the IT organization, partnering with the vendor during strategic decisions, and maintaining sufficient control over the internal and vendor knowledge sources.
The project related risks have operational and tactical impact and require continuous monitoring, identification, assessment and control. To manage such risks, a detailed operational risk management plan should be established so that the risks associated with the cost, schedule, functional and technical aspects of the project are appropriately addressed. Some of the risk elements are specific to the IT organization and some impact both parties of the engagement.
Project risks should be identified at the beginning of the project and reviewed on an ongoing basis throughout the life cycle of the project. During the project lifecycle, team members (both onsite and offshore) should use professional judgment to identify risks. Once a risk has been identified, it has to be documented by means of a risk notification form, which is the basis for subsequent assessment, control and feedback activities. Communication channels should be setup between the offshore team and the onsite team to determine and analyze the metrics that help monitor the risk and identify when it actually turns into a problem. Most significant risks should have a specific contingency action identified.
Critical project issues should be addressed as common problems of the engagement partners and should be discussed with a candid attitude. It is in this context that the strategic objective of the vendor should be in line with that of the IT organization, so that frank and fruitful discussions can be held with mutually beneficial resolutions.
Other risk factors in offshore engagement include design complexity, use of new technology, developer turnover, and control on resource usage. In several occasions, it is not uncommon to see that the offshore teams have only a rudimentary understanding of the new technology, and base their estimates on incomplete knowledge and experience.
Timely, appropriate and complete communication of project information between the different stakeholders of the engagement is necessary for any project. Today, with the high Internet penetration all around the globe, there are several delivery mechanisms that provide easier communication channels, wherever the teams may be located. The communications plan should include using access tools like video conferencing, emails, Internet-based groupware, etc. The message should be recorded in writable media such as forms or emails, and should be made easily accessible to the team members. This will ensure that team members understand the message communicated, with less distortion.
Regular scheduled teleconferences can provide feedback on the status of current and ongoing projects. The communication plan should include regular quarterly or semiannual meetings wherein the key people meet and discuss their near term information technology strategy. This will provide an opportunity for each of the partners to understand the other's strategy and incorporate them into their own planning process.
Cultural issues are common in any cross-country project. However, in an outsourced engagement it is possible get around most culture-related issues. It is even possible to get a synergistic output by appropriately combining the cultural advantages of the two countries. As long as the other project management issues (like scope, communication, integration, etc.) are addressed well, by properly delegating management responsibilities to either the onsite or the offshore teams, each party can be insulated against the other's culture related issues.
The onsite management team, which will be made up of both the vendor and IT organization's resources, will have to undertake the responsibility for managing culture related issues. In addition, every team member should be aware of the cross-cultural differences and should be willing to cooperate with each other.
Starting a Project
Project initiation activities should include a visit from the offshore team to the IT organization facilities and, if possible, a visit from the IT organization to the vendor site. A face-to-face communication, particularly in the initial stages of the project can help prevent several problems down the line. It can also set appropriate expectation and sow the seeds for mutual understanding and teamwork.
Both the IT organization and the vendor should have a basic disciplined and structured approach to managing their project. This approach should define the planning and controlling of projects as a repeatable, consistent, and successful process. The methodology should cover the issues of creating, executing, controlling, and formally closing the project with specific feedback. The methodology used should be agreed upon during the initial stages of the engagement.
As a part of project initiation, the core teams from both the IT organization and the vendor should be identified, so that the foundation can be put in place for these teams to work together. This working team should be included the onsite project manager and the IT organization project manager.
The offshore project manager and the core team should acquire an understanding of the IT organization's concerns and goals for the outsourcing effort. The teams should identify the important issues that need to be resolved in order to finalize the scope of the project and the most appropriate approach. Once the core team is familiar with each other as well as the project details, the offshore project team is established. The required offshore infrastructure should also be finalized, procured and implemented in this stage.
In the context of defining the initial scope, communication and quality standards, the vendor should be viewed as a partner in progress. In addition the vendor should assume a position willing to share the risks. Both the vendor and the IT organization should invest in training and creating a knowledge base for the sake of a long-term partnership.
One good way to transfer the business and application knowledge to the vendor will be to schedule it in phases, between the onsite and the offshore teams. The initial knowledge transfer should be between the IT organization and the vendor's onsite team. The vendor's onsite team and the offshore project manager should understand the existing system, processes, procedures and documentation. Subsequent to this initial training, the vendor team should acquire as much additional knowledge about the application as it can, working with the IT staff and the existing documentation.
Once the knowledge acquisition is complete, the teams should plan to transfer the knowledge to the offshore team and start up the offshore operation. The key staff from both the vendor and the IT organization should visit the offshore facility and manage the transition. In addition to the business and application knowledge, the offshore team should be trained on the processes defined to ensure the quality and standards adherence.
In summary, a successful global outsourcing model should incorporate culture conscious resources, business focused teams, good communication strategies, efficient transfer of relevant knowledge, mutually trusting environment, commitment to quality and a disciplined project management approach. To obtain a lasting competitive advantage, the project teams should be comfortable with each other and each partner should be willing to trust and care for the other.
Proceedings of the Project Management Institute Annual Seminars & Symposium
November 1–10, 2001 • Nashville, Tenn., USA