One of the main points of discussion in this workshop was: "What is the journey?" That is, how to we get started along the road to outsourcing and global development and what do we find when we get there.
Some definitions:
The main conclusions of this workshop are found in sections 4.5 and 5 of this document -- "Core Questions for Executives" and "Crystal ball -- what will the situation be in 5 years?"
Our initial workshop discussion was a "spiral" discussion -- starting from core reasons to employ outsourcing and global development as well as the skills that are needed to be successful.
This initial brainstorming raised a large number of issues, so in order to create some useful conclusions, we decided to answer two fundamental questions:
These two questions created a lot of discussion, and the result was some long lists of factors, issues, and effects. The following two subsections below summarize what we learned.
There are a lot of things to say about each of these subjects. First, cost is something that is very difficult to gauge. The cost savings for outsourcing might not be dominated by the difference in wage rates for the workers -- and there are a lot of hidden costs that are missed in a hasty analysis.
Freeing up experts by migrating routine development or maintenance work to an external company or offshore to a low-cost organization can sometimes work well. Many developers in North America or Europe don't want to do maintenance work because it isn't fun or it isn't valued by their management or peers.
Herd mentality or fashion is the notion that you have to move to an outsourcing model just because the competition is, or other companies in similar industries are outsourcing. It isn't a good rational motivation.
Some secondary reasons were also raised: getting access to additional technical experience not available within the company, seeking to open new markets by having a local presence in the target countries, and increased flexibility in managing staffing levels.
In most outsourcing models, communication is something that becomes more complex. A compact software development team in one location within a single company has an easier time working with looser problem definitions, informal but frequent discussions of requirements and architecture issues, and less stringent quality control. For a partially or completely outsourced product, the informal discussions are replaced with more formal requirements models, legal contracts, acceptance tests, and key process indicators. Often, the communications channels between a company and its service provider need to take into account the cultural differences and some technical process differences between the two organizations. Effective communications requires attention to clarity, context, focus, and scope.
Quality is linked to a set of skills and practices: teams will use appropriate tools and processes for testing activities and other quality control work in the outsourcing context. Most successful outsourcing activities have well-defined quality assurance metrics that are collected and reviewed regularly.
Risk management needs to be done as thoroughly as possible when doing outsourcing. One big challenge here is to match the risk management work to the delivery cycles of the product.
Other secondary skills that were mentioned in the session: an understanding of the structure and processes of the service provider, a good shared "vision" of the products being built, and time zone management.
In this section and in the next section, the discussion revolved around finding some "roles within a company that are involved with the decision or consequences of outsourcing". The names of the roles don't necessarily match job titles -- but almost every company involved in software development has someone wearing each of the hats described here.
For the three management levels listed here, there are a bunch of issues and items that are considered in the process making the decision of whether to outsource and how to outsource. (By the way, some of these issues and items are reasonably rational, others are quite irrational -- but actually observed in real life.)
The Executive is company CEO or business unit head (in a large company) -- the person who is responsible for longer-term decisions, strategic plans, and the relationship with the stockholders. When deciding whether and how to outsource, the Executive considers these things:
The Operation manager is the person who is responsible for overseeing a large functional organization or business unit within a company. This person usually makes the call when balancing the resource demands of several competing projects.
Most of the issues and items to consider are the same for the Operation manager as for the Executive -- except for company image. There are a few additional items:
Also, the Operation manager is usually making decisions based on one-year budget cycles, so his/her focus is different from that of the Executive. The Executive handles the longer-term strategy for outsourcing.
Project managers have an impossible task -- because they are usually not brought into the decision making process until many factors are already decided. They do get some input into how the outsourcing activities might be organized. They gather information about the following factors:
This next list presents the set of things that will change in the jobs of technical folks and various kinds of managers:
A Product Manager (different from a project manager) has ongoing responsibility for the lifecycle of a family of products. He/she has to worry about how the products work together and what the customers' perception of their value will be. A Service Manager is like a Product Manager, but he/she is responsible for a family of services provided to customers.
In some cases, a company receives development cost pressure from its customer. A company that is contracted to build a software product for a big important customer might be almost forced to do outsourcing or offshoring to a low cost country -- because the customer says that they are only willing to pay a "blended day rate" of 250 pounds sterling per person-day. This cost may only be achievable by doing 90% offshore and 10% onshore. (Note that this is a pretty scary mentality on the part of the customer -- they aren't looking at value, only at cost. It is driven by IT consultants that are trying to follow the herd.)
Quality and cost are usually linked very closely. Although the cost can be reduced in some cases through outsourcing, it is important to consider to what extent the service provider's workers will have adequate domain knowledge. This will be more true for commodity areas of technology -- standard e-commerce for example. On the other hand, a company that wants to outsource software work in an area of their "core competencies" (the area or areas in which they have an advantage over their competition), it is highly unlikely that the service provider will have workers with adequate domain knowledge, and it would be a big mistake for the contracting company to provide training to fill in that missing domain knowledge.
There is always a "delivery risk" involved in any outsourcing relationship. Since the service providers deliverables will be spelled out in some kind of combination of written agreements and requirements documentation, it is possible that the contracting company will get what they ask for without actually getting what they need. The increased formality of parts of the software lifecycle can be both good and bad -- and it is especially bad if the requirements are not really very clear or firm.
In many outsourcing situations, the contracting company may be displacing existing software staff -- particularly software developers. This causes a lot of bad feeling: stress, fear, conflict. This can result in a diminution of good communication, innovation, creativity, and quality among the existing staff -- if they feel that their jobs are under threat.
Communication with the service provider can be quite difficult at times -- especially since it becomes cross-cultural communication. For example, in some cultures (such as Japan), saying "no" is difficult for technical staff to do, because they lose face. It may be necessary to come up with different ways to rephrase questions or make requests in order to get information and/or results -- need to match up with the culture of the service provider organization.
One thing that makes cross-cultural communication easier is to use lots of drawings and pictures (as opposed to straight text) in problem definitions and descriptions.
Legacy system outsourcing is often a "bigger win" than attempting to outsource a new product or a product in the prime of its lifecycle. This legacy outsourcing can help free up expert resources to work on new things.
There are so many things within the software lifecycle that are hidden -- back channel communications between developers and business analysts, discussions in the hallway or at the coffee machine, lessons learned from previous failures in an organization down the hall. In order to understand what the true costs of the actual activities for a software development project, it may be necessary to bring in a social anthropologist to observe everything, not just the activities that are on the organization's official process.
How much of the testing burden will be executed by the service provider? How much will fall on the contracting company? If the tests are being used to monitor the progress of the service provider, what is the interval that test results should be reported? What kind of feedback should appear on the project manager's dashboard? How about the executive's dashboard?
The tactics of managing outsourcing activities might follow a bunch of models. In the workshop, we briefly discussed two models: RACI (Responsibility, Accountability, Consultation, Information) and RA2 (Responsibility, Accountability, and Authority).
There are four categories of outsouring risk described in the book The Outsourcing Revolution by Michael F. Corbett. This book discusses all kinds of outsourcing, not just IT services. However, the book's risk categories are equally applicable to many domains. The four categories are Strategic risks, Operational risks, Results risks, and Transactional risks.
These risks are difficult to estimate, but a good manager will at least try to get the order of magnitude.
It isn't a good idea to hope to break into a new product area or solve some serious problems with an existing product development effort by turning to outsourcing. If you don't do it well domestically, you won't do it well through outsourcing/offshoring.
We discussed the most important skills needed by software developers -- the people who are the most threatened by the outsourcing wave. The three most important skills are:
Other useful skills:
If outsourcing really has a positive value, then there should be a set of indicators that management measures throughout the process to track the performance. The following things can be used to measure the ongoing outsourcing effort to see that it is effective:
All of the workshop participants felt that there are extra costs of outsourcing that are being ignored or overlooked by many managers:
Increasing value means that your customers must get a product that is as good or better, and it must be a product that gets increasingly better over time. If you choose to just hack together a product as cheaply as possible, with no consideration of its "value" over time, you risk disappointing customers now or in the near future.
Your value and costs computation might be missing many of the hidden costs -- see section 4.4 above for a good initial list that you should consider. You ought to consider tracking some of the Key Process Indicators listed in section 4.3.
You don't want the service provider company to turn around and compete with you in a couple of years. You ought to consider what forms of communication you will use to pass information from your company to the service provider. It might be necessary to seriously restrict the contents of requirements and architecture documentation that crosses the inter-company boundary.
A company's values are important. There are good lessons from books such as Built To Last: Successful Habits of Visionary Companies by James Collins and Jerry Porras. The companies that endure for a long time are the companies that have a set of "core values" that they defend, in the face of all kinds of business fashions. These core values are always about much more than making money.
All of the management literature on outsourcing says "don't outsource your core competencies".