Reiser - Getting the Most out of Offshore Development

By Greg Reiser 11 February 2009

Many businesses avoid using offshore resources to implement high-value, high complexity software projects and many who try are frequently dissatisfied. In a recent survey Forrester Consulting found that nearly half (46%) of businesses were unhappy with their offshore provider for development of mission-critical applications.

This begs the question, “Is offshore development incompatible with high-value high-complexity projects?”

My experience suggests otherwise. I have worked with many talented teams that have successfully delivered high-value high-complexity solutions using a distributed development model that takes advantage of talent located in multiple locations around the world.

In this article I will briefly describe how specific practices, some associated with agile development, will help you get maximum value out of your distributed development efforts.

(Please note that I prefer to use the term “distributed development” instead of “offshore development”. This describes projects where work occurs in multiple locations. It is my experience that there are no “offshore” projects. Rather, there are distributed projects where a good bit of the work is performed offshore.)

Involve the whole team in the planning – This is counter-intuitive to those organizations that rely on up-front analysis and planning and then engage a development team (possibly a vendor) for the implementation work. This presents two problems.

First, the development team will insist on doing its own analysis in order to fully understand the business requirements document, use cases, RFP, etc. Hence, some of your up-front effort will be redundant.

Second, and more importantly, it’s during the up-front analysis and planning that the business sponsors and subject-matter-experts establish a shared understanding of the project vision, business objectives and priorities. If the development team (or vendor) is not involved in this process they will be less effective in adapting when the inevitable surprises occur.

Sorry folks, documentation just doesn’t cut it. To paraphrase General Dwight D. Eisenhower, “The plan is nothing, but planning is everything.”

Monitor the product, not the process – Many agilists criticize earned value analysis (“EVA”). Although the EVA technique has shortcomings, the basic idea of assessing project progress by the value delivered is sound. It is much better to assess progress based on functionality delivered rather than interim deliverables such as the System Design Specification (“SDS”) or worse, budget or schedule consumed.

Whether the project team is distributed or not, in-flight metrics based on implemented functionality and user feedback are significantly more reliable barometers than traditional “percent complete” metrics. How many projects have you seen that are 90% complete for half their actual schedule?

Although the SDS may be a very important and valuable artifact (I’m not one of those people who demonize all documentation), its veracity is suspect until an implementation validates it.

Admit that you have a (communication) problem – It doesn’t matter if your project methodology is agile, waterfall or something else. Communication and efficiency suffer when team members are separated by miles. It gets worse when they are separated by time zones as well. In addition to the obvious investments in communications infrastructure and practices (high-quality speakerphones, high-bandwidth networks, overlapping workday schedules, etc.), consider some not so obvious practices.

One of my favorites is the “exchange program”. Have people from each work location spend time working (not just visiting) in the other work location. I’m talking about at least two weeks at a time, working side by side with peers in the other geography. This is both an effective knowledge-sharing and team-building technique.

Don’t give in to the argument that “money saved on travel can be more effectively applied to real work”. The improvements in efficiency far outweigh the additional travel costs. On one large complex program we experienced a 200% increase in throughput after we implemented an exchange program.

I don’t necessarily advocate expensive video-conferencing equipment and services. Although it is a blessing to have access to such, the cost-benefit is not as favorable as it is for less technically sexy investments.

The bottom line is that your project plan must address the communication challenges inherent in distribution. If the necessary investments exceed the benefits of doing the project in a distributed way then don’t do it that way.

Redundant roles – A typical pattern for distributed projects is to have the project manager, subject-matter-experts (“SME”) and business analysts at the customer site and the developers and testers at an offshore facility. This works quite well for small, short-term projects, but it is sub-optimal for large, complex programs.

Concentration of expertise and/or decision-making in one location slows the project down, as the development team often has to wait a full day (best case) when certain types of impediments arise.

Having business analysts and/or SMEs close to the developers and testers improves throughput as questions are answered much more quickly. Having project managers in each location improves throughput as many decisions can be made much more quickly. Having developers at the client site improves throughput as critical defects can be resolved immediately and integration challenges can be addressed in a timely manner.

From a lean perspective, redundant roles are actually a best practice because the apparent waste in redundant roles is significantly less than the waste generated by the wait times in the more typical staffing model.

Monitor technical integrity – “Technical debt” is a metaphor developed by Ward Cunningham that describes the long-term terms costs associated with “quick and dirty” development. The “interest” on this debt is realized in the form of increasing development costs due to inflexible and/or overly complex design, excess dependencies, duplication, defects, etc.

Technical debt management is important for any project. Distributed development makes technical debt management more difficult because some, if not most of the code is developed by the offshore part of the team. Hence there is a greater risk that by the time the symptoms of too much technical debt become obvious, the cost to correct will be high.

You might replace your offshore team due to poor performance and you might even recover some of your costs. But if this really is a mission-critical project, your business will still suffer. Although you can and should apply manual techniques for monitoring the technical integrity of the software under construction, I have found that the use of automated tools to monitor indicators such as automated test coverage, adherence to coding standards, design quality and design complexity can serve as early warning signals for technical debt growth.

Using these types of tools within an automated build process that sounds an alarm when metrics fall outside specified thresholds accomplishes two things. One, they trigger investigation and potential remediation when it is still possible to do so at low cost. Two, they automatically encourage design discipline. No one wants to be singled out for violating coding standards, for not following the agreed upon testing discipline, or writing unnecessarily complex code.

Once again, a modest investment can reduce risk and saves significant costs within a relatively short period of time.

These are but a few techniques, some obvious and some not so obvious, that help make it possible to execute high-value high-complexity projects and programs via a distributed model. Look for future articles for more practical learnings from the trenches.

---

About Greg Reiser: Greg is a software development professional with 20+ years of experience as a developer, project manager and a consultant. He has experience in a wide range of industries including banking, insurance, publishing, logistics, healthcare and telecommunications. Greg has helped numerous enterprises deliver mission-critical solutions using advanced software development practices. He is currently focused on helping organizations get the most out of global development capabilities.