Rather than building systems in house, many organizations outsource development to contract development companies. They might outsource the work to take advantage of skills they do not have available in-house, to augment their internal staff, or in an attempt to save money or time. The outsourced development supplier could be located physically nearby, on the other side of the world, or anywhere in between.
The role of a business analyst is even more important on these projects than on a co-located project. If the team members are all in one location, developers can walk down the hall to ask the BA a question or to demonstrate newly developed functionality. This close collaboration can’t happen in the same way with outsourced development. Compared to in-house development, outsourced—and particularly offshore—projects face requirements-related challenges such as the following:
- It’s harder to get developer input on requirements and to pass along user feedback to developers.
- A formal contractual definition of requirements is necessary, which can lead to contention if differences of interpretation are discovered late in the project
- There might be a bigger gap between what the customers ultimately need and the product they get based on the initial requirements, because there are fewer opportunities to adjust the project’s direction along the way.
- It can take longer to resolve requirements issues because of large time zone differences.
- Communicating the requirements is more difficult because of language and cultural barriers.
- Limited written requirements that might be adequate for in-house projects are insufficient for outsourced projects, because users and BAs are not readily available to answer developer questions, clarify ambiguities, and close gaps.
This article suggests some techniques for successful requirements development and management on outsourced projects.
Appropriate Requirements Precision
Outsourcing product development demands high-quality written requirements, because your direct interactions with the development team are likely to be minimal. As shown in Figure 1, you’ll be sending the supplier a request for proposal (RFP), a set of requirements, and product acceptance criteria. Both parties will engage in a review and will reach agreement, perhaps with negotiation and adjustments, before the supplier initiates development. The supplier will deliver the finished software product and supporting documentation.
Figure 1. Requirements are the cornerstone of an outsourced project.
With outsourcing, you won’t have the same opportunities for day-to-day clarifications, decision making, and changes that you enjoy when developers and customers work in close proximity. Particularly with offshore development, you should anticipate that the supplier will build exactly what you ask them to build. You will get no more and (hopefully!) no less, sometimes with no questions asked. The supplier likely won’t implement the implicit and assumed requirements you thought were too obvious to write down. Poorly defined and managed requirements are a common cause of outsourced project failure.
As with in-house development, visual requirements models augment functional and nonfunctional requirements for outsourced teams. Using visual models to supplement written specifications is even more valuable if you are working across cultures and native languages, because it gives developers something to check their interpretations against. However, be sure the developers can understand the models you send them and interpret them accurately.
Prototypes can also help clarify expectations for the supplier team. Similarly, the supplier can create prototypes to demonstrate to the acquirer their interpretation of the requirements and how they plan to respond to them. This is a way to create more customer-development interaction points to make course adjustments early in the project rather than late.
Watch out for the ambiguous terms found in Chapter 11 of Software Requirements, 3rd Edition that cause so much confusion. I once read a requirements specification intended for outsourcing that contained the word “support” in many places. The BA who wrote the requirements acknowledged that the contractor who was going to implement the software wouldn’t know just what “support” meant in each case. A glossary is valuable when dealing with people who don’t share the tacit knowledge held by those who are familiar with the acquiring company’s environment.
Acquirer-Supplier Interactions
Without real-time, face-to-face communication you need other mechanisms to stay on top of what the supplier is doing, so arrange formal touch points between the acquirer and the supplier. Plan time for multiple review cycles of the requirements. Use collaboration tools to facilitate peer reviews with participants in multiple locations. Incremental development permits early course corrections when a misunderstanding sends the supplier’s developers in the wrong direction. If the supplier raises questions, document them and integrate the answers into the requirements. Use an issue-tracking tool to which both supplier and acquirer teams have access.
Outsourced projects often involve teams with disparate company cultures and attitudes. Some suppliers are so eager to please that they agree to outcomes they cannot deliver. When an error is brought to their attention, they might strive to save face by not fully accepting responsibility for the problems. Some developers might hesitate to ask for help or clarification, or to say “I don’t understand.” Employ elicitation and facilitation techniques such as reading between the lines for what isn’t said and asking open-ended questions. Establish ground rules with all team members regarding how they should interact when they work together.
Developers whose first language is different than the language in which the requirements are written might not pick up nuances or fully appreciate the implications of certain statements. They might make user interface design choices that you wouldn’t expect. Things as diverse as date formats, systems of measurement, the symbolism of colors, and the order of people’s given and family names vary between countries. The requirements should avoid the use of colloquialisms, jargon, idioms, and references to pop culture that could be misconstrued.
Change Management
At the beginning of the project, establish a change control process that all participants can use. Using a common set of web-based tools for handling change requests and tracking open issues is essential. Identify the decision makers for proposed changes and the communication mechanisms you’ll use to keep the right people informed. The outsourced development contract should specify who will pay for various kinds of changes, such as newly requested functionality or corrections made in the original requirements, and the process for incorporating the changes into the product.
Acceptance Criteria
Define in advance how you’ll assess whether the contracted product is acceptable to you and your customers. How will you judge whether to make the final payment to the supplier? If the acceptance criteria are not fully satisfied, who’s responsible for making corrections, and who pays for those? Include acceptance criteria in the RFP so the supplier knows your expectations up front. Validate the requirements before you give them to the outsourced team, to help ensure that the delivered product will be on target.
Properly handled, outsourcing the development work can be an effective strategy to build your software system. An essential starting point for a successful outsourcing experience is a set of high-quality, complete, and explicitly clear requirements. If the requirements you provide to the supplier are incomplete or misunderstood, failure is probably at least as much your fault as theirs.
Authors: Karl Wiegers is Principal Consultant at Process Impact, www.processimpact.com. Joy Beatty is a Vice President at Seilevel, www.seilevel.com. Karl and Joy are co-authors of the award-winning book Software Requirements, 3rd Edition, from which this article is adapted. Karl's most recent book is Software Development Pearls: Lessons from Fifty Years of Software Experience.