Design Thinking in Times of Subcontracting, Outsourcing and Offshoring

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.

Design Thinking in Times Of...

Here is more information on the complex situation:

  1. 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.
  2. 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!’).
  3. 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.
  4. 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 :-).

16 thoughts on “Design Thinking in Times of Subcontracting, Outsourcing and Offshoring”

  1. Hi Rajesh, this is a classic problem of development not knowing the “bigger picture”. This would definitely either fail or result in huge production / re-work cost. But, I’ve been assuming that this problem was of dinosaur-age…! Agility is the current name-of-the-game. There are KPIs that measure how fast solution reaches production. In this multi-tiered responsibility, no one would take the blame or everyone would take the blame. More interaction between the business and development team only will resolve this problem. We can use any buzzword for the same viz. DevOps / Agile / TTM and all that, finally business wants to beat the competitor and gain a better market share, period. If only our solutions are aimed towards that, IT organisations will survive, else they would perish – soon…!

    1. Hi Ram,

      Even in projects that use the Agile methodology, I have seen that the development team is far removed from the actual end-users. All requirements are channeled to the development team through a “Product Owner/ Manager” who interacts with other people in the customer organization. The people who provide requirements in the customer organization are not necessarily the end-users!

  2. It is indeed a “wicked problem” . With the chain of intermediaries increasing the distance between the customer and the solution designer, understanding and empathizing with user personas, which is the key to design thinking, becomes a challenge.

    In my view, the problem statement then changes from “designing the software” to “solving the communication divide between solution designers and end customers” as a necessary 1st step.

    And design thinking can be used to solve this. This may result in tweaking the delivery/engagement model, identifying focus groups (of retail customers), designing collaborative approaches between all the intermediaries (and factoring this as part of the RFP/delivery proposal) to enable solution designers to engage with end user focus groups and so on.

    Traditional outsourcing contracts may need to be re-designed to enable more effective customer centric solutions. Taking a product view of traditional service delivery (productizing services) may be necessary.

  3. The point then is, who will take the initiative to make this change? Is it the offshore delivery organization, the onshore partner, the business analyst consultants, the strategic consultants, or the customer organization?

    I believe that the customer organization (like a bank) has to take the initiative in changing the situation, because they will have to take the perceived risks of the change, provide the budgets to support non-specifiable outcomes, and also reap the benefits of better systems and to service their end-users. Other entities in the chain are likely to be happy to join in (as long as their billing is not affected :-)).

  4. An ideal contract should be a shared risk contract. A traditional fixed price contract has a risk bias (+) towards the customer, whereas the T & M has a bias towards the supplier. A balanced contract where the risks are balanced with a reward and penalty clause should be the norm. Most Fixed price Agile contracts are going this way now. What I have also seen is having two SOW’s signed, one for the initiation place of the project and another for the execution phase.

    1. Vasanthan,

      Please consider these situations:

      In a fixed price there were hidden requirements and the supplier has to expend more resources than planned. Risk for Supplier.

      In an T&M contract the supplier is prolonging unwarranted and is maintaining head count just for billing. Risk for customer.

      I kind of like the two SOWs you mentioned. I would call the first one to evolve the requirements to reasonable level and form and the second for the rest of the SDLC phased in scope. I might also suggest a third SOW for independent testing.

  5. Yes, Banks (in this case) could take the initiative , since they will be the most impacted. And consulting organizations that draw up large outsourcing contracts could advise their customers accordingly while drawing up the RFPs. So that structures and environments to enable end user- solution designer connects are enabled. This might also mean investments by intermediaries on collaboration platforms, revisiting the onsite-near site- offsite operating models.

  6. It strikes me that you are trying to form a Keely Triangle with only Product Management and Engineering, and no UX Designers.

    I could go on for hours about what is missing from the above view of Design Thinking, but primarily the above team is lacking empathy for the end user. (Which is why most financial apps are horribly painful to use. And why I left my role at consulting firms serving the finance industry.)

    If I had a magic wand to make improvements to the above situation, I’d hire a UX designer to observe end users to witness pain points (with a PM and Engineer flown in from Bangalore observing as well) The UX designer would be responsible for leading the research, aligning the team, and communicating the results… and overseeing the agile iterations of the product as it matures. (Focus groups are better for evaluating marketing objectives… and much less effective for product design.)

    I’ve witnessed teams of engineers wonder why completion of the features of an RFP on time and on budget resulted in a product no one wants so many time it makes me Ill just thinking about it.

    All these poor outcomes are what happens when you teach kids STEM instead of STEAM.

    The scenario above will likely only change once a design lead team produces a more desirable product, which consumes market share, putting ineffective teams out of business… until their PMs copycat the features in an attempt to survive in the face of true innovation.

  7. If one has to apply “Design Thinking” to solve this “wicked” problem, then the perspective/approach has to change.

    The goal should not be to try and resolve communication issues or process issue – but at a much larger level – to redesign the overall business using Design Thinking – to cater to the retail customers. That is where the business is.

    Often, people try to solve the issue that is “seen” and ignore or fail to see the objectivity or the context of the need. So, fixing the communication by using better frameworks or methods may not help at all. Even KPIs, etc would only give data after the act has been completed.

    The initiator can be anyone who can add value to the system – but the Bank or the decision-making stakeholder should be convinced on the overall approach and change in the perspective.

    One needs to approach this from the perspective of a preventive/adaptive solution than that of a proactive or a reactive solution using a powerful tool like Design Thinking.

    As Prakash has mentioned, one needs to redefine the contracts – but it has to be more of an end-user centric than anything else. Yes, the monetizing aspects etc needs to be considered, but a good DT exercise would ensure that all these aspects are captured and mooted upon before arriving at a possible solution.

  8. Excellent perspectives from Andrew and Vijay.
    It will be great to deliberate on the application of design thinking concepts in a variety of business scenarios on this forum. More ideas and scenarios welcome.

    Look forward.

  9. Hi Rajesh,
    Thanks for giving insight clearly about whole topic.
    It will help me in someway or the other.
    Thank you!

Comments are closed.