An Outsourcing Progress Report
I’ve written somewhat negatively about outsourcing in the past: primarily issuing warnings about doing it without proper planning, for the wrong reasons, or with expectations set too high.
Recently, someone close to me has had his own outsourcing experience. Software that he and his group would normally develop was being done by a group of software engineers in India. Since there were in-house developers available to do the work, the decision to outsource doesn’t seem to have been driven by a need to offload anyone’s work.
I don’t know how the outsource company was selected or if they had any prior experience with the domain, but they had no prior relationship with the primary company, so it was not a matter of maintaining an existing relationship. One is left to speculate that it had to be a cost decision (current or future).
My software-developer friend was relegated to quality monitoring. He reviewed the requirements spec, written by the outsource company, and because he understood the increased importance of the spec in this job, he tried hard to think about what might have been left out. Over the years, some behaviors had become SOP (standard operating procedure) at the company and were rarely included in specifications (right or wrong). Now they had to be spelled out, lest they be missing from the final product.
I had a chance to take a look at the spec, and I admit that I was impressed with its structure and thoroughness, and I thought that there might be a chance that this outsourcing experiment might work. I heard that they were asking good questions and requesting scenarios: good signs.
My friend is now running tests on the nearly-completed software and is now able to begin judging its quality (both of the software and of the spec). He is finding that the software runs the normal cases fine. That’s a good start. But : : guess what? The anomalous cases are failing. What happens when a piece of hardware is missing or the network is interrupted? The software freezes.
Were these anomalous cases included in the specs? My friend says “probably not”. They were SOP for the in-house group, just “good engineering practices”, and would have been done regardless of whether they were spelled out in a spec.
Will the company save money on this development? That remains to be seen. It’s not known how these “good engineering practices” will be handled by the outsource company, whether they will demand compensation for spec changes.
Perhaps the outsourcing experience is simply a way to train this Indian company for future work, and perhaps it’s irrelevant whether money was saved on this first development. Nonetheless, it’s a good case study of the role of a requirements spec in an outsourced development as well as a great example of the need to ask the right questions when developing the spec in the first place.
Anita Wotiz
www.duckpondsoftware.com (see the Consulting tab)
Instructor, UCSC Extension, SEQ Program
Software Requirements Engineering and Management (next class starts Aug 5 2008)
Software Project Planning, Monitoring, and Management (next class Oct/Nov 2008)
