Articles
IT outsourcing has its roots in one simple business directive: save money. Early users of outsourced IT were looking to either lower their current costs, or undertake new initiatives based on the lower rates of offshore suppliers. As recently as 2005, a Gartner Inc. study found that, ". . . the majority of organizations worldwide are still focused on tactical IT outsourcing to achieve short-term, cost-focused objectives."
Read more Much debate has existed over the last few years on the topic of Agile development processes and their suitability for managing/coordinating offshore development projects. Our experience at Coherent Solutions during that timeframe is that Agile is superior to traditional “planned” methodologies for managing offshore teams (although traditional methodologies can be used effectively as well). This experience, however, is counterintuitive to what one would expect. Intuitively, one would think offshore would require more process overhead, more documentation, and more control and that Agile would be a poor match.
What’s the secret to reducing cost and accelerating the delivery of offshore software development? Move business analysis offshore, too! That's right. There’s now a growing body of evidence that doing so will reduce the costs of developing requirements while still maintaining high quality (Powell, Piccoli, & Ives, Winter 2004), (Nath, Sridhar, Adya, & Malik, October-December 2008). At Coherent Solutions, our experience indicates that companies will achieve greater efficiency from their programming staff by co-locating business analysts with their offshore programming team.
Offshore outsourcing can offer significant advantages in software development, including cost savings of 50 to 70 percent compared to internal development or onshore development firms. Yet virtually everyone has heard of or had first-hand experience with the less-attractive aspects of offshore development—costs are often far higher than predicted, delivery timetables continually have to be modified, and delivered software is so defective that it virtually has to be redone.
Requirements and software development have a strange and sometimes strained relationship. Good requirements are a prerequisite to ensuring you (the buyer) get what you need. But written in a prose style, they rarely offer a complete picture for the developer. Thus, over the years, software developers have made many attempts at improving this situation. One consistent mechanism they have used is actually showing you what you will get—first by writing and sharing prototypes and eventually evolving to developing and demonstrating working software.
