Today, Gartner Inc. estimates that by 2004, more than 80 percent of U.S. executive boards will have discussed offshore sourcing, and more than 40 percent of U.S. enterprises will have completed some type of pilot or will be sourcing IT services through a global delivery model, such as near shore and offshore.1
The offshore outsourcing marketplace today has something for everyone - if you know what you want and how to get it. While the market is more mature, there are still pitfalls - even for software companies, which are in the business of developing software and delivering IT services.
Let's take a look at some of the common approaches to outsourcing product development and some DOs and DON'Ts that can guide you through the various stages of your project and ensure its success.
Getting Started: Platitudes, Attitudes and a Practical Suggestion
Most people will agree that you can't just define a project and "throw it over the wall" to an outsourcer. Yet there is a common misconception that you start out by preparing a product specification for outsourced development.
There is no document, however comprehensive you think it is, that you can just hand to an outsourcer and be sure you will get what you need. The actual, functional product spec, the document used as the basis of design, will be the result of a process of progressive investigation and analyses, often marked by a sequence of documents:
- Request for proposal (RFP)
- Proposal or statement of work (SOW)
- Business requirements specification and a functional specification
Outsourcers will expect to go through this process, and so should you. You may be experienced in writing product specs for your own development group. However, successful outsourced development involves more than defining a product spec. Success requires careful definition of how your company and the outsourcer will interact - and the right spirit governing those interactions.
First, your goal, and that of the outsourcer, should be to make your initial project a success. This goal is a prerequisite for meeting your other goals for outsourcing, such as cutting costs or getting to market faster. One way to succeed is to choose the right kind of pilot project - one amenable to success - so you can forge a relationship and learn how to work most effectively together. Good projects for successful pilots involve minimal risks to the business strategy or core product. They are relatively easy to define and break down, and have few dependencies. Examples include product enhancements, testing, APIs, interfaces or bug fixing.
Whether your project is simple or complex, to succeed you need to communicate - not only about the daily details and tactical activities, but at the executive level, about strategy. Understandably, many companies are reluctant to reveal business strategy. But remember: the more an outsourcer understands the context, the better prepared it will be to solve problems, offer recommendations that might get you more for your investment and help you to achieve your long-term goals.
Here's a true story. A software company hired an outsourcer to develop a prototype, with a stated goal of attracting investor funding. However, the company also planned to use this prototype for product testing among potential users - a goal that was never communicated to the outsourcer. The outsourcer focused on delivering key features for a demo to investors. Because of this failure to clarify the project goal, the software delivered did not have the performance and scalability necessary for user testing.
With this in mind, here is a look at the steps and related documents necessary in the process of selecting and working with an outsourcer.
Engaging an Outsourcer: To RFP or Not to RFP
Request for proposals (RFPs) ask for the outsourcers' qualifications, describe the business and product requirements and establish a project timeline and price estimate. With every candidate answering the same questions, an RFP seems like a fair way to judge everyone and a good way to get the best price.
However, if someone underbids but can't deliver the work or if the product delivered doesn't meet the true business need, you don't save any money or get to market faster.
Some things to avoid:
- Do not write an RFP as your product specification and send it out to a dozen outsourcers.
- Once the RFP is written by the people who want and will use the software, do not turn the RFP over to another group to evaluate the vendor responses and do not let them choose a vendor based on company guidelines.
What is wrong with the RFP process? Many outsourcers will not commit the resources to respond to RFPs - for a couple of important reasons:
- First, RFPs don't provide enough information to write a meaningful resource and cost estimate. While many companies consider them to be a product specification, from the outsourcer's point of view, RFPs contain only 50-75 percent of the real requirements - at best. At worst, they contain errors in estimating the size of the work and the skill levels required. For example, RFPs may contain necessary information about desired features - without considering whether and how engineers can build them. Detailed information - combining users' and engineering perspectives - will only emerge after an outsourcer prepares a SOW, is selected and gathers more information.
- Second, if the process of managing RFP responses is handed over to another group, often the stakeholders who generated it are not available for discussion with the candidates. Good outsourcers will want to talk to the stakeholders to find out information that is necessary for them to write a realistic proposal.
