SmartAdvice: Getting The Right Onsite Mix With Offshore Suppliers
There's no perfect ratio for onsite workers when setting up an outsourcing project, The Advisory Council says. Also, if your company has made a business case for using Linux, consider gradual adoption while the SCO lawsuit business is settled; and, don't confuse information with knowledge when deploying business intelligence.
Editor's Note: Welcome to SmartAdvice, a weekly column by The Advisory Council (TAC), an advisory service firm. The feature answers three questions of core interest to you, ranging from career advice to enterprise strategies to how to deal with vendors. Submit questions directly to firstname.lastname@example.org
Question A: How do we achieve a good onsite/offshore ratio with an offshore supplier?
Our advice: Achieving the optimal ratio of onsite to offsite resources requires balancing project needs, supplier capabilities, and organizational goals. Focus on selecting the projects best suited to take advantage of offshore delivery, and build a support infrastructure that facilitates distributed work efforts.
What makes a good ratio of onsite to offshore workers? This question has no simple answer. Although the ultimate goal may be straightforward--put as large a percentage offshore as possible to reduce labor costs--project characteristics, logistical issues, and organizational experience all affect the difficulty and desirability of achieving this goal. Keeping too many people onsite erodes the cost benefits of going offshore, but pushing the ratio too far in the other direction may affect a project's effectiveness so severely that it actually increases overall costs. Although widely quoted as "industry standards," ratios such as 30% onsite to 70% offshore are only valid when viewed as high-level averages across many projects, rather than guidelines for an individual effort. The right answer varies from project to project, and even by stage within a project.
An IT organization can optimize its onsite/offshore ratios on a project-by-project basis and across all of its offshore engagements by paying attention to these factors:
Each project has its own characteristics that affect the best ratio of onsite to offshore personnel. Begin by determining the optimization goal for the project (lowest cost, fastest delivery, etc.), then make adjustments to optimize for that goal. Consider:
Type of project--A freestanding project such as a technology migration can support a much higher offshore ratio than a collaborative effort between IT and marketing to create a new Web site.
Stage of project--The earliest (analysis, design) and latest (deployment) stages require a high percentage of onsite workers, while the bulk of coding and testing stages can be performed offshore.
Work breakdown within the project--Rethinking and realigning team-member roles can achieve more-effective splits between onshore and offshore team members.
Organizational factors help optimize onsite to offshore ratios across all projects.
Outsourcing strategy--A formal outsourcing strategy with well thought-out goals lets an IT organization screen projects to best achieve those goals. For example, if the strategic goal is to save as much money as possible, focus on projects for which most of the work can be sent offshore.
Outsourcing maturity--The optimal percentage of offshore workers will increase as an organization gains experience working with offshore partners, and adopts offshore best practices.
Outsourcing infrastructure--An automated process infrastructure to support collaborative, distributed development lets more complex efforts be split between onsite and offshore personnel.
Picking the right offshore partner for a given assignment is essential to achieving an optimal ratio of onsite to offshore workers. Here are some factors to take into account:
Trustworthiness--Beware of unrealistically low offshore rates. Less-scrupulous companies use these rates to attract customers, but recapture their costs by putting more of their workers onsite, at high U.S. rates.
Experience with the specific type of project--High levels of experience mean greater efficiency and less need for onsite resources.
Experience with your company--As your partner gains greater knowledge of your company, processes, and systems, it will reduce the need for onsite personnel and enable more cross-training to be performed offshore.
Process maturity--Offshore providers with high Capability Maturity Model ratings have the processes and tools to handle complex distributed processes without requiring extra onsite support.
Resist the urge to achieve an industry-standard ratio for onsite and offshore resources. Rather, seek to optimize ratios on a project-by-project basis for the most benefit. Picking the right partner(s), adopting their best practices, and implementing a support infrastructure will improve ratios across all projects. Ratios also will improve as your company and its partner(s) gain knowledge and experience working together.
Question B: SCO has started suing Linux users as threatened. Does this change your advice from Nov. 3?
Our advice: In our Nov. 3 SmartAdvice column, we said it's unlikely that SCO will prevail in its legal actions. Given the contractual issues that are the basis for SCO's suit against IBM (which involve only those two companies), and the fact that Linux is licensed under GPL (the GNU General Public License), we still don't believe that legal actions taken by SCO will amount to a serious threat to Linux users. We were mildly surprised, however, to see SCO actually initiate legal action against user corporations.
For many organizations, a decision to deploy Linux is a strategic and long-term one. Major parts of their IT infrastructures will use Linux as a foundation, potentially representing large numbers of systems (and therefore licenses). Given the cost-related motivation for considering Linux, the potential for having to fund a legal battle with money and other resources, or deal with unexpected but substantial licensing costs, is something enterprises would want to avoid.
Major Linux vendors understand this, and have responded with indemnification programs that offer various types and levels of protection for their customers. Hewlett-Packard, IBM, Novell, Red Hat, and Sun Microsystems have all put such programs in place, although they differ. Sun, for example, restricts indemnification to desktop deployments, and HP limits coverage to Linux deployments on its own hardware. Red Hat, through what it calls the Open Source Now Fund, is offering support beyond users of its Enterprise Linux product to those who leverage other open-source licensing scenarios. IBM asserts that SCO's suit against it is without merit, and therefore indemnification shouldn't be necessary, but it is nonetheless a contributor to the Open Source Development Laboratory (OSDL) Linux Legal Defense Fund.
Also on Nov. 3, we asserted our belief that SCO was most likely after stock-price stimulation, its takeover by a major Linux vendor, or both. As we haven't seen anything to convince us that SCO's revenue outlook has improved since then, we stick with this view of SCO's motivations.
Indemnification programs, however, introduce two new elements into the mix. First, vendors' willingness to support or sponsor indemnification programs demonstrates their belief that any legal action shouldn't be taken seriously. If they're correct, the time during which SCO initiates suits will be short, and the number of suits initiated will be low.
Second, it's possible that SCO never expected to collect licensing fees from users, but in fact may have anticipated the creation of indemnification programs from which it could collect significant revenue. Both of these elements should provide some reassurance for enterprises that Linux usage shouldn't be feared. Technology-adoption decisions should always begin with a determination of the suitability of the solution. Once Linux is determined to meet relevant business and technical criteria, an assessment of risks to business operations and the cost-benefit trade-off associated with a SCO-initiated suit would make sense. Vendor/product selection may depend in part on the applicability of an indemnification program to the enterprise's particular circumstances.
Indemnification aside, a lawsuit can be a major distraction. Nevertheless, with a strong justification for Linux deployment based on technical suitability and overall cost, fear of lawsuits can be overcome. If circumstances permit, gradual adoption is an option, while the vendors and courts work through the issues to pave the way for enterprises to leverage Linux' advantages without fear.
The Business of Going DigitalDigital business isn't about changing code; it's about changing what legacy sales, distribution, customer service, and product groups do in the new digital age. It's about bringing big data analytics, mobile, social, marketing automation, cloud computing, and the app economy together to launch new products and services. We're seeing new titles in this digital revolution, new responsibilities, new business models, and major shifts in technology spending.