So I blew up, over gTalk, with nothing but frustration and emotion, as it seemed that planning, daily chats, and excessive help was just not getting it done. But the truth is, one which I knew prior to my compulsion of taps across my keyboard, acting out won't get anything done in India as well, because threats are meaningless to someone 3 thousand miles away, who can pickup another job that day from one of the ten's of thousand's of people in my position looking for LAMP developers to jump into projects, learn the strategy overnight, execute the plan as if you were in the office, and save us tons of money at the same time.
The truth is, when you put a lot of US-India Outsourcing expectations on paper, they add up to impossible. The same way that time, cost, and features are the standard triangle metaphor for product development in corporations around the world; location, social context, and project plans (LSP) dictate the success of using developers offshore.
More Costs Below The Surface
I have been doing dual-shore software development for several years now and I am still occasionally getting burned by completing projects late, over budget, and under expectations, as "getting it done" has usually required feature cuts. My suspicions have always pointed to the fact that I am not adequately calculating "real", unknown, factors into my project planning and as a result, projects have been susceptible to coin-flip outcomes, where these LSP "unknowns" take a "real" value, and project success comes down to the individual developer, and not the project plan.
In layman's terms, offshore developers are:
- (L) missing the vision (stuff scribbled on the white boards), the gooey glue that holds internal teams together onsite, but fails to extend to many developers jumping into a project
- (S) missing the context of what is "now" in the marketplace
- (P) missing the importance of getting the project done on time, outside of reputation in the market as a software provider.
The real cost shows up near the end of the project. If offshore developers do not see your LSP, they will typically approach coding for you as a task based assignment in which they go down the list and do items one off, typically jumping around to solve easier tasks first, and going back to harder tasks the further into a project they get. The problem with this is the fact that "harder" tasks poses several unknowns in their own right, and when developers approach software from a task based stance, they will almost always need to go back and change queries and classes from tasks designated "completed". When a PM (Me) goes into test, suddenly things that once were working are not, and timelines are being extended because reasonably hard issues turn into larger than life challenges that continue to escalate the further behind a project becomes.
Moreover, this reduces a PM's ability to manage efficiently, as developers now hold the "power of completion" where they expect PM's to understand that difficulty creep is a result of 300' analysis done by the dev team at the point of requirements, and that time creep is inevitable to "solve" the problems defined by the business team. On the surface, this used to seem justified to me and I would go back and sell the business team on timeline extension.
As I investigated this deficiency over several bad projects, I realized it came down to 1 thing.
- I was putting developers in the mode of task monkeys and not engineers because I was not engaging them on a LSP level.
Engaging your outsourcing software developers on a level conscious of LSP will help them to work in the mode of engineers and see the product from a wholistic point of view and will tasks on a list into pieces of a whole. By allowing them to approach a feature as part of an eco-system, they will address harder challenges upfront, because they simply better understand the nature of what they are working with. This will allow them to make more accurate decisions in code implementation.
A Simple Understanding of LSP
I know that many people reading this will write this off as an essay on better explaining the vision of a product to offshore developers, but that is only a small portion of what I am referring to. Rather, LSP is about understanding the REAL costs associated with social/spatial disconnect, I have seen in everyone of my projects using offshore development. More importantly, I am advocating that PM's look at LSP an an investment in the project outcome, where by spending an extra day on LSP, you can save literally 4-5 days in project time.
So the next time you begin a feature with an offshore developer, do your usually process of specs and screenshots, but integrate one day of LSP into your planning process, introducing the following items:
- A thorough walk through of examples (1 hour min) where you explain the a) history of those example, b) the expected future of those examples, and c) the justification of why those features mean something to users.
- Walk-through's that extend beyond the feature you are working on*.
- A small quiz that allows you to assess if they "got it".
- An easy-to-access archive of material related to your own product's evolution.
By investing in the advantages of educating your offshore developers as team members and not task monkeys, you will be able to reduce time delays and cost increase. Also, by performing the 4 tasks mentioned above, you will be able to determine the LSP deviation (an amount of perceived disconnect from the internal group's understanding) and seeing that in any fashion will allow you to better plan cost and timelines in the future, as you will be able to recognize potential difficulties due to social/spatial disconnect.
* example - I am developing user galleries. Rather than spending all of my planning time explaining to the developer how users will interact with photo galleries, I will take them through account creation, take them through usage of other features, and then get into explaining photo galleries.
