Offshoring 1.0 — Specs offshoring. Key drive to win: Rigid process excellence
Back in the days when the practice of software offshoring started to pick up in various corporates globally, the main success criteria for the engagement were how well the specs were defined by the onshore company, and how well they were followed by the offshore development company. Large systems were designed and detailed in bundles of specifications with screen mockups and even defined databases, and each data field was defined to the atomic level. This was a readymade package prepared by the architects, BAs and software developers in developed countries for outsource to a company in India (or any other offshoring destination) who would develop and ship it back to the sourcing company. Most these projects were pre-estimated and meant to be delivered within fixed-price contracts. These engagements happened within rigid contracts, including penalties for low quality and time drops. Most these projects followed very rigid waterfall processes to address fixed specifications, defined extremely rigid change management processes, and clearly tracked delivery deadlines. These processes, introduced for software project execution and management, were imported from the construction industry, where they were used heavily for construction projects.
Furthermore, these processes evolved alongside other standards such as CMMI, ISO as well as PMI and Prince2 methods. Project managers at the offshore end often tracked key indicators such as volume of code produced per day and bug count per each individual developer. The trust between outsourcer and outsourcee was totally built upon references and contractual trust. With time, most onsite stakeholders also developed trust in one or two key project management individuals on the offshore side, as a result of frequent communication and delivery track record. Most of the time, the onshore-offshore engagement was built on single points of contact or a small number of managerial contacts from each side. Onshore-offshore ‘team trust’ was not quite visibly seen in this model and often onshore stakeholders were satisfied with a single point of contact from offshore vendor companies, so as to reduce the complexity and the cost of communication.
The biggest pain point of these projects was the lack of transparency in software production. The offshore teams saw only the output of the design process (in the form of confirmed specifications) and onshore customer saw the final product of the system only when it was completed as per the specifications. Often these projects failed to achieve “fit to purpose” and most projects had to go through very tiring post-delivery phases to fix the systems to make them “fit enough” to use. Budgetary and timeline overruns were quite typical in such situations. In most cases, the contract clauses were strictly enforced, and both offshore development companies and onshore customers had to bear the cost and pain of deviations after lengthy and time-consuming arguments.
However, we cannot argue that such contract- and specifications-focused approaches never worked in the industry. Major systems in banking and finance, Telcos and many other industries have developed robust systems using the offshoring 1.0 model, irrespective of the huge hidden costs, overruns and painful processes of offshore development with many additional complexities.
Offshoring 2.0 — Agility in offshoring. Key drive to win: Lightweight process, high onshore-offshore collaboration
Offshoring 3.0 — Innovation offshoring: Key drive to win: Business value addition via technology innovation