Outsourcing. The word itself polarizes forces between those who love it and those who loathe it. The word outsourcing invokes fears of the unknown, of losing jobs, of losing competitive advantage, and of losing intellectual property. At some point in your product management career you will be asked to outsource part of your solution. Before you become paralyzed with fear, ask some critical questions. Outsourcing can be risky if you do not know the answers to these questions.

• Why are you doing this?
• What are you outsourcing?
• Who will do what?
• Where will you do it?
• When will you connect?
• When should you start?
• How will you do this?

Answering these questions can give you the confidence that outsourcing is a well thought out strategy, not just another corporate fad.

According to Bob Booton, author of Outsourcing In-a-Box, the “Prime Directive of Outsourcing is to pick the right outsourcing partner.” Unless you answer these questions and take a fact-based approach, how will you know you have the right partner?

Why are you doing this?

At the root of any outsourcing decision is why you are doing it. The most obvious reason is to save costs. Executives read about “global outsourcing” and immediately assume “if you outsource, it will be cheaper.” If you do this well and can make it repeatable, you can save money. But if you are expecting a quick return, you (and the executives) will be disappointed. Competitive pressures often drive companies to outsource. If others are doing it, should you? Be careful that you are not doing it simply because the competition is outsourcing.

Other reasons to outsource are increased capacity and reduced time-to-market. There are never enough resources in your company. If you get someone else to do the work in parallel to your other development efforts, then theoretically you will get the solution sooner. Think manufacturing capacity. Additional plants. But, software capacity is a different animal. Adding engineers or quality assurance resources will not necessarily provide the same payback in terms of time and cost savings. Increasing “capacity” does not give you the multiples you would get in manufacturing because of the increased complexity of adding more humans to the project. (Remember “The Mythical Man Month”? Three people working in parallel cannot deliver a baby in three months.)

Time-to-market is linked with capacity. Integrating all of the resources into the total solution may give you a quicker time-to-market, but then again, it may not. Frankly, the challenge of development is what to leave out, not what to put in. And remember to add time and resources to assure the quality and delivery necessary to meet your customers’ needs and expectations. Your reputation and brand are at stake.

Outsourcing is an excellent way to expand the company’s development skill set. Does your organization lack the technical skills necessary to deliver part of the solution? If so, your choices include: hiring the skills (which might be more expensive than outsourcing); partnering with someone who already has the technology you need (which will require integration, but this may be less risky than outsourcing the development completely); or outsourcing the development to an organization that already has the technical skills.

Outsourcing functions or projects that are not core to the company allows you to concentrate on your own distinctive competence. On the other hand, if you are outsourcing something that contains the company’s intellectual property (IP) and distinctive competence, you put your unique advantage into someone else’s hands, possibly in a country that may not recognize your country’s patent and IP laws! What would prevent them from selling the knowledge to the competition?

Where does the customer fit in your decision? Assess the impact to your customer. This is directly related to the focus on your distinctive competence. If you provide world-class customer service, are known and valued for it, and it is unique in your marketplace, then why would you outsource the function or project to an organization that does not know your customers, their culture, or their language, and may be separated from you and your customers by an ocean? There may be legitimate reasons, but cost should not be the only driver for this decision.

What are you outsourcing?

There are companies today providing outsourcing services to technology companies for just about everything:

• Research
• Development
• Quality control
• Documentation
• Service
• Manufacturing
• Marketing
• Distribution

Which function or project are you thinking about outsourcing? The “what” and “why” are closely related. Assess the risk in outsourcing the function or project. If there are risks, what is the mitigation strategy? For example, what will you do if you are outsourcing software programming and the project begins to fall apart? What safeguards do you have for getting source code on a frequent, regular basis?

Not only will you choose which function to outsource, but you should choose which project to outsource. In the beginning, choose something with less risk so that you can get the mechanics right: maintenance projects, porting, executing tests. Basic functionality that does not have many issues. Automating something well known. And remember that you should not outsource a project that is part of your unique value in the market.

Who will do what?

This is about roles and responsibilities—in both organizations. Before you start the project, it is essential to clarify who does what and when. Key roles in technology development include:

Product Manager

This role defines the problem to be solved. In a market-driven organization, this role looks for valuable and pervasive problemsto solve in the market segments you are targeting and problems that the market is willing to pay to solve. The product manager writes requirements, which are the capabilities to solve the problem: the “what,” not the “how,” of product definition.

When a judgment call is required—and it will be—who will decide? In every development project there are items that remain unspecified. Should it be fast or easy? Should it be 1,000 items or one million? This or that? A market representative must be nearby or the developer must make a decision. As anyone who has built software knows, these judgment calls are rarely raised to a review board; the developer just decides.

If a product manager also assumes any of the following roles, she or he will not have time to do the strategic product management activities necessary to be focused on the market and the customers.

Product Architect

This design role defines an approach to solve the problem, the “how,” not the “what.”

Development

This role builds the product. In software development, this is the programmer who writes the code.

A lead developer might be one of the interface points between the two organizations.

Quality Assurance (QA)

In any project, this is a critical role responsible for assuring quality. This role needs to be involved in the planning to ensure the product requirements are verifiable and that the specifications meet the requirements, before anything is built. When outsourcing, this role becomes even more important than when the team is all in the same location. Being together in close proximity means you can have quick iterations, review sessions, and hallway conversations to verify that everyone is on the right track. Valuable time is wasted in rework (or quality problems in the field) if you outsource without thinking in advance about quality.

Some of the QA functions might be done locally and some might be outsourced. For example, the up-front verification of the requirement and specification might take place on your side of the ocean. Building the test plans might take place on your side of the ocean. The actual validation against the test plan might take place remotely. Regression testing might take place remotely.

Program Management/Project Management

As companies grow, these roles are split into two functions. In smaller companies, both aspects of the role are done by one function (or as a part-time job by someone with good project management skills).

The program manager is responsible for ensuring the project has the right resources and skills at the right time during the development project and that Development is proceeding according to plan. This role assesses the risks of the interdependencies of the different resources and manages them accordingly. The project management role keeps track of the individual tasks; the percentage of complete items; schedule slippage; Gant and Pert charts; and updating the project in products like Microsoft® Project.

When outsourcing a project, this role might become the key interface point between the two organizations. That means this role travels back and forth between organizations.

Account Manager

This role might exist on either side as the person responsible for the overall relationship and expectation setter between the two organizations. This person would not necessarily be as involved in the day-to-day operations as the other roles are but becomes the focal point for anything that needs to be escalated to management such as technical issues or scope changes. In smaller organizations, this role might be assumed by either program manager or product manager.

If you are outsourcing within the same company (using a remote group that is made up of employees within the same company), then the account management job may be done by the program or project manager.

To be successful with critical projects, someone from your company must work with the outsourcing partner at their location, not just visit occasionally. Increasingly, outsourcing firms are insisting on an onsite project manager to coordinate with the offshore location. If you do not provide one, they will. Invite someone from their company to work with you at your location. Although today’s technology allows remote meetings and remote sharing of information and projects, you are still dealing with human beings. Remember the value of face-to-face meetings and the benefit of cross-pollination on both sides. This allows you to have formal and informal communication take place every day.

Choose which roles are most appropriate depending on the size and nature of the project. When you outsource across an ocean or to a country with a different culture or language, have a product architect on either side of the ocean. The architects become the conduit between organizations.

For complex projects, each of the above roles may need someone on either side of the ocean. As we add people, it is even more critical to clearly define who does what and when. The counterpart on either side of the ocean needs to understand cultural and language differences and be diligent about formal and informal communication methods.

Where will you do it?

Until you choose a potential partner, you cannot answer the specifics of this question. But once you have narrowed the choices, where will the partner be located? With any remote operation, there are always communication issues. Small, co-located teams seem to get things done more efficiently because of the informal communication that can occur. This includes:

• Impromptu reviews
• Meeting for lunch
• Hallway conversations
• Frequent iterations
• Seeing the expression on someone’s face

This is not to say that outsourcing or remote operations will not work! Just be aware of the risks and decide how to overcome them.

Multiple companies, multiple countries

Cultural issues have significant impact on successful projects. Are there differences between the West Coast and East Coast of the United States? What about the Midwest? Or the South? And even within the United States, there are time zone issues. Different product labs within the same company have differing development and process standards.

The difficulties with remote operations within our company are exacerbated when working with other companies. In particular, the company culture differences are more pronounced. To be successful, you need to develop a good working relationship with a key contact in their company. This might be an account manager, alliance or partnership manager, or channel manager.

When working with a team in another country, you must anticipate the language differences. Even when the operation belongs to your company, remember that the other team lives in a country where things are probably done differently. People in other cultures may not be comfortable asking questions for clarification or may make different assumptions. But, as other countries start increasing capacity and skills (whether part of your company or in another company) and as demand grows, costs rise. It is basic supply and demand. We already see this in software development in India and Ireland.

Are you frightened yet? You can do this! Remember, if you do not, someone else will.

When will you connect?

One of the reasons companies think outsourcing is a good idea is the increase in capacity. By outsourcing across the globe, we can have 24 x 7 operations. While we sleep, they work; and vice versa. But as you move into implementation you will soon realize that somewhere someone has to be available during the middle of the night. We need on a regular basis real-time communication (phone, video, web, live chat) while we are both awake. The window of time when we are both awake is not very long (end of day for one, beginning of day for the other). And there are time zones where there is not any overlap during the “normal” workday, so someone has to stay longer or arrive earlier than normal.

If we do not find common times to connect on a frequent basis, we waste a lot of time waiting for the other to reply back to resolve an issue or answer a question. No one likes waiting, so often the developer guesses and goes down a path that ends up being the wrong path. Time for rework. If you have someone from your project team at their site, and someone from their side at your site, some of these issues can be resolved before they cross the ocean.

When should you start?

Outsourcing can add additional time to the project for the up-front planning, agreements, environment setup, etc. If a program or project manager needs to temporarily relocate to the outsourced site, time mustbe allocated for finding housing, dealing with travel and work visas, etc.If the project requires exchanging confidential data on a regular basis, agreements and secure transmission methods must be established. Ifthe project is within the same company, some of this will be easier, but processes still must be documented and established. Does the outsourcing site have the necessary hardware, software, networking, and tools to dothe work? Many times, the projects require specific versions of compilers or networks, and huge problems hamper the start of outsourced projects that were unable to quickly get the development or testing environment set up. Also, remember training. Though the technical skills may be available, the project may require some knowledge transfer or specific training.

For outsourced projects, plan on at least one additional month in the up-front setup and formalization of the process. This is the minimum! This also assumes that there is at least one full-time person working on the logistical details. If your project has less than that, plan on more time. For more difficult issues, such as inter-country laws, inter-company legal agreements, or specific technology or skill requirements, add even more time up front.

How will you do this?

The best approach is to hire an expert. Outsource the outsource expert? Yes, sort of. But if you want to make this repeatable, you also need to groom internal resources to be excellent at outsourcing. If this will be a key function in your company, you ought to have executive ownership of the function.

The fundamental mechanics of outsourcing can be divided into beginning, middle, and end of the project.

Beginning (Pre-development)

What problems are you solving?

Before you even make the decision about what to outsource, clearly identify what problem you are trying to solve (internal problem or customer problem). Basedon the problem, discuss what the optimal solution might be. Look at different options. Understand the value of solving the problem. How long do you have? Then, and only then, should you make the decision to buy the technology, build it yourself, or partner (outsource).

Do you have the right partner?

Do not choose the partner until you know what problem you are trying to solve. Different outsourcing companies are good at different things. Choosing the right partner is essential to your success, but you cannot choose the right partner until you have the other questions answered.

Who will do what?

Look at the various roles. Where willthey be located? Who will do what? Whois accountable for the success? What arethe handoffs and deliverables?

How will you protect your IP?

Even though people sign Non-Disclosure Agreements and contracts, be sure to conduct due diligence on the partner, and research the country’s laws about patent and IP protection. You are probably still vulnerable. You may need to hire an expert in IP protection to help you.

Middle (During development)

How will you communicate?

You will need multiple communication methods. Today’s technology brings many options. Not only will you need to explore the technical fit (telephone, voice over internet protocol, web communication, intranet/internet/extranet, collaboration, document management, email, instant messenger, face-to-face meeting), you will need to calculate costs, security, availability, and reliability of the communication vehicle. What are the Sarbanes-Oxley implications for top-secret projects?

What feedback mechanisms will you use?

Successful outsourcing requires disciplined forms of documentation. If requirements are not clearly documented and communicated, QA cannot verify that they are met. If requirements are changed, the documents need to change. Look at all of the artifacts you will need to communicate requirements, specifications, documentation revision controls, scope change controls, status, and key issues. A stage-gate process will ensure that you are not moving to another phase of the project until you have met the objectives of the previous phase.

How will you validate with customers?

Successful commercial projects require customer involvement and validation throughout the process. It is too lateto wait until the beta testing phaseto get customer validation! Thinkof projects you have worked onin the past. By the time youreach beta, there is momentum and tremendous pressure to finish the product so you can ship and recognize revenue. If significant design flaws are uncovered during beta, you will not be able to redesign during that cycle.

Include customer validation steps in the plan. The product manager should make sure it happens, but does not own the usability testing itself. (This is part of the “how” and the design, owned by the product architect.)

End (Post-development)

Did you solve the problems?

When defining the product, start with the problem to be solved, then during the planning phase, validate with customers that the product requirement will allow them to solve their problem. Then, QA ensures the product requirement is verifiable and that the specification meets the requirement. Finally, QA assures that the product built meets the specification. Part of the test plan should be to ensure the problem was solved!

Conclusion

Outsourcing has actually been around for a very long time. In today’s world with the internet and technology improvements that allow global communication, outsourcing has now become a global business. It is not going away. As a product manager, ensure you know what problem you are trying to solve before you race to outsource the solution.

Answer the questions in this article, and take a fact-based approach to outsource the right projects with the right partner for your company.

Resources