Requirements for Outsourced Projects
In short When another company builds or tests your software, the requirements become part of the contract. They must be ready earlier and written more precisely than for an in-house team, because the contractor will build what is written, no more and no less.
Based on: K. Wiegers, J. Beatty, Software Requirements, 3rd ed. (Microsoft Press, 2013), ch. 23; I. Kornipaev, Requirements Management, course slides (in Russian), section on RFI and RFP tenders.
On this page
Key ideas#
What is different about this kind of project#
Compared with in-house work, Wiegers and Beatty point to: - slower feedback between developers and users; - a formal, contractual definition of requirements, so differences in interpretation surface late and cost a lot; - a wider gap between what customers expect and what they get, with fewer chances to correct course; - time-zone delays in resolving questions; - language and cultural barriers; - terse requirements that worked in-house are not enough, and the business analyst is not always on hand to clarify; - remote developers lack the business knowledge local staff absorb over time.
The authors observe that offshore projects often cost more than expected, not because of rates, but because of extra effort on precise requirements, rework for unstated requirements, contract negotiation, and heavier communication and oversight.
Requirements are the contract#
The acquirer issues a request for proposal (RFP) with a requirements specification and acceptance criteria; the supplier estimates and the parties negotiate; the supplier builds and delivers software and documentation. Without daily contact, a contractor will not implement requirements you thought too obvious to write down. So develop requirements earlier in the schedule and in more detail. Thoroughness that might look excessive in-house becomes a virtue here.
Make meaning travel#
- Visual models cross language barriers and let developers check their interpretation, but only if the contractor knows the notation.
- Ambiguous words such as “support” cause real confusion across languages. The authors describe a project where that one word did exactly that. Also avoid idioms, jargon and cultural references, and spell out date formats, units and name order.
- For quality requirements, the authors recommend Planguage, a structured notation for stating them precisely.
Working together#
- Plan several review cycles. In some cultures reviewers avoid openly criticizing others’ work; find this out early and adjust your approach.
- The authors describe a failed project whose plan had a week of requirements workshops but no time to document, review and revise the specification. With slow, long-distance communication, the schedule collapsed and the dispute went to court.
- Deliver in small increments so misunderstandings surface early.
- Record every contractor question and its answer in the requirements, in a system both sides can reach.
- Some suppliers agree to the impossible to please the client, or hesitate to say “I don’t understand”. Ask open questions and agree explicit rules of engagement.
- Split the burden: the acquirer supplies complete information; the supplier asks instead of assuming.
- The authors also describe an offshore team that implemented each requirement literally, one at a time, without grasping the whole. The client ended up redoing most of the work itself.
Change and acceptance#
Use one change process and shared tools for change requests and defects, wherever people sit. The contract should state who pays for which kind of change: new functionality versus corrections to the original requirements. Define acceptance criteria and put them in the RFP (“begin with the end in mind”, as Covey puts it), and approve the requirements before handing them over.
Running the tender#
Kornipaev’s course describes the acquirer’s side. Organizations tender when they lack capacity or expertise, or when a ready-made product looks attractive. The stages: market research → request for information (RFI) → RFP → decision.
On the bidder’s side, he notes a risk: questions asked during a tender may reach competitors. A bidder can ignore the issue, make a documented assumption, or ask anyway. Bidders should keep all tender materials, including assumptions and unasked questions: contracts can take a long time to sign, and the project team is often not the bidding team.
Example: RFP outline#
Based on the structure in Kornipaev’s course:
1. Confidentiality
2. Introduction: purpose, scope, dependencies, referenced documents
3. About the acquirer
4. Instructions to bidders: conditions, budget and payment principles,
the acquirer's right to change the RFP or reject bids,
requirements for bidders and for their responses, pricing
5. Timeline: issue, intent to bid, questions and answers, responses,
presentations, shortlist or selection, contract
6. Selection criteria: team expertise, technical proposal, cost
7. Appendices: questions for bidders; the requirements
(stakeholder or system level)
For The Workshop, a fictional bike-repair chain hiring an outside team, the requirements appendix holds the booking and notification requirements. Following Wiegers and Beatty’s advice, it also includes acceptance criteria such as “a customer can book, change and cancel a slot from a phone browser”.
Checklist#
- Requirements are complete and approved before the RFP goes out.
- Acceptance criteria are in the RFP.
- Ambiguous terms are removed or defined in a glossary.
- Models use a notation the supplier knows.
- Several review cycles are planned, and cultural review habits are understood.
- Questions and answers are logged where both sides can see them.
- Deliveries are small and frequent.
- The contract states who pays for which kind of change.
Sources and further reading#
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 23.
- I. Kornipaev. Requirements Management, course slides (in Russian): RFI and RFP tender stages and document structure.