Software Development
Converting in-house development departments into smaller units providing on-demand, virtual, global teams takes a new set of business practices. Here are seven steps—from my own experience—to making the offshore relationship work.
1. Choose the Right Partner
Hiring an outsource contractor is like signing on a whole new department of developers or testers: You need more than just the right skills and knowledge. Contracts must ensure the use of a dedicated team; in many offshore situations, the supplier can offer a “shadow team” at no additional cost. This offers added protection against staff fluctuations and the inevitable turnover of key resources. On one of our contracts, for example, we discovered that key developers were supported by junior staff “buddies.” While these buddies were not charged to us, they offered some risk mitigation in case a lead developer was reassigned. But it also fostered the feeling that the contractor could easily switch resources on us.
Apart from technical qualifications, the supplier should have a well-defined development process. Among the multitude of outsource suppliers, many companies lack the infrastructure and processes for consistently high-quality work. For this reason, and to avoid the “low cost equals low quality” perception, many offshore companies, especially in India, have become obsessed with quality certifications such as ISO or SEI-CMM accreditation.
Understanding cultural differences between customer and offshore supplier is essential. Contractors in some parts of the world may be too agreeable and eager to please, avoiding uncertainty and hesitating to ask for help. This desire to “save face” can lead to unresolved issues or misinterpreted specifications. In one situation, we received several incremental builds that not only failed some very basic test cases but in many instances created fatal errors on start-up. For several weeks, we were assured that these problems would be resolved with the next build. Finally, we had a conference call with management and found that the contractor team didn’t understand our specifications and had shipped us broken code to give themselves more time to figure out the design.
2. Choose the Right Type
The inherent risk of outsourced projects increases with the degree of innovation required. Developing new products involves tweaking unstable specs and gaining new insights that invoke frequent changes. At the SPC, we learned this the hard way when we outsourced part of the architectural design of a new product. Since we didn’t fully communicate details of the target environment, we had to rework the design several times to overcome communication problems. It became clear that it would have been safer to develop this early part of the project ourselves and outsource only the later stages. In essence, it was our fault to include the contractor in a project phase during which we were still iterating on some fundamental design concepts.
Most outsource suppliers are more like software factories that can produce quality products based on detailed blueprints. Innovative capability should remain your own development team’s core asset.
The less interaction required, the higher the chances of success. For example, UI design requires many prototypes—not the kind of activity you want to conduct across the ocean. You should also be aware that aesthetics and cognitive responses differ greatly between cultures. A screen designed in Asia may not appeal to a Western audience.
3. Choose the Right Phase
In general, the earlier phases of projects are less suited to outsourcing than the later ones. The definition phase requires domain expertise and creativity, and is best done by your own staff. Outsourcing becomes more feasible with design, depending on how critical it is. If the application must integrate tightly with other systems, for example, it should remain in-house. If it doesn’t matter how the system is designed as long as it meets the specification criteria, design can be outsourced. The labor-intensive, final project phases, including coding, testing and maintenance, are generally good outsourcing candidates.
4. Manage Communication
Effective communication is probably the most critical outsourcing success factor—and its importance depends on the magnitude of the effort. If just a segment of your project is outsourced, you may require only the project or contract managers on each end to communicate. But this is a rare situation—more typically, team members on both sides collaborate on the same project, in which portions of the work are parceled out with a clean definition of interface points. In these cases, multiple team members on each side need to communicate, requiring a detailed definition of roles and responsibilities, means and frequency of communication, and ways to resolve issues.
5. Write Detailed Specifications
Specifications are the essential reference document for an outsourcing contract. Depending on what phase of the project is outsourced, this may be a requirements or design specification.
In an outsourcing situation, especially a new one, specifications must be considerably more detailed. An outsourcer who is unfamiliar with the application may not grasp details that may appear obvious to internal staff. Differences in language and culture can lead to misinterpretations. In my experience, clarifications by phone or e-mail are sometimes difficult and may require several cycles to resolve even a single issue. This can be very time-consuming and can even stall a project if too many issues are pending.
The need to clarify many specification issues might cause a contractor to argue he is losing planned project time, leading to schedule slips and cost overruns. Certain clarifications may also be interpreted as scope changes, with a resulting cost and schedule impact. When you’re estimating an outsourced project budget, the cost allocated to specifications development should be significantly higher than for in-house projects.
Given the importance of requirements specifications and the need for unambiguous understanding, I recommend that you use a requirements management tool as a facilitator for long-distance, asynchronous communication on complex issues.
6. Manage Changes
Almost all projects undergo frequent change. Here, again, the physical separation of client and supplier makes a tool-based solution the preferred approach. If all aspects of the project are outsourced, synchronization of artifacts is less critical, but if parts of the project are handled on both ends or if, for example, testing is performed by a third party, you need an industrial-strength change management tool. Establish a formal change control board—with members at both ends—to deal with mutating specifications.
7. Manage the Project
Good tracking and oversight are essential. Isolated from the team, without the opportunity for face-to-face meetings, the client project manager on outsourced projects can estimate progress only through communication with team leads or project managers at the supplier end. This lack of human contact must be compensated for with detailed and frequent status reports.
Meeting milestones is generally a good indicator of project health. I’ve found that repeated and unexplained delays are a clear sign that the contractor is running into trouble.
Project management also relies on effective human interaction. The best communication tools can’t replace face-to-face contact. It’s best to plan several trips to the supplier site—this is a more effective method, by the way, than visits from key supplier staff. These trips can be costly, but they certainly pay off. I’ve worked on both projects that ran purely on the basis of long-distance communication and others that relied on periodic trips to the supplier. The latter proved very successful, not only ensuring that the project is on track, but also establishing a personal relationship that makes subsequent long-distance communication more effective.
An important element of project management, especially for outsourcing situations, is managing risk: Consider it an early warning system to catch problems before they become disasters. Designate staff responsible for managing risk at both sites. Create a list of the top 10 risks at the start of the project and periodically review and update the risk situation as necessary.
Typically included in the statement of work, an acceptance process should be defined at the project’s beginning, and should be followed for all deliverables. It should define roles and responsibilities, as well as a time limit for each review cycle. In some of my outsourced projects, I used an independent third-party testing company to perform quality assurance on all interim and final deliverables. This impartial approach gave me an objective perspective on the quality of deliverables and reduced the potential for conflict.
At the end of any outsourced project, whether it succeeds or fails, review the experience. Exchange the lessons learned and document suggestions for improvement. If you plan to use this supplier again, include key staff from the contractor in the retrospective.
Ever-Present Process
Outsourcing will soon become an integral part of most development organizations. The recommended process for conducting outsourced projects isn’t much different from generally accepted best practices for software development, but certain parts of the process need much more attention than do traditional in-house projects.
With careful planning and continued monitoring, your company’s first outsourced project can be used to establish a good working interaction and to fine-tune the process for a lasting partnership.
| The Right Stuff Good projects for outsourcing share many of the following factors:
|
Detailed estimation helped this outsourced project come in on time and near budget. Our first outsourcing project was a feature upgrade to an existing system. The application was a fairly large, student information system tracking class scheduling, logistics, grading and other administrative tasks for some 10,000 educators and tens of thousands of students. The upgrade included extensions to the database schema and significant changes to report generation. Our specifications were very detailed, and before soliciting a quote from our Indian contractor, we counted the number of requirements. Combining this information with experience data from past projects, we used a commercially available estimation tool to generate the likely project effort, which was a range that depended on several cost drivers. Apart from the usual cost drivers—team experience, application complexity—the major factor turned out to be a schedule constraint: The system had to be ready for the coming school year. Initially, we communicated entirely via e-mail and change- and project-management tools. About a third of the way into the project, the constant frustration on both ends came to a head. We realized that we needed face-to-face meetings to better express our needs. We sent our lead designer for an initial one-week visit to the contractor site. This proved to be so beneficial that we continued with face-to-face meetings every two months for the remainder of this one-year project. This added about $5,000 per trip to the project cost.
Although the project was not without its challenges, our customer considered
the result a success: We delivered a working system on time and very close to
budget. In fact, the project completed only 15 percent above the original cost
estimate. Considering some changes in specifications along the way and considering
this was the first outsourced project, involving our customer, the Indian development
contractor and the Canadian testing company, this cost overrun is quite acceptable.
Cost savings from offshore outsourcing were approximately 50 percent. —W. Strigel |
Wolfgang B. Strigel is a member of the IEEE Software editorial board and is based in Vancouver, B.C., Canada. He has also worked at the Software Productivity Center Inc. in outsourcing product development to India, managed outsourced testing through QA Labs Inc. and developed process material and taught courses on the topic.
