When Outsourcing Makes Sense
November 06, 2016
Disclaimer: This article is based on my personal experience of software project development work over a 25 year period running a mixture of local projects, outsourced projects and hybrid models. The data is my own and subjective, but supported by 1,000’s of industry peers I question while delivering training courses for the PMI. I do not work for a local based or outsourcing based company, I have nothing to gain from favoring either approach, but I hope these thoughts are useful for determining some of the pro’s, con’s, true costs and circumstances when outsourcing is better or worse than local development.
To the uninitiated, outsourcing seems like a great idea. Software engineers are expensive in many countries but much cheaper in other parts of the world. So, since software requirements and completed software can be shipped free of charge via email and web sites, why not get it developed where labor rates are much lower?
Coding vs Collaboration Costs
The flaw in this plan comes in the execution of it when it becomes apparent that software development projects typically entail more than just the development of software. Writing code is certainly part of it, but understanding the problem, agreeing on a design, discovering and solving unforeseen issues, making smart decisions and compromises to optimize value and schedule are big parts of it too. This is the collaboration effort part of a project. Also, while the coding part might represent 30-50% of the overall project costs, these shrink to 20-30% when a 3-year ownership cost view is considered that includes support, maintenance and enhancements.
Sticking with just development costs for now, let’s examine a scenario. The business case pitched to executives by outsourcing companies initially seems very compelling: Project Alpha needs 9 months of software development by a team of 5 people. If you work in an expensive labor market, like North America, we can assume fully-loaded hourly rates of $100 per hour, yet highly qualified consultants from our fictional outsourcing country of TechLand cost only $25 per hour. So, the project for 9 months x 160 hours per month x 5 people at $100 per hour in an expensive market costs $720,000. For a TechLand team this would cost 9mths x 160hrs x 5pl x $25hr = $180,000, that’s a cool $540,00 saving, right?
Let’s revisit this scenario based on the acknowledgment that the actual software writing part of a project is closer to a 30-50% of the total effort. This leaves the remaining 50-70% of the work as the communications heavy collaboration part. It should come as no surprise that separating people via distance, time zones, and potentially language and cultural barriers increase communications effort and propagates issues up the cost-of-change-curve.
So, when 50-70% of the communication-heavy collaboration work takes longer, how do we quantify that? Agile methods recommend Face-to-Face communications because it is the quickest, conveys body-language and provides an opportunity for immediate Q&A only for the issues that need it. Switching from Face-to-Face to video, conference call, email or paper create barriers and adds significant time and opportunity for confusion. A 2-3 X increase in effort likely downplays the true impact when considering the costs of fixing things that go awry because of inevitable misunderstandings, but let’s use that number.
Redoing our project Alpha costs with, say, 40% as the actual coding effort and 60% effort communications heavy collaboration work that takes 2.5 X as much effort we get: 9mths x 160hrs x 5pl x $25 hr x 40% = $72K Coding + 9mths x 160hrs x 5pl x $25 hr x 60% x 2.5 = $270K Collaboration giving $342,000 in total. However, this is less than half the costs of the $720,000 locally developed project so we are still good, right?
The Compounding Costs of Delay
An error in the logic applied so far is that this 2.5 X communication and collaboration penalty on 60% of the work can somehow be magically absorbed into the same 9 month timeline. In reality these outsourced projects take longer because of the increased communication and collaboration effort and 2.5 x 60% = 1.5 X as long is consistent with my experience from 25 years of mixed local and outsourced projects.
The calculations above do factor in longer for communications, but not for development. Unfortunately, work is coupled with dependences, developers have to wait for the requirements that take longer, testers have to wait for developers. So in reality, a closer estimate is that the whole project team burns budget for the increased duration. This means our 9 month $342,000 outsourced project actually becomes a 1.5 x $342,000 = $513,000 project. This is still a reduction over $720,000 local costs, but we have now also delayed our ROI.
Organizations do not undertake projects just to recoup their initial expenditure on them. They are looking for a good rate of return on their money and anything that delays the project impacts the return on investment. If project Alpha was to return $1M in benefits, over 9 months the Internal Rate of Return (IRR) and Net Present Value (NPR) over 9 x 1.5 = 13.5 months now look significantly less appealing.
Combine this with the potential for loss of market share for new products plus lost opportunity costs and you soon realize why companies like Google and Apple pay top dollar for local development. They simply could not afford the true costs of getting projects done slower even if the initial outlay seemed less. (Despite, ironically, developing lots of the technology used by outsourcing companies to make remote development easier.)
When Outsourcing Makes Sense
Using examples like Google and Apple who are known for their innovation is a good segue to talk about when outsourcing makes sense and I have had good experiences with it. New projects, new products and anything with design, uncertainty and risk are heavily penalized by the communication and collaboration costs of outsourcing.
On the other hand, rewrites, conversions and ports of software have less uncertainty, scope for design or discussion and the economics of outsourcing swing in their favour. When you have a machine executable specification – another system to reproduce in a new technology or port to a new platform, suddenly lots of the inefficient collaboration and communication work goes away.
The projects that I have seen do well with outsourcing are these rewrites and ports. Design constraints, non-functional requirements and high-level system goals can be transferred along with the existing system to port or re-implement. From then on, the opportunity for confusion still manages to exist, but it is greatly reduced compared to trying to develop a new custom application.
Another instance when outsourcing makes sense is when portions of the work can be done with less collaboration and communication. For instance, load testing a web site, foreign language conversion, or testing to a well-defined industry standard. These parts of a project can be packaged up, sent off, monitored and the results then integrated into the final project.
There will still be the need for some communication and collaboration, but these more self-contained tasks suffer less from the communications penalty and so the outsourcing savings can be worth while. Of course engaging third parties to undertake some of the project work adds a layer of complexity and additional dependencies. So it should only be undertaken if the savings warrant the extra work and risks.
Hybrid Models
Life is complicated and we usually have to work with what we are given. We cannot always build the perfect co-located team or outsource to the perfect specialists. In these cases, hybrid models come into play and a combination of team models can be used. Understanding the characteristics of the project help stack the deck in our favor for success.
When Complexity is high and the opportunity for discovering issues and technical limitations is high we should anticipate the need for adaptation. In these circumstances having the development team, architects and QA local will greatly speed the diagnosis, alternatives testing, and adaptation required to overcome complexity and uncertainty.
Likewise, when the technical complexity is low, but the need for Communications, collaboration or consensus building is high we might get away with remote development, but should have business analysts and the PM local. This is because when there is debate on what to build, how it should look, or operate we need the business analysts and the PM to help gather requirements and discuss the implications of changes. These combinations and recommended solutions are shown below:
Summary
Hopefully, by taking an honest look at some real-world pro’s of cheaper raw development costs and the con’s of increased communication and collaboration time, we can make smarter decisions around when and where to use it. Also, when faced with inheriting a structure with some ability to influence it, we can mitigate the risks and exploit the favourable characteristics through hybrid models and proactive steps to address execution and communication risks.
These have been my findings from completed projects after the dust settles and the final costs and issues can be counted. I would love to hear from others that have been through the process and can look back on completed projects and reflect on their experiences.
(Note: I first published this article on ProjectManagement.com, if you are a member you can view it and the comments here)
Comments