Avoiding remote software collaboration disasters
4 key questions for your early warning system
About 6 months ago I commissioned two small pieces of remote software development. My motivation was getting the best value for money in the technology areas of Microsoft .Net and Flash animation. One was a success and the other a disaster - I think I now know why!
I selected my chosen suppliers via the web - one was an Indian software staffing agency I found via google and the other was a small US-based supplier selected via elance.com. Both jobs were in the $1000 price range.
The Indian supplier turned out to be a disaster - they exceeded my budget by 70%, my timeframe by 100%, used up large amounts of my personal time in communications and I still had to get all the code totally rewritten by another developer which effectively tripled my costs.
The US supplier did an excellent job - after a number of good prototypes which I was able to refine and comment on they delivered a high quality product on time and to budget.
When I look back at this experience at a surface level it would be easy for me to say "just avoid Indians and use Americans for software" - but I am sure this is not correct and is missing the point altogether.
So when I got over my irritation and started to look at things a bit more logically with the benefit of hindsight, I realised that there were 4 simple questions I missed in my selection process which would have saved me from my bad collaboration experience:
1. How good are the supplier's language skills?
My poor supplier would not talk to me via VoiP - we had endless 1-hour sessions on yahoo messenger where I essentially had to restate every line in the specification in two or three different ways.
LEARNING: If your remote supplier does not speak English as their first language then you must satisfy yourself that they will be able to clarify and understand the complex nuances of your instructions.
It does not matter how good they are technically if they don't really 'get' what you want them to do.
2. Is the supplier committed to results or charging by the hour?
My poor supplier was at pains to point out there would be no fixed prices - everything would be billed by the amount of hours used. They claimed that they 'nearly always complete the work within estimate'. I foolishly agreed.
LEARNING: Don't put yourself in the position where all the risk is on you. Remember the story of the chicken and the pig in collaborating to produce your cooked breakfast - the pig is committed (bacon) but the chicken is just involved (an egg).
3. Have the supplier staff specific independently verifiable reputation?
Like many others, my poor supplier offered me 'organisational credibility' and excellent staff CVs - essentially generic credentials.
My good supplier offered me (via elance.com) 'ebay-like' independent ratings from their previous jobs - specific reputational information.
LEARNING: Avoid selecting partners based on generic organisational credentials - try to get specific independent reputation information for the individual supplier staff who will be working with you. This also gives you power to comment publicly at the end of the project - all my dissatisfaction with my poor supplier just went into a private black hole!
4. Does the supplier have a professional process for what they do?
My poor supplier only did exactly what I asked for.
Their view was if I wanted my code unit tested then I should have asked for it!
LEARNING: You cannot get a professional product if your collaborator does not have a professional process. Ask them about their process and what checks they do before they deliver anything to you. Poor process also seems to go with 'charging by the hour mentality' mentioned abover.
So what made the difference between the good collaboration and the bad one - 4 simple things :
- good language skills
- shared commitment to results
- verifiable and updateable staff reputation
- following a professional process
Bioteams Books Reviews
We are bombarded with the idea its good to talk and its good to text. But is texting and other forms of mobile phone interaction a useful form of communication? Or is it even a form of communication at all or something totally different? In a mini-book "Heidegger, Habermas and the mobile phone" the author invokes some key thinkers of the twentieth century to offer an essential alternative to the new doctrine of 'm-communication': Martin Heidegger, who saw humanity as ‘the entity which talks’ and Jürgen Habermas, current-day advocate of authentic communication.