Design Thinking in Times of Subcontracting, Outsourcing and Offshoring
A few days ago, we were discussing Design Thinking principles at a large software development organization based in Bangalore, India. The office was the hub of a 250 person banking project nearing delivery of their first phase to a US bank.
After around ten minutes of discussions, one of the project managers said, “We cannot implement Design Thinking in our project. It won’t work in most projects that our company executes.”
She went on the explain how they had no possibility of any contact with the retail customers of the bank, who are the main end-users of the software that was being developed. She explained the various layers of intermediaries that had been set-up through subcontracting, outsourcing and offshoring. A simplified version of the situation is depicted below.
Here is more information on the complex situation:
- The bank had hired a local US based consulting company to prepare the Business and Customer Requirements. The consulting company, which was a reputed ‘expert’ in banking did not observe or talk to the retail customers. They had a few meetings with managers at the bank and submitted the requirements document.
- The bank then floated an RFP (Request For Proposal) for outsourcing the software development work. A US based IT Services company won the contract as they had a low-cost off-shore delivery center in India. Their US presence was also treated as a plus point (‘can be sued more easily in case of any breach!’).
- The team in Bangalore consists mainly of hardcore tech people, though some of them have been involved in banking applications in the past. The main reason they were chosen for offshoring was their tech capability, lower cost, and ability to scale up fast.
- The Onshore IT Services team consists of Project Managers and Accountants whose job involves making sure that all legal terms are satisfied, that billing is complete, and any extra work is compensated for. Meeting the needs of end-users is not part of their job scope or priorities.
Given this situation, it is likely that many years will pass before the software becomes useful and usable, and the process will probably include several Change Requests, a lot of blame allocation, and contractual wrangling.
The situation described is not unique. It is typical of any large software development effort, and many engineering design projects (automobile, aerospace). The fact is, outsourcing and offshoring have significant advantages of lower costs, access to specialized skills, and ability to scale. Such modalities are here to stay.
So, how does one solve this “wicked” problem of the distance between the developers and the end-users in such situations?
Please feel feel to share your views, experiences or queries, using the “comments” feature available.
Nothing Official About It! – The views presented above are in no manner reflective of the official views of any organization, community, group, institute, or association. They may not even be the official views of the authors :-).