Outsourcing differs from other development because there is bound to be a contractual relationship, probably a geographic distance, a different sense of loyalty, language misunderstandings, cultural differences, reluctance to speak up to the client – and many other associated problems. Good requirements are always a problem, but outsourcing increases the problems, and makes even great demands on the requirements specification. The payoff for doing good requirements is greater, and the penalty for not doing them is more threatening.
I am going to argue that we need to make use of far more explicit background specification for each requirement, a page or more of specification for each requirement. I will argue that this is a necessary investment – because failure to do so will probably cost far more – sooner or later. I will argue that failure to be more detailed than normal will be counted in the clients disfavor in any legal proceedings trying to determine responsibility for failure of the project.
Outsourcing Requirements Principles
Here is a set of principles for Requirements for Outsourcing:
- If anything can be misunderstood, it probably will be.
- Writers Are Responsible for Readers Wrong Renditions
- Assume Nothing, Specify Everything
- Too Much is Safer than Too Little
- If They ask a question, document and integrate the answer
- Quality Control before sending
- Evolve Requirement Delivery
- Quantify Quality
- Constrain explicitly
- Connect relationships
Let me explain them in more detail:
If anything can be misunderstood, it probably will be.
Every person has a strong tendency to interpret words slightly to largely differently from everybody else. When we ask 20-30 people to write down their interpretation of a short requirement statement, we always experience totally different, never identical answers from individuals working on the same project. We call this the ‘Ambiguity Test’ – and it really gets the point across to the whole group about how careful we must be when writing specifications that must be understood correctly.
Explicit Definition
One simple tactic we recommend in ‘Planguage’ or The Planning Language [CE] is to take the trouble to explicitly define any term that could possibly cause misunderstanding, and then ‘Capitalize’ the term to signal that the reader must interpret it with the official definition.
