One of my clients was trying hard to outsource software development, and has implemented processes for identifying candidate projects. The rules were pretty reasonable:
- Existing software is documented in a suitable way (from requirements over specification and design to programming and rollout). “Suitable” means “competent people without prior knowledge of the project have access to enough information to extend the software successfully with reasonable effort”. That, by the way, is a pretty good definition of the quality any documentation should have.
- The customer is aware that development is being done offshore, is willing to live with that, and accepts that documents provided by him to the project and documents produced by the project are written in English.
- Processes are in place that allow for clear specification of stable requirements, and clear separation of phases and responsibilities.
- The offshore workforce is reasonably stable so trained personnel is available over a longer period of time.
The problem was that pressure to increase the amount of offshored projects was so high that projects got moved to India, no matter the cost – ironically.
Here an example of a gone wrong (= more expensive then before) project transition:
- The existing software was developed under high pressure, meaning “coding before design” and “we’ll do documentation when we have time”. That meant no overall design, and no documentation.
- The customer did neither produce nor accept documentation written in English. All documents exchanged with the customer had to be translated at additional cost that couldn’t be billed to the customer. Translation was done in India, and results had to be proof-read by German personnel.
- Because of sluggish processes a of lot of time got wasted between the customer voicing a request and the production of usable requirements.
The offshoring guidelines were very reasonable, but they were completely ignored. I can’t give any other advice than to “stick to the plan”, if the plan is reasonable.