Archive of Outsourcing Articles

When companies first start off-shoring, they usually send the “low level” implementation work overseas first, to work out the process kinks and manage risk. Over time, your valued, domain-aware developers will perceive a lack of career opportunities with this limited role. Naturally, you will want to consider sending design work offshore too. You can make it work. If you do it wrong, you’re toast.

Economic pressures are driving most companies in high-developer-salary markets to explore using offshore development teams as part of their approach to developing software. Developing software with a global team presents new challenges as well as new benefits. If you do it right, you can have a more cost-effective team. If you do it wrong, you can have a disaster.

One of the ten big rules of writing a good MRD is writing unambiguous requirements. Ambiguity is a function of communication. The writing can be generically ambiguous, or ambiguous to the writer. A requirement could be precise in intent, but ambiguous in interpretation by the reader. Understanding our audience is as important as precision in language. We write unambiguous requirements because misinterpretation of requirements is the source of 40% of all bugs in delivered software.

Allan Holmes, for CIO Magazine just posted a scathing and detailed autopsy of the disastrous Medicaid Claims System project run by CSNI and launched in January of 2005. Requirements elicitation failures combined with incompetent vendor selection and project mismanagement lead to a $30,000,000 oops for the state of Maine, jeopardizing its credit rating. The system failed to process 300,000 claims in the first 3 months of operations, causing many health care providers to close their doors – and presumably causing citizens of Maine to go without needed services. Maine is the only state in the union (as of April 2005) not complying with federal HIPAA regulations.

Frederick Boulanger picked up on our earlier post about different outsourcing process models, and extended it with his own good ideas- making it easier for teams to decide which outsourcing model is right for them. Frederick identifies the three key factors that determine which model is most likely to succeed for a given team. They are control, coordination, and communication. Anyone else want to join in? Blog away, and trackback or comment here.

topsyWidgetPreload({ “url”: “http%3A%2F%2Ftynerblain.com%2Fblog%2F2006%2F03%2F31%2Ffour-outsourcing-models-for-software-development%2F”, “style”: “big”, “title”: “Four Application Development Outsourcing Models” });

On March 30th CIO magazine published an article titled Do’s and Don’ts of Outsourcing Benchmarks. The article spurred us to write about outsourcing models for product development – it is otherwise unrelated, but interesting.

Alan Cooper presents the analogy that software development is like making movies in his book, The Inmates are Running the Asylum. Cooper is presenting the analogy in the context of validating the business case for investing in interaction design, but it holds true for requirements as well.

“71 percent of software projects that fail do so because of poor requirements management”