Tech Forum

Effective outsourcing

Article summary

This article does not talk about outsourcing the complete IT infrastructure. It is restricted to outsourcing software development.

Software outsourcing is being practiced for many years. Yet, the entire methodology has not stabilised completely. Further, all the entities involved in this process are far from satisfied.

Finally, the tangible benefits accrued as a result of outsourced development are still elusive in most cases.

While working in this industry, I have been witness to a lot of good and not-so-good practices and outcomes in outsourcing.

This article discusses the problems, the root causes and a set of guidelines that can be of help. This article is equally relevant to customers as well as vendors.

Quick definition

Although everyone knows what Software Development Outsourcing (I will call it SDO in this article), I will try to redefine it in English. Rather than defining it as a long, complex sentence, I will define it as a set of bulleted points.

• Software Development is initiated due to some internal business related need.
• SDO is done because it is impossible (no skills/time) or inefficient (higher cost) to do this in-house.
• This implicitly means that the outsourced vendor provides skills, time and cost advantage – without compromising the intended end result.
• Maintenance is a long-term task. This is best done internally rather than externally. The SDO process should also cater to this requirement and prove to be cost-beneficial in this area.
• People leave and technology changes. The end product should be manageable in spite of these problems.
• There must be some mechanism of proving that outsourcing did lead to benefits in all expected areas. Otherwise, we may continue outsourcing without realising that is counter-productive.

Parties involved

We tend to think there are only two parties involved – vendor and customer. However, things are not that simple. Here the word ‘party’ means an entity that has distinct objectives and role to play in the process. If you think from this point of view, there are a lot of parties involved. Here is a list. In order to make things clearer, I have also listed the base objective of each party.

As you can see, there are many entities involved and each one of them has a separate agenda. Due to this, the outsourcing outcome may not be optimal.

Common problems

Here are some common problems with the outsourcing process.

1. Users are not clear about their exact needs.

2. As a result, the specifications given to vendors are very sketchy. More of a wish-list rather than specifications. Specifications should be detailed, clear-cut and without any ambiguities.

3. Because there are ambiguities, the vendors are not in a position to understand the exact scope of work. It is quite common to have phrases like the ones mentioned below in customer specifications:

a. “Performance of the system should be acceptable to users.” Which users? Which part of the system?

b. “System should be completely configurable without any coding.” Which parts should be configurable? Higher level of configurability means more coding. This increases the cost substantially. Is this acceptable?

c. “All reports should be generated within 15 seconds”. This is simply impossible for large, monthly, batch-processing based reports. This is not explicitly mentioned as an exception. This can be a problem during user acceptance.

d. “System should perform well under stress”. What stress? How many concurrent users? What type of users? How much data? 1 year / 5 years? What type of hardware? Is clustering assumed?

e. “System should be implemented within 3 months.” Fully functional systems can never get implemented unless there is infrastructure and user buy in. Both these are beyond the control of the vendor. Yet the vendor is supposed to accept this.

f. “Minor changes if any must be implemented as a part of the project” What is a minor change? Who decides whether the change is minor or major? What if there is a clash? Who is the final authority? Will vendor be paid extra for major changes? If yes, when?

g. “Warranty for 1 year”. What does this include? Only bugs are expected to be a part of the warranty. But often users ask for more changes and customers want vendors to implement these at no extra cost during the warranty period.

4. Vendors do not have access to user departments. This is understandable. If there are multiple vendors, users can not be expected to explain the specs and solve various problems. In effect, vendors are expected to quote in spite of ambiguities. This is a risk. This risk can be mitigated only by adding a buffer to the fixed cost. This way, the customers also end up paying more.

5. Customers tend to get everything done within the fixed cost proposal. Reducing the base cost is one win for them. Further wins are aimed at by making the vendor do work which is definitely out of scope. As the vendor is worried about the acceptance of the base project and the recovery of money, they end up doing many ad-hoc things.

6. End-users are generally completely ignorant about the actual process of software development. They do not devote adequate time and attention towards the development process. Response time of users to resolve queries or to accept design, etc also is crucial for timely execution of a project. If end-users want to have a hands-off (‘this is not my work’) type of approach, the project is destined to fail from the beginning.

There are many more problems. But let us now talk about how to solve these.

Root causes

The root cause is actually very simple and fundamental—there is no clear indication of how the end-users are going to really benefit from this new software. Further, there is often no link between the work done for this project and overall organisational goals.

As the base premise itself is weak, everything around it becomes ad-hoc and unstructured.

The process with which many software outsourcing assignments go through is illustrated below.

Of course the fuzziness in the process depends upon the maturity of processes followed by the customer as well as the vendor. However, in order to show the lacunae, I have tried to exaggerate the impact slightly.

Guidelines

In the next article, we will explore some guidelines and best practices in detail. These are guidelines based upon my perception. There may be more guidelines and best practices available from various sources. These guidelines are based upon practices I have followed myself as well as experiences from other customers with whom I have worked closely.

About the Author:Dr Nitin Paranjape is the Chairman and MD of Maestros (Mediline). He is a consultant with many organisations, covering appropriate technology utilisation, business application of relevant technology, application architecture and audit as well as knowledge transfer. He has authored more than 650 articles on various technology-related subjects. He can be contacted at nitin@mediline.co.in