I am possibly going to have to outsource some work, the good news is that I will have a lot of authority over what I do (so no silly red tape) but the bad news is that I have no experience.
I am not asking for suggested locations to find people that I can outsource to but for suggestions on how to make the best use of them and tips to help avoid possible pitfalls that I may encounter.
I am interested in Web Design/Development outsourcing so tips specific to that are especially welcome.
Thanks.
As long as you understand that outsourcing is a zero-sum game, you'll be fine. There are language, cultural, and time-zone related issues that hinder smooth communication of you are outsourcing overseas. Because of this, you will likely get larger quantities of lower quality code than hiring locally. Also, the code will be written by nearly anonymous individuals in another location, so you won't have the benefit of local employees with expert knowledge.
That said, the more specific you are with requirements and top-level design, the more likely you are to get something useful and maintainable through out-sourcing.
Actually, it would help if you could make questions more specific (man, this topic is really large) - here are some scoping suggestions:
You get the idea...
Consider using an existing system that tracks performance of "bidders". Elance (et al) will let you see the profile, testimonials, etc of people so you can make your choice very easily... But that comes at the sacrifice of having to use their system.
Your other option is blind project posting. Just shove it up on craigslist (or your local varient) and see what the responses are. Be sure to create a separate email for the one job because you'll want to stem the flow of emails eventually.
Make sure you ask for CVs/resumes and past experience.
As far as executing the outsourcing, you'll want a fixed quote. They guarantee you get something for a set price. Open estimates might mean you end up paying way too much.
In order to get an accurate quote, you might need to separate the project up into blocks.
Don't pay too much up front. Lots of freelancers will need a deposit but you don't want to chuck more than £400 down on a project up front and only if you have confirmed details for the dev - much less if you're outsourcing internationally. You might want to consider using paypal for their payment protection too.
I can't give you any advice from experience on making outsourcing work, because I've never seen it work. It doesn't matter if the "out" means Shanghai, Mumbai, or Cleveland, the outsource team is not part of your team and won't act like it. They will deliver something that is almost but not completely unlike what you spec'ed, and you'll have to send it back pointing out what they did, but did completely wrong, and what parts of the spec they ignored. And then you'll discover that you left stuff out of the spec because your local team would have walked down the hall to clarify but the outsource team won't have either the ability or inclination to do so, and so you'll have to update the spec, and then you get into who pays for the extra work that entails.
So good luck to you. I hope your experience is better than mine.
I have posted a Buyer's guide to development outsourcing on my blog.
Executive summary: 24 tips for dealing with freelance workers, including
We outsourced a major portion of our project and it didn't turn our too well. Partly our fault for not having as rigorous specifications and we should have. It was a web app, and both backend and frontend were poorly coded and untested. Some of the poor coding was due to us not having specified completely, though the ammount of breakage was unexcusable. They were fast, but the ammount of tuning we would have had to do would offset any of the time gain so we ended the contract.
In conclusion, provide rigorous specs and see if you can get some testimonials from past clients. YMMV.
Here are my $0.02 from the other side of the wall (I do outsourcing from Romania for a US company and before that for a Dutch one):
Contrary to what some people say you can find good people to outsource, but given the distance and communication problems sometimes it's a difficult thing to do. You must be sure you've chosen the right programmers before starting an important project.
I see good communication as the biggest bottleneck. You need to be very clear when you send specifications, you need to convey all the information about the project to the team and also all the feedback from the client.
If possible it would help to see your outsourcing team face to face. In my experience that helped a lot with communication.
At my first job a few years ago, we outsourced the development of a component of a voip softphone to a developer in Turkey. About $8000.00 and 3 months later we realised that things weren't going to work out. Some lessons:
Get references upfront,and use companies/individuals with solid experience even if it is more expensive. We chose a guy we met on the dev forums of the application. A week later, another company approached us and we declined based on price and that we had already found our developer. Bad move: the company we rejected was a key developer of this voip softphone.
Know exactly what you want. I cannot stress this more. All your requirements need to be detailed as if you're explaining religion, gravity and TCP/IP to a six year old kid. Take your time, use pictures and define as much as possible upfront. Don't use the entire UML 2.0 standard but make sure you leave no room for ambiguous requirements. Use cases and high level sequence diagrams come in handy. We didn't use them... :(
Know exactly how you are going to define and measure the deliverables. How are you going to test the output? When and how do you want feedback during development. Set times and dates...even approximations. If you have been given a budget you need to show the peeps from financial and your boss your projections for expenditure. While this was a relatively small project, I've been on subsequent projects in excess of $100 000 where things like this takes place as a mere formality that no one pays attention to until its too late.
Do not pay upfront. Enough said. Oh my word... enthusiasm from the developer is inversely proportional to the amount of money you've given him.
Know exactly what you want... again...revise your requirements...
Put it all onto paper...and then makes sure everyone involved signs it.
Don't take shortcuts. IF you have a commercial process, take it seriously. If you need certain groups to approve it then get it done properly. You always want to have the peace of mind that you've done everything as best you can.
Problems will happen. You may have difficulty contacting the developer, things will go wrong during testing, your boss may stop funding... list all the things that can go wrong and make sure everyone involved understands the associated impact. Too many times I've heard the nattering of project team members doing a post mortem saying "if I'd have known about it I would have done x or y or z..."
Whew...hope that helps for what its worth :D
Listing down some points I learned. Most of them sound very generic but definitely worth looking at them from outsourcing perspective. I fully support outsourcing but it should not be taken for granted. There is a lot of responsibility in understanding and managing such a team.
For reading, The Pitfalls of Outsourcing Programmers Another excellent article from MSDN..
"Next, I am going to give some examples from my own experiences. Please do not take these examples as being a generalization of a particular people or culture, but simply as illustrative examples. My examples are based on my work with teams in India and Eastern Europe. The experiences of working in each of these locations were radically different. In India, the general answer was always immediately, "Yes, it can be done," and then the developers would go off to huddle and try to figure out what they thought was being asked for in the solution. In Eastern Europe, every request was responded to with a barrage of questions, and unclear ideas were challenged until everyone had a clear understanding of the desired solution......"
Over past 5 years I have outsourced quite a few projects ( small to medium ).
Here are few points that have made me wiser. ( all through trial and error.) but now, I swear by each and every one of these...
1) As you will be entering a contract, make sure your requirements are as detailed as possible ( and numbered ). Detailed requirements will get you bids from contractors who are serious about accepting your work. If you are serious about detailed requirements, experienced contractors will recognize it and put time in considering your bid.
2) Agree to a realistic deadline but be VERY firm about deadline in your contract bid. ( extend it later if required, but convey it initially that you are firm about deadline. Lot of tryout contractors will disappear once you mention this. )
3) Schedule and make it mandatory to get delivery of code in milestones of 1 to 2 weeks each ( max 2 weeks, not more ). This will help you a lot in figuring out if the contractor can deliver on time with quality or not, and allow you to use the exit clause to cancel the project and recover your funds. Make this point very clear in your contract : If more then 1 or 2 milestones are delayed or not upto required quality, you have right to cancel and recover you money in full. This really keeps the contractor honest.
4) Use a tool or search engine ( like http://www.copyscape.com/ ) to help you figure out if the code or document being provided is copied from one or more sources. This saved me in 2 projects in a year, and I was able to request cancellation of both projects as I was able to provide proof. It is common for contractors to think they will get away with plagiarism.
5) Request a sample of actual work (for projects over $500. ) I have found contractors who are willing to give actual samples of your projects are best bets. Serious contractors will give small sample without hesitation. The best contractor I came across, provide a short actual working sample along with a reasonable bid. I accepted his bid without negotiating and was 100% x 10 times happy with his work. I gave him a bonus without asking and was happy to give repeated contracts after that.
6) For complicated or time sensitive projects ask the contractor to put a small % of project amount into escrow ( say 20% of what you would pay him/her ). This is essential for projects which are important to you. Without this the contractor is free to abandon your project midway( as it happened to me more then once ), and your schedule will be in mess.
7) Though I have found couple of good contractors with the lowest bids, but usually it is a waste of time to select the bottom bids. Contractors with Mid range bids are lot better.
8) Skip the bids of any contractor who does not take time to provide tailored reply to your project bid. All contractors who provide canned replies are waste of time.
9) Make sure the contractor can comfortably communicate ( written as well as verbal) with you in the language you are comfortable in. I had to abandon a project due language problems. Specially if you are giving a long term or medium+ project, talk to the contractor over phone/voice chat before accepting the bid.
10) In the contract, make sure to add a support period after delivery of the full project ( few weeks or month based on size of project.) Keep part of payment ( say 10% ), to be paid after the support period is over.
Hope this helps.
I worked both as part of an outsource team as well as at onsite to deal with offshore team. From my experience this is not an easy stuff to manage unless you are so lucky to get a team, who expose very high skills. The best strategy for a newbie would be to check the team with a very small dummy project for at least 2 weeks. You can check the following things from them remotely
And of course so many other typical team qualities you can check while this period , so with this small project you can very well measure them and decide whether they are good enough to take a big Spec and do the work, or you need to modularize the spec even smaller pieces and need a constant communication with them or not. Anyway managing offshore team is going to be a big task. But if you are able to get a neat team up there, you can very well expand your dreams/ideas, because you got a dedicated cheap labor team waiting.
From bitter experience:
Ensure that the contract states that the people doing the outsourcing will work hours that fit in with your time zones.
Otherwise, code sent Monday their time is only tested Tuesday your time and any bugs will only be fixed Wednesday their time. If you are lucky, you'll get two shots per week!
If possible, expose a server for them to install the latest code themselves (otherwise more time wasted with code that doesn't even install).
Get them to write some unit tests and provide a log with each release that proves all tests have run and passed. (Regression issues are a real killer).