You decide to outsource your software development to some far away exotic country. Why use some local cocky programmer that costs a fortune and only gives you an attitude when you instruct him something simple to do? "Go Far, Go Cheap" seems like a good alternative. But, what if you are not the very trusty kind of person? How can you make sure that after forking over 100.000 Euro you will get your stuff?

Photography by Joe Nangle.

Well, by not paying 100.000 euro, but only 100 euro at a time.

Even if you don't use people that are at the other side of the globe, when people you don't know are not within eye sight, it can do strange things with a Project Manager's mind. There is a solution to all this. Not a solution to avoid problems, but more or less a solution to reduce the impact of when things go bad. And let's be honest, that is the only reason why your head is spinning.

It is done all the time in projects, but mostly on a larger scale. I have performed this technique on my larger projects. However, I really took it a step further when I started to manage some smaller projects using freelancers I found on the Internet on sites like Rentacoder.com and eLance.com.

Split your project into smaller meaningful products.

Nothing new or rocket science about this one, but the trick is to really define small products that can be assigned to different people (or teams). Don't ask for "a website". Ask for "a design (mock up presentation), "website articles on topic X" , "A customization of CMS x conform this design" . You don't have to assign every product to a different team. But, the essential step is to order the creation of one single item at the time.

Assign a microbudget with each product.

Only release a defined (fixed) portion of your total budget upon completion of each product. If people want something upfront, just create smaller products and use even smaller budgets. Most of the time they will accept this. Only release funds after completion.

Make sure the end result is something that can be validated.

This puts some burden on your part, but define each product, each statement of work if you will, in such a way that both parties know when it is finished. And in such a way that both parties can validate in the end if the work was done as performed.

Make sure the end result can be handed over.

I am not talking about large documentation. But make sure you get source codes, make sure there is a least some rudiment form of explanation. If things are not going as you have hoped for, you can at least switch to different parties (although some additional effort will be associated with that).

This approach is not unique. This approach is not new. But it is perfectly suited for long tail projects where a flexible workforce is used, one that is scattered all over the globe. It means you can go incremental in your product development, you can prioritize every next step, and you can pull the plug earlier because you only get finished products.