Making offshore outsourcing of software development projects can be made to work. It’s not easy, and here’s a list off issues that you must address if you want it to be successful.
Create a testing framework (on top of the existing JUnit framework), complete with utility classes, that the offshore team can use to create consistent test cases. Common types of utilities include those that read files (such as input XML documents from the developer’s local hard drive), write files, parse XML documents, ummarshal and marshal XML documents to and from object graphs (the kind of thing you might want to do to verify that, say, the result of a business process is as expected), etc.
Your testing framework should have at least one base class from which all JUnit test cases derive, so that the developer doesn’t have to worry with the details of using JUnit (such as setting up a TestSuite, inheriting from TestCase – not terribly difficult stuff – and junk like that). The less the developer has to know about JUnit, the less likely they are to deviate from the way you want them to write test cases. Believe it.
Plus, having a test framework, including base classes from which all JUnit tests derive, will reduce human error, ensure consistency among test cases, and make it easier for your offshore development partners to follow any applicable standards your organization may have, as well as reducing the amount of time spent wrestling with JUnit itself, and increase the amount of time writing code to test the business logic.
This is a very important one. Make sure to document – completely – everything you want done. Include the requirements (so you can track back once the implementation is complete), documentation (if modifying an existing system), expected deliverables, and the criteria for success (you would think this is obvious, but you would be wrong). Let’s look briefly at each of these.
Clear, concise communication begins with documentation. Of course, there will be meetings of various types, but without good documentation (and by “good” I mean of the kind that includes the stuff in the previous paragraph) you’re sunk. Believe it.
One important thing to document are your development patterns. Do you use a framework? Document how to use it, and include it in a “User’s Guide” that your offshore team can follow. Is there a particular daily build process that must be strictly adhered to? Document it. Special plug-ins and wizards developed in-house that the offshore team can use to develop the code? Document them.
Templates, Templates, Templates
Templates provide a nice, high level gut check of whether or not your company’s standards are being followed. Plus, templates fit in nicely with quality improvement initiatives such as Capability Maturity Model (CMM) and Six-Sigma.
What templates you’ll need really depends on what deliverables your offshore partners are providing to you. Here are a few examples I’ve found helpful:
1. Schema review – in the world of web services, messages are in XML format (wrapped in SOAP, wrapped in a mystery, wrapped in an enigma, yeah, I get it). Those messages (my company uses the Financial Industry standard – Interactive Financial Exchange, or IFX) are constrained by a schema (or they should be, and if you don’t see the value in that, well, get outta my blog). The schema review template should include the name and email address of the offshort resource who wrote the schema, the name of the onshore reviewer. Also included should be a list of the standards your company has with respect to schemas, and a place to indicate whether or not the particular schema up for review follows those (a place to put a check mark should be fine).
2. Design review – also to make sure applicable standards are being followed.
3. Code review – ibid.
This is perhaps the most important area, and certainly aided by the previous three. Without constant, effective communication, your project is sunk. Believe it. What is “effective communication?” I think of it as getting your point across, communicating your ideas and expectations, and (this is important) making sure that your communication is received and understood. I’ve worked with many, ahem, spoken language-challenged offshore resources (who speak very grammatically correct English *way* too fast, making it difficult to understand them, more on that in a future blog) who politely nod along with what’s being said. Later I found out that they either (a) didn’t understand a word I said, but as their “customer” they felt it would be insulting to obtain proper clarification, or (b) understood what I said, but not what I meant. So, what’s a well-meaning architect/project manager to do? Get them to repeat back to you what it is you *think* you said. If they can do that, then you know (and they know) that all is understood. And send a follow up email outlining what was said, and what was agreed to (and what, if any, items were dropped from scope, tabled for later, require more clarification, etc.). And do this for EVERY MEETING YOU HAVE. Is that a lot of work? You bet! But you want to make this work, right? Look, management are the only ones convinced that this is actually cheaper than doing it in-house. And from a pure financial analysis standpoint, it is. But, there’s no free lunch! Let me repeat that: there’s no free lunch. So, there must be a trade-off, right? Yep, and there it is: somebody onshore is going to have to work harder (and smarter) to make it successful.
Any thoughts? I’d like to hear from you.