Top 7 Tips for Successfully Outsourcing Development

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!

Note: This post has been copied from the old ibrow.com website, originally posted on 2007-11-15 . See this entry for more details

Installing Subversion on CPanel/WHM

Just a quick tip for those who (like me) have wanted to install the Subversion client on their CPanel/WHM VPS. (I have my repositories hosted with SVNRepository.com so no need for a Subversion server to be set up). I have a couple of VPS servers set up and wanted to install subversion on both. After a bit of Googling I worked out that by simply logging into the command prompt as root and installing Subversion via YUM

# yum install subversion

It should install fine, and on the first of my VPSs (CENTOS Enterprise 4.6 x86_64) it did. Great!

However, on the second VPS, it came up with the error:

Error: Missing Dependency: perl(URI) >= 1.17 is needed by package subversion

This VPS is running CENTOS Enterprise 4.6 i68. Initially I tried to install Perl URI via YUM, using the command yum perl-URI, but it reported that there was nothing to do, so I tried to clean the cache (yum clean all) and try again, but still no luck. The solution was to find a suitable RPM, download and install manually. After a bit of searching, I found a list of RPMS, one of which was suitable for my distro. I installed the RPM, everything went well, so had another go at installing subversion and all worked fine. These are the steps I followed:

# wget ftp://ftp.wavelink.com.tw/pub/Cent4464/CentOS/RPMS/perl-URI-1.30-4.noarch.rpm
# rpm -i perl-URI-1.30-4.noarch.rpm
# yum install subversion

To test I tried

# svn --version
svn, version 1.1.4 (r13838)
compiled Aug 21 2005, 20:56:55
.... etc .....

Which means it’s working!

Hope this helps someone out there.

Note: This post has been copied from the old ibrow.com website, originally posted on 2008-03-27. See this entry for more details

Updating ibrow.com, moving old blog entries

We are currently in the process of updating the ibrow.com website. We should have done this months ago, but we’ve been a bit rushed out (as ever). During this tidy-up I’ll be moving some of the old blog posts from ibrow that I wrote over to my blog (which you’re looking at right now).

Stay tuned for some “retro” posts.