Knowledge is power. We love to share it.

News related to Mono products, services and latest developments in our community.

denis

Software outsourcing – good or bad

12/10/2011

As a producer of software applications, components and related services, we have been in a unique position to learn about software development outsourcing process, both as a service provider and a support service for outside outsourcing teams that use our products. It has (and still is) a fascinating experience. We see the common set of patterns reappearing in most of the projects, and we thought that it might be a good idea to share our thoughts about the whole process. There are no earth-shattering insights here, but still, our experiences might come handy once you start to think about outsourcing – and given the current trends in the industry, chances are you will.

The “o-word” itself continues to be highly unpopular with American and European workers, evoking images of corporate downsizing, mass layoffs and mediocre service from foreigners with heavy accents. However, we all outsource certain tasks, even as individuals: hiring someone to file your taxes or to fix you car – these are classic examples of outsourcing. The situation is rather similar when we shift to the business context – hiring someone to do the job which would otherwise be too expensive, difficult to do or time-consuming is quite often a very good idea. You cannot have a full-time employee for each task necessary to run a business, can’t you? It seems that the sentiment begins to change only when a particular outsourcing strategy involves foreign workers – a new term, offshoring, has been coined to differentiate this case from a “standard”, domestic outsourcing. When political and public reasons are put aside, we can all agree that it is just a tool that can be used efficiently.  The world has become a small place, and there is no purpose in running away from something that is being done at every corner.

There is a long list of issues for organizations that outsource could address: focus on core business, cost restructuring, quality improvement, increased knowledge pool, etc. However, the first and foremost advantage of outsourcing almost all of us are trying to achieve is simple: cost benefits. It is a perfectly legitimate goal, but as all things in life, can quickly lead you nowhere when taken to extreme. This is where most of the first-timers do their first, and quite often, the fatal mistake. There are many people with some money and an idea, searching for software developers that could transform that idea into reality. They routinely turn to various freelancer / talent market / outsourcing sites: oDesk, Elance, Guru, you name it. Even before they post their project, they spot hundreds of other projects, with budgets set as low as $250 or somewhere in that neighborhood. Most of these projects do require a month or two worth of work of an averagely skilled developer – and very often, much more. So who will spend so much time, being paid so little? Actually, no one. An average monthly salary for a decent developer in some of the international outsourcing centers may be lower than $1000, but as the price goes down, so does the quality of work. Here is a comment from an Indian developer I stumbled upon recently: it neatly summarizes the situation. Realistically, you can get high quality people for as low as 50% of the price you would pay for their US or EU counterparts, but this will still require a good deal of research, experience and a bit of luck. I would still argue that freelancing sites are not the best places to find them, at least while we’re talking about software development, apart from very simple projects.

Note that things will not look too bad at the beginning. Almost every project will receive dozens of bids. Hundreds of thousands of freelancers, teams and individuals, are bidding very aggressively, trying to win as many projects as they possibly can in a very competitive market. Sure enough, some of them are capable to implement the stuff they are bidding for. However, most of them are not. They start to worry about the details once they win the project. Most commonly, they will do some preliminary work, just to see how far can they go. However, as soon as the money starts to run out, all sorts of weird things start to happen and projects never get finished. This situation often leads to a vicious cycle, where another provider is hired to  pick up the ball and finish the project, just to realize that the existing code and documentation is worthless. The project is than restarted several times, and the frustration grows. We recently had a client who has been down this road for at least five times, trying to implement a rather advanced application with a lot of social networking functionality: “I have employed many developers, some are ranked as high as #50 of 400,000 on my favorite freelance site and even they have not been able to complete stage 1 of my project.” – he said on our initial meeting. Sure enough, the quality of the code delivered by his previous teams was unbelievably bad, resulting in Web pages with multiple headers and buttons and links that do not work for the most of the time. As it turns out, high rankings on freelancer sites are not the measure of the quality of a development team. With the high staff turnover rates in such teams (mainly due to low salaries), even the reference list does not mean much – developers that built the applications on that list may be long gone. And while we are at it, many teams have teams of different quality – the “A” team starts the project, but soon enough it is moved to “B” team with significantly lower productivity and quality of the final product.

Even more importantly, you have to take the cultural differences into account. Dave Rodenbaugh recently published his article “The Real Reason Outsourcing Continues To Fail”, in which he argues that Power Distance Index (PDI) is an important factor that has to be taken into account when hiring the outsourcing team from a high PDI culture. This may sound controversial (some would say even racist), but the experience teaches us that the “yes sir” approach is rarely adequate for software development projects.

The responsibility for the project’s failure is almost always shared between the buyer and the provider. Too many buyers set unrealistic goals for the project triangle of software development: scope, schedule and resources.  If a development team fails at renegotiating the situation as described above, it is forced to try to deliver under those constraints anyway.  In the end, if the project team delivers at all, the quality of the delivered product suffers and the project is almost always late and over budget.

Additionally, buyers have very different ideas on how the process for specifying the work to be done should work. Some believe in detailed specifications with hundreds of pages coupled with the old-style waterfall development methodology in which things tend to be over-specified up front and changes (that will inevitably come as both sides learn more and hear the feedback from each other and the users) are discouraged. Everything is subsequently thrown into the hands of a development team, without too much interaction (“everything is specified in the documentation”), but with great expectations. This can be bad – but it is even worse when you are expected to build a complex system based on a three-page Word document and a few Excel sheets with a couple of mock-ups. We have seen our share of people who work in such quasi-agile environments: the “agility” is here just an excuse for not specifying the minimal requirement set, defining the prices and the deadlines early on, and leaving the development team with an ever-expanding set of features.

Don’t get me wrong – outsourcing can work wonders, especially if you minimize the risks by doing the following:

- do your research. Find the team with the proven expertise, check their references, track their blogs and support forums and talk with their customers. Don’t rely on “talent market” sites for anything beyond the simplest projects.

- sign the agreement that clearly defines the scope of the work and the responsibilities of both sides.

- do not pay significant amounts of money up front. Too many development teams ask for 30% or even more in advance. It is much better to clearly define the project milestones and pay after each of them has been reached and you get your deliverables. However, be prepared to pay for non-development work as well: for example, requirements gathering is a critical and time-consuming step – if you don’t have a decent specifications doc, you will have to pay somebody to build it for you.

- be realistic. You may not like what your outsourcing team tells you regarding the project scope, schedule, or features, but an honest and informed opinion is much better than blessed ignorance. Remember the PDI story from above!

- embrace the agile methodology. It helps with building trust and understanding early on. Insist on early delivery of working modules, frequent iterations, testing, and all other principles of agile software development. This way, mistakes will not derail a project, just marginally delay it.

Having experiences with software outsourcing/offshoring, good or bad? We would love to hear them!

Rated 5.00, 3 vote(s).