Specifying Requirements for Outsourced Projects
Rather than building software systems in-house, many organizations outsource development to contract development companies. They might outsource the work to take advantage of skills they lack 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 (BA) 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 several requirements-related challenges:
- 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.
Poorly defined and managed requirements are a common cause of outsourced project failure. With outsourcing, you won’t have the same opportunities for quick clarifications, decision making, and changes that you enjoy when developers and customers work in close proximity. Particularly with offshore development, expect 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 record.
As with in-house development, visual requirements models augment functional and nonfunctional requirements for outsourced teams. Models are even more valuable if you’re working across cultures and native languages, as they give developers something to check their interpretations against. Be sure the developers understand the modeling notations you use and interpret your diagrams 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 requirements author acknowledged that the contractor who implemented the software wouldn’t know just what “support” meant in each case. A glossary also is valuable when dealing with people who don’t share the tacit knowledge held by those who work in the acquiring company.
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 can’t deliver. When you bring an error 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 local 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. The contract should also define the process for incorporating changes into the product.
Acceptance Criteria
Define in advance how you’ll assess whether the contracted product is acceptable. 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 them? Include acceptance criteria in the RFP so the supplier knows your expectations up front. Validate the requirements before you pass them to the outsourced team, to help ensure that the delivered product will be on target.
Properly handled, outsourcing 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 likely is at least as much your fault as theirs.
==============
This article is adapted from Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty. If you’re interested in requirements, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources. Karl’s latest book is The Thoughtless Design of Everyday Things.
