|
Comments
I agree, outsourcing is a petrifying experiance for a small business. Most people I know in this field are contractors and to be honest most seem pretty conscious of the hours they're putting in and getting the job done. For us, if we've not worked with the person before or are unaware of their abilities we make sure they work in-house, at least for the first project. Other than that project management tools can be used to document progress, highlight issues and anything else that should be monitored. Posted by: DannyT at June 20, 2006 05:23 PMI too have had bad experiences like this (and unfortunately have been the cause of a few others - woops), but I think it's just how the software industry in general is. It's not a tangible thing, so estimating hours is very difficult. I used to work in a production house who did tv commercials as well as develop high-tech websites. They could estimate almost exactly how long filming, editing, etc would take because it was a set process that has remained constant for over 10 years. Websites/internet apps are completely different. Technologies change so quickly and people struggle to keep up with the "latest thing". People move around to different jobs/techologies/etc often and most likely don't become experts in any particular field. (except maybe reading blogs) And I guess some people bite off more than they can chew. Sorry about the rant.. Posted by: Adam at June 20, 2006 08:59 PMI've been working as an independant developer for over 10 years, and have both been sub-contracted, as well as used sub-contractors. What I have learned when using someone new is to first give them some small, with a deadline that if missed, you can go to "plan B" and either do it yourself or sub to someone you trust. I try to grow the relationship slowly, so I can learn the sub-contractor's strengths and weaknesses. Based on your post, if I was expecting to see something in 2 weeks, but the contractor had nothing for me to see after 3, I would have cut them loose. Also, I don't mind if someone I hire is struggling with something I've tasked them to do, as long as they are up front about it, and ask for some help or guidance. If they wait until a delivery date to tell you there is a problem.. the real problem is the contractor! Gus Posted by: Gus at June 20, 2006 09:17 PMThanks Danny and Adam for your input, much appreciated. I agree Gus, it was just a matter of too much trust. I saw the signs but just kept giving chances. Not a mistake I will ever make again. It wasn't a matter of waiting until delivery date, he continuously said he didn't have something but was "working hard on it". I now realize how full of crap he really was.. Such is life I guess, "fool me once, shame on you, fool me twice... " Posted by: Graeme at June 20, 2006 09:29 PMHi, I do not want to protect the sub-contracter you hired, as a good communication policy is vital in a deadline baseed business world, but as was mentiioned by Adam, the internet and its technologies are a rapidly changing thing and it is sometimes very hard to acurately estimate the time needed for something unless it is just a copy of what has been done already. As a contracter, I think that going with a small start project is a really good idea. Allow a relationship to grow from your side as well as from the sub's side. Communicate frequently and openly and things should work out for the best for both sides. Just my 2 cents worth. cheers, Julian Posted by: Julian at June 20, 2006 09:39 PMRead all the comments, and didn't see one reference to -- checking references! Not a magical solution, but hey, ask for AND check references. If none are available, then warning bells go off. If they don't pan out, well, then it's easy to move to the next. It's hard to imagine that this person had delivered well for all other clients except you. Would a reference check have turned this up? Posted by: Mike at June 20, 2006 10:31 PMThanks Julian, yes I agree with that but I'm a contractor too and always keep to my agreements with clients and if time goes by and something still isn't quite done they are always informed in a timely manner with a proper update on how much longer I expect to be. So even though I agree that sometimes it's very hard to figure out how long something will take, I find that would be more of an excuse than a reason. I like your ideas of building up the relationship, but I truly felt that wasn't necessary in this case, I was wrong though... Mike, yes, references. But this was such a small item, theoretically it should have been done quite quickly but wasn't. Good idea though, I'll definitely be checking on the next person. Thanks all for your input. :) Posted by: Graeme at June 21, 2006 02:24 AMI recently hired three external consultants for a project. My experience from that is: insist on seeing code. With designers, it's easy. You either like their visual style or you don't. With programmers it's a bit different, but sort of the same. If you code yourself, you'll have a strong opinion on how you would solve things yourself, so insist on a code sample, preferably of a medium to large application. If the person can deliver that and the solution is not too far away from how you would have done it yourself, it's a good indication the person is a good coder. Allow the person a little time to clean up the code. That just makes it easier for you to verify it. If the code is poor, it's really hard to hide it and nothing one can fix in a short amount of time. Make sure to check if the code is well documented. That's always a solid plus and an indication that you'll be able to maintain the code once the contractor is done with his/her part. One of the three I ended up hiring was a designer that had started doing code some years ago. He didn't really have the requisites, but he's code was solid (though not excellent and class-based). I told him that I'd hire him if he worked hard on his skills and he has absolutely done so! He actually learned all the basic OOP skills in about one week :) So my advice is meet the person directly, check the code, look for error handling, documentation and readability in addition to how it solves the task at hand. Posted by: Jensa at June 21, 2006 04:46 AMAgree with Jensa. Ask for code but not daily. Personally i like working when i feel like to. I always count this personal preference on project time so everything goes fine. I don't know but i always end up working at midnight. For example, last night i woke up at 4am and started working LOL Ask for code or progress every 2 days. Ask the outsourced to keep a project file. This works for us pretty well. We are 5 ppl in house but we work with other 3 remotely. Posted by: Fernando at June 21, 2006 09:49 AM |