Outsourcing/Offshoring is seen by many to be a panacea for improving the bottom line. But for a great many of us, offshoring a development project is a great way to be like the big boys, and build something you would otherwise not be able to afford to do locally.
Outsourcing though can be tricky to pull off. The person you rely on is sitting a world away, reading your notes and emails in a language that more than likely is not their first. Language is difficult, because more often than not our daily correspondance can be littered with euphamisms, inferances, and lingo that could be flying over the heads of its intended recipients.
Also, as I have discussed previously, there will most certainly be cultural differences at play here as well. Certainly you as the project champion must understand or at least be sensitive to not only cultural issues, but also time zones involved as well. I knew someone who was constantly frustrated his outsource team didn’t communicate with him often during the business day, despite being 12 hours behind his team.
So you decide that you need to outsource certain aspects of your development, where do you start? Where do you look? Well before you hit the pavement, you need to start with defining what it is you want the team to do.
First off, start with the basics. What is the project/development stream about? What are your overall goals? Once complete, read it again. Ask yourself, would Joe in Marketing understand this? If the answer is yes, then re-write it again. Remove any and all catch-phrases like “value proposition”, “market penetration”, and “leverage”. No seriously, take them out of the document alltogether. Imagine you are writing this for a teenager. Its not to say all offshore developers do not understand these types of terms, but the simple fact is some developer might not understand it at all, or even worse get the wrong understanding alltogether.
Once you’ve described your project, your next goal should be to detail each and every feature in plain English. Here is where another common pitfall occurs, someone will write a requirement that says:
The homepage should have a facility for a user to create an account.
But then, the writer will “assume” the developer know to create a function to actually log-in to said account. Assume? Please don’t do that. Assume nothing.
Now, if you have a particularly complex requirement, I can’t recommend enough the power of simple use-cases. A use case is a line by line description of how a user/performer will interact with specific features in your site/application. A great description cited on Wikipedia by Bittner and Spence says:
Use cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful
You can write use cases about anything. If you’ve just written a requirement, and are not sure you got the point across or are not sure it will be understood, then write a use case. Don’t get fancy, just be as plain as plain can be.
- User logs into the system
- System presents a page with the following data:
- Personal details about the user
- Name
- Address
- Products user has purchased
- Product 1
- Product 2
- User selects an option to purchase a product
- System generates a page with a list of products
- User selects the “buy” option next to Product 3
- System generates a checkout page with the following data……
You get the idea. Now, as basic as the above is, it does give a decent explanation of a potential user flow through the system. Don’t worry about following the classic description of Use Cases either, you can use it to detail the type of options available on a particular page, or describe the types of activities users will utilize across the site. Either way you slice it is up to you, use them wherever you think clarification is needed.
Now, once you’ve written your post and selected a provider, I offer one last bit of advice. Always, always make time in your proposal or project plan for a design phase. Even if your development is simple, a developer will always need time to carefully review your requirements, ask questions, and ascertain the best way of achieving this. You may think this is money down the drain, but it is the most crucial step in any development. If your concerned your developer will just sit back and relax, build in checkpoints or deliverables that turn the tables on them: ask them to describe in their own words each requirement. Get them talking, get them describing what it is they will build. You will be quite surprised that in many cases the circle you are describing is being thought of as a square. If this happens, don’t shoot the messenger. Just go back to your documentation and re-write your description and feed the update back to the developer.
Also, regardless of how busy you are, make yourself available to your team. Give them your Instant Messenger details and encourage open communication, regardless of time of day. Email is great, but a lot of developers will struggle with their English and labor over simple questions for too long (again, this is a gross generalization). IM, in my opinion, is far more informal and can be a boon for quick clarifications and questions.
Lastly, once you get your team started, you’d like to think the hard work is over? Well, think again. Now is the time you need to get close to your team, and make sure they are working to plan, and are clear about everything that is expected of them. Basecamp from 37 Signals is an excellent tool to keep in touch with your team from the project/devlierable level. Best of all, its free.
This post will either encourage you to give outsourcing a try, or it will send you running in the opposite direction. Its understandable, outsourcing is an incredible way to ramp up your team and build something for far less than it would be possible if the team was local to you. However, keep in mind that successful projects do not always rely on the team you pick, or the development being attempted, success relies mostly on you.
