This blog I wrote to share some of my insights on Distributed Software Development (Offshore, Nearshore, Rightshore, GRIDSHORE, whatevershore).
I will not go into cultural differences, intellectual differences, communication issues (human and technical), time and distance issues, etc.
Lets simplify it by stating that it adds WASTE to the Development Process but we don`t know how much as it depends on the situation, location experience, people involved, and so on.
WASTE is an important concept to understand as it is by far the biggest influence factor in reducing time-to-market and cost reduction. Lean Software Development is a translation of lean manufacturing principles and practices to the software development domain and focusses on removing WASTE. Adapted from the Toyota Production System, a pro-lean subculture is emerging from within the Agile community. Everything not adding value to the Customer is considered to be waste. This includes:
unnecessary code and functionality
delay in the software development process
slow internal communication
The term Lean Software Development originated in a book by the same name, written by Mary Poppendieck and Tom Poppendieck.
I hear you saying, what about Productivity? Productivity in economics refers to measures of output from production processes, per unit of input. Labor productivity, for example, is typically measured as a ratio of output per labor-hour, an input. Its known that there can be an enormous difference in productivity between one developer and the other. Also the development language and tools they use can make a difference. Again, I will not go into the discussion if Cobol, RPG, C##, Java, Ruby is more productive than the other, neither I will state in this article my opinion on architectures like SOA.
What is important to grasp is that Productivity depends on the team size. Adding people to a team does not have a lineair posive effect on the duration (it has sometimes a negative effect) and it has certainly not a positive effect on Productivity as the input (labor hours) increases and the waste (waiting time) too.
Brooks has written about it in his book the Mythical Man Month. Everyone knows the famous example “one women can get a baby in 9 months, 9 women can not get a baby in one month“. But why are planners still not taking this into consideration. In short “If one bricklayer can do a wall in 100 days and two can do it in 50 days the productivity remains the same (nothing said about the cost as salary can differ) but its unlikely that 10 bricklayers can do it in 10 days“. The SLIM tool of QSM used by a lot of companies can show nicely this effect. I did a lot of estimations, planning and collecting data in the past working for the big consulting firms and just to illustrate the effect I have included a screenshot of my spreadsheet tool.
If you take a project of 1000 Function Points, then the optimum in duration and effort would be around a duration of 10,2 month with 6 FTE resulting in 8531 hours. The same project (1000 FP) but now done in 9 Months (what is 1,2 month you would say) will take 11,8 FTE on average and cost 14586 hours which is almost double the hours. One remedy would be splitting the project into two projects but the architecture should allow this. If you where able to split the project in a project of say 400 FP and 600 FP then you would see that with 400 FP it will take 2,9 FTE, 5,7 months and 1852 hours. The project of 600 FP will take 7,6 month with 4,5 FTE and cost 4769 hours. With some parallel development (if possible) we can meet the deadline of 9 Months and it will cost around the same as before.
Estimation of work is not equal to planning. A certain task say writing a use case, analyze a use case, design, code, test, deploy can be estimated (although not easy as re-use of existing classes comes into play). Planning although is arranging the tasks in the right order taking into consideration the dependencies on resources and other tasks. Planning of tasks takes most of the times place in the form of batches (writing requirements, analyze requirements, design, etc.) which is a form of WASTE.
So what has this to do with the REAL Cost of Offshoring? The message I want everyone to understand is that introducing WASTE but not adjusting the duration will have a dramatical negative effect on the Productivity. And not understanding this up-front will cost only more as the natural reaction when not meeting deadlines is to add more people to the project. I also noticed in the past that the local (expensive) resources are longer needed on the project too making the business case for going Offshore completely worthless.
Is there a way to overcome this? Yes, one way is to eliminate WASTE as much as possible by bringing more work Offshore (Analysis, Design, Test) and bring the local knowledge also Offshore (communication will improve a lot by doing this). But even more important, be aware of WASTE, try to eliminate it and adjust the planning (longer duration or decrease functionality) and release more often and in shorter cycles (agile).
3 thoughts on “The REAL Cost of Offshoring”
Pingback:Offshore development… and software defects « Michael Ayvazyan on the Network
Pingback:Gridshore » Defects, Lean Software Development, Offshore, oh my …
Nice post, brings back a lot of memories :-). I’d love to see more posts about this topic with details so others can learn from it as well.
Comments are closed.