In the United States there is an array of responses when you mention the word offshoring.
Offshoring is the process where by less expensive resources are sought out from a different geography. It’s not a new concept. The industry has seen both successes and failures in the implementations of outsourcing. For some it creates solutions, and for others it creates headaches.
There is no one formula for success; however, there are a few key approaches that you can take to improve you odds for a successful implementation of outsourcing.
Expect Nothing
Whenever you hire a developer for a permanent position, hire a contract developer, or hire a consulting firm, expect that they know nothing. I know – you’ve worked hard to select the best possible person or firm and you feel like you should expect excellence from them. Perhaps you will receive excellence from them, however, expecting it is a recipe for disaster where not expecting it means a little more communications – perhaps awkward communications but not a substantial time investment.
There are fundamentals of instructional design and teaching that say that we don’t learn evenly. (For instance, Piaget’s Developmental Theory exposes this through the concept of “equilibrium” where by repeated experiences are easier to learn, and loss of equilibrium where uncommon experiences require changes in cognitive structure to accommodate.) We all have gaps, holes, and craters in our knowledge. While we may be substantially intelligent and experienced there will be something that we don’t know that another practitioner might believe is obvious. We must challenge our beliefs that our teammates are aware of something just because we are.
Consider a CFO at a large multi-national organization. He might be someone who is clearly intelligent and thoughtful. However, he may be equally incapable of performing even the simplest repair such at installing a new keyset in a door. He’s not dumb by any stretch; he might just have a small gap in his knowledge when it comes to some mechanical activities.
When selecting an outsourced partner, look for assurance that the partner knows how to develop software. Look for organizations with a high number of certified developers. Seek out Software Engineering Institute CMM Level 5 organizations. (www.sei.cmu.edu) Check references and perhaps run trial projects.
The problem with this has two parts. The first is that there is little or no independent research indicating a correlation between IT certification and on the job performance. Most of the studies that are used to show correlation have been commissioned by the organizations that are the purveyors of the certifications. Most certifications today rely upon multiple choice standardized testing to certify candidates – this simply isn’t a foolproof indicator of on-the-job performance. The Cisco CCIE exams are rumored to have a pass rate of approximately 2/3rds of the candidates with the lab (read: “Real World”) portion estimated to have 1/3rd of the candidates pass. It’s little wonder that there may be little correlation between certifications and job performance. Someone who is a certified developer may or may not do better than his uncertified peer. I’ll qualify this to my experiences and say I’ve not personally observed a high correlation between job performance and having a certification. I still look for it as an indicator but it can’t be treated as an assurance that the performance will be better.
The CMM certification process stratifies organizations based on their perceived level of software development competency. Organizations at Level 1 are perceived to have a low probability of reliably producing quality software. Level 5, the highest level, is reserved for organizations that are perceived to be operating at an optimal level. However, even organizations that are certified CMM Level 5 may or may not be operating at this level on every project. They may have a core team, perhaps one that makes frameworks for the rest of the organization that has been certified CMM Level 5. However, how do you know if any of the people that you’ll be assigned follow this process or have experience with it?
The second part is that the people you get for a pilot project are likely not the same people that will perform the real project. I’m not suggesting any lack of integrity or slight of hand here. I’m simply stating that resources that tend to get scheduled for pilot projects are not those that are likely to be on long-term projects. The folks assigned to short-term pilot projects move from one pilot project to the next. Since you’re creating an outsource partnership it’s likely that you’ll be looking for folks to work on long-term projects.
However, not knowing whether you have a good developer, an average developer or a poor developer is the same challenge you face as you hire folks locally. Similarly you don’t know if they have experience with web applications, logging, batch queues, or any of the other technologies that you need.
It is your responsibility to ask what experience they have with something, to expose areas you need to train them in before they start coding and your responsibility to promptly (read daily) review their code, and make sure that it’s meeting your objectives.
If you expect that no developers has all of the knowledge that they need and that it’s your responsibility to train them you’ll find that things just work out better.
Communicate Everything
Pickup any book on Agile in any form. Pickup a book on Lean development. Pickup any book at all on traditional software development in the last 20 years and you’re likely to find a major focus on communications as a key ingredient to a successful software development project. Even if the book doesn’t explicitly call out communications as a key ingredient to software development you’ll likely find undertones that lead you to the same conclusion.
In these same books, particularly those that advocate agile development practices, you’ll likely find a discussion on the warmth of the communications options that you have. Face-to-face open dialog on a whiteboard type discussions are perhaps the richest and written languages being the least rich. This means that an hour of time spent in a face-to-face meeting may be several times more effective than writing the same thing down. This is not to suggest that writing isn’t important or required – simply that this is a framework on which direct face-to-face communications should be hung like a skeleton. It isn’t the complete solution.
However, when we seek to communicate with offshore partners we are limited to video meetings at best and written communications at worst. Is it any wonder that communications is a challenge?
Working with an offshored solution requires a substantially greater focus on communications than the communications that would happen between two people in the same room. The sort of random, informal, ad-hoc meetings that happen daily and accidentally when people are co-located in the same room must be replaced with some sort of a communications infrastructure. Without this infrastructure the project is necessarily doomed to fail. Of course, at any time whether in the same room or across the globe people can choose to stop communicating which is the project creating its own demise.
Structure Communication
Creating the infrastructure can vary by organization and by partner but I suggest a minimal set of documents to get you started. First, have a set of approach documents. These documents describe the overall approach for different parts of the system. They are descriptive rather than prescriptive (for the most part). They describe the design patterns that are preferred, allowed, discouraged, and disallowed. They describe the architectural approach that is being used – for instance in bridge building it would specify whether the bridge should be an arch bridge, a suspension bridge, or some other sort of bridge. It wouldn’t necessary explain all of the details; its objective is simply to provide a foundation.
The second deliverable is a program specification. The specification should include what requirements and design feature points that are associated with the program in question as well as a more detailed – but not necessarily explicit – account of what the program should do. If possible it should refer to the test scripts and cases that the program will need to pass.
The one important part of the program specification is the encouragement (or requirement) of questions. You’ll never write a program specification which answers all of the questions that a developer might or should have – if you do you’re spending too much time on them. You have to expect questions. You should encourage them – and document the answers with the program specification. For this reason you should consider sending documents a few days ahead of when you actually want work to begin.
Verify Understanding
So if I didn’t scare you with the understanding that written communications and how it is hopelessly inferior to face-to-face at a whiteboard communications let me warn you off of another impact. One very dangerous thing, particularly when you’re working with those for whom your primary language (mine is English) is a secondary language, is that the person actually understands what you mean. When I first started my career I was working with a company that imported some products from the Far East. One of the very sage words of advice from someone who traveled a lot was to always ask a question where the correct answer was “No.”
When questioned about this, there were several important factors making this an important question to ask. First, asking the question is the necessary step in verifying understanding. It is fundamental in all relationships whether in the same room or across the globe.
The second factor is that when faced with partial understanding most cultures – particularly in business relationships – tend to respond in the affirmative. You want to make the other person happy so you say, “Yes” and not “No.” For most folks saying “No” is more emotionally strenuous than saying “Yes.” By asking a question in the negative you force the person to be sufficiently confident in their understanding that they’re willing to tell you “No.”
I’m not saying that the offshored team members that you’ll be working with won’t understand what you say, nor am I saying that they will intentionally mislead you into believing that they understand something that they don’t.
What I am saying is that there are natural barriers that may exist and it takes extraordinary people to get past them. I know and respect several folks who have gotten past them and I am enriched by their friendship – however, I am simultaneously aware that there are many more relationships that I personally have to work for.
No Free Rides
I have no particular predisposition to believe that people from any country should be granted a free ride when it comes to jobs. Not being a Politian by nature, I believe those that are the smartest- who solve problems best, have the best education and experience-should receive the work.
That being said, there are many developers in America – and I suspect the rest of the world – who are sleeping. They believe that because of where they live how they were brought up, they deserve a job. I disagree. Work hard to be the best developer you can be and you’ll find work. Don’t try to learn, grow, and think and you’ll have trouble no matter where you live.
I don’t advocate outsourcing as a strategy except in very specific circumstances where communications is easy, the problem is well known, and the visibility of the outcome is straightforward to see. That does not mean I have the correct view of the opportunity that outsourced development brings – it means that I am biased towards applying it in the situations where it has demonstrated to me that it works best – not in those ways that have questionable results.
It does make sense in some circumstances – and it’s a valuable business tool. However, go into the experience with your eyes open.
About the Author
Robert Bogue, MCSE (NT4/W2K), MCSA:Security, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He was recently honored to become a Microsoft MVP for Microsoft Commerce Server and before that Microsoft Windows Servers-Networking. Robert blogs at http://www.thorprojects.com/blog. You can reach Robert at Rob.Bogue@thorprojects.com.
