Thursday, November 15th, 2007 by Rob
As a self-employed web developer I’ve had numerous experiences over the years outsourcing work to other providers. This is the option I turn to when a relatively “simple” clearly defined project comes in that I’m either too busy to take on myself, or I don’t want to be distracted from a larger, more complex project. I have also hired a number of single outsource developers to work as a “team member” where we both work on the same project together and tackle things in a much more fluid way. Like most experiences, sometimes it’s worked, and other times it hasn’t, also some of the providers have been great, some have been simply awful. This post is about what I have learned from experience.
1. Communication
The number one most important tip I can offer is that you must have a good line of communication with the provider. If you are outsourcing a single project, make sure that it is as fully spec’d as possible, with clearly defined goals and timescales. Also, make sure the provider agrees to the spec and that they fully understand what is entailed. If you are working on a more fluid, lengthier project you must stay in touch with the provider as much as possible. Obviously if you are working in different time zones I’m not suggesting that you should switch to using their clock, but the provider needs to know when you will be on line, how they can contact you if there is a problem/question etc. Instant messaging, email, Skype and wikis are all valid means of communication, each with a specific job, and I strongly suggest that you use as many of these lines of communication as you feel comfortable with, or that the project entails.
- Instant Messaging
This is the number one tool for day to day communication. You should always have your Instant messenger fired up and online so if there the provider needs to ask a quick question, they can easily get in touch
- E-mail
If a question is too complex for a quick IM, email should be used to outline the problem and also record the decided solution. Email should definitely be used to make statements about the project, timescales, methodology and anything else that needs to have a record kept.
- Skype (VOIP)
Sometimes confusion can arise within IM and email. This is especially true if your provider is from another country and does not necessarily speak the same language, or understand the same cultural nuances as you. I can remember with one provider once insulting him over IM because he wasn’t as indoctrinated with the British sarcastic sense of humour as I am. If this is the case, sometimes actually speaking, so the tone of voice can be heard, goes a long way to facilitate communication.
- Wikis
I find I’m using wikis more and more when dealing with outsourcing. I find they are invaluable when spec’ing out projects, detailing any changes and also documenting coding guidelines, stating reasons for why the code is as it is. Wikis are also a handy place for the provider to find any links to staging severs, get access to SVN etc. In return the provider can outline the structure of their code and explain why they have done things in a certain way etc.
2. Clearly Defined Expected Outcome
This relates heavily to point 1, but it is absolutely imperative that you have a clearly stated outcome you are working towards, including expected timescales or date of completion. I have found if there aren’t clearly defined expected outcomes, regardless of whether it is a single project, or a “team member” type scenario, the provider doesn’t have anything to aim at. If there is no outcome to aim for none of the functionality will ever get properly written. And, if there is no timescale agreed, there is no urgency to get anything done!
3. Clearly Defined Methodology
As well as having good communication with clearly defined expected outcomes I have found it is imperative to have a clearly defined methodology. This may be as simple as “please email me at the end of the day with a progress report” or be as complex as instructing the provider to always use your online collaboration suite and submitting to the Version Control System for the nightly build. Which methodology you choose to use really depends on how mission critical your project is. Whatever methodology you do use, it is important to define this from day one, as it is very easy to get into a habit, but impossibly hard to break one.
4. Have Good Tools
This is linking in a little bit with point 3. It’s necessary to have good tools with which to implement your chosen methodology. It is also important (critical in fact) that your provider knows how to utilise the tools. One (very irritating) time I noticed that a provider I had just hired promised that he knew all about Subversion, but was downloading, file by file, the entire code base from the browser, and not with an SVN client like TortoiseSVN. Needless to say, he didn’t last long.
These tools should include, in my opinion, at a minimum a version control system and bug tracking software. I am a big fan of Trac but I don’t know if that is just me coming from an Open Source mentality. Also, as I think it is brilliant, I recommend Mantis as a bug tracker if you don’t want to get as complicated as Trac or BugZilla. Damn, that means I also must mention FogBugz, but enough – on to point 5.
5. Treat your Provider with Respect
This isn’t just about being polite, which of course is an absolute must, but is really about trusting your provider to be able to actually work on your project without you having to hold their hand and check up on them every 5 minutes. Yes you should always be there if they need help or have a question, after all they aren’t as up-to-speed on your project as you are in the beginning. However, trusting your provider and treating them with a little programming respect will not be as hard if you heed point 6.
6. Find the right provider for the job
One of my first mistakes when outsourcing work was to just hire the first provider that came along and said they could do the job. Every provider I have since found out says they can do the job, but it really depends how well you want the job done. The more providers I used, the more I realised that getting a provider is really like finding someone to employ. You want to get the right person for the job. Also, a big mistake I made was thinking that a bigger price equals a better provider; this is not always the case. So when you are looking for a provider, ask to look at some example work and some of the code that makes it work. Maybe even give them a little test. You want to make sure you get the right provider after all…
7. Don’t forget, it’s your money
This might seem a stupid point, obviously it’s your money (it may be your client’s money eventually, but you will still have to pay for it first). As it is your money, if you feel unhappy, or are not confident the provider can do what they said they can do, or complete the project, don’t waste your money and your time. There are a hell of a lot of providers out there, you can find someone you are confident with and who can complete the project. When I first started using outsourcers I was often too nice, I helped them out and was very communicative, all good. However, with some of them I realised I was doing more explaining and helping out than the provider was coding. I had to keep on referring them to the coding standards I wanted them to adhere to, or the function spec I had written for them. After a while I twigged that this was costing me money. If the provider cannot do what you are asking, find someone who can. Nevertheless, saying that, if you find a provider that keeps getting it right, doing what you are asking and in the timeframes you’ve requested – hang on to them, they will help your business invaluably!
Posted in Development | No Comments »
) article by a guy called Marcus Whitney: 
