Hey. I've been managing IT projects for more than 5 years and here I'll share my experience in picking and managing remote contractors. I'll focus on developers, but some parts can be applied to other types of services too.
How To Choose Contractors
It can be challenging to know for sure if the person/team are really capable of delivering, but there are ways to minimize risk.
1. Always prefer those who you have already worked with and who has delivered similar projects. Easy, right?
If you are here, I'll suppose that's not an option.
2. Ask the people you know for a reference that satisfies the criteria above. If that doesn't work out, read further.
3. At this point your only option (that I know of) is to go public with your task. If you can, it is always better to start working with a new contractor on a small project first. Just to see if they deliver at all and if you are a fit. Keep in mind, that sometimes it can be not wise to split up a big project, because your contractor plans the workload ahead and the good ones are busy. So when you decide to proceed with the bigger part, you might have to wait. You've got to find the sweet spot between these extremes that works specifically for your situation.
4. If the task description is appealing enough, you'll get proposals. Pay close attention to their contents. Usually it's best to entirely skips all of them that seem generic, copy/pasted ones. I always go with those who try to point out potential bottlenecks, pitfalls, etc in the task I described and those who ask good questions. What questions are good? The ones answers to which will alter the project's scope, time and cost. And if that's a software dev. or a web design project, very good questions will be those that point out the ways to improve your users' UX. That means your potential contractor cares not only about your project, but also thinks ahead about how your customers will use it, what trouble they might have along the way. This is unique per project, proves they care, invested some time into it and didn't copy-paste the proposal, so I'd pick them. Besides, more expensive doesn't always mean better.
Starting The Project
Before commencing the execution I prefer to agree upon particular communication schedule.
Remember, to get the project done faster your contractor needs to do less, not more. (That's one reason why micromanagement is counter productive).
But until you get to know each other it might be useful to agree upon daily progress updates. It's ok if the contractor needs a couple days to get up to speed, but if a week later they are not fast enough, that's an issue to be discussed and resolved.
Good and experienced contractors know that to go fast you need to build trust. And to build trust you need timely, transparent and consistent communication. So it won't be a problem for them.
Once you get to know each other and feel comfortable, you can decrease the communication's frequency to 3 times per week, or twice a week.
It's also important to setup acceptance criteria beforehand.
Things To Watch For During The Project
If they ask no questions during an extended period of the execution, that's a red flag. Ask them yourself: where they are now, what can they show so far, what questions do they have.
Usually things come up along the way, even if you know each other and the specifications for the project appear to be clear.
On your regular calls measure the progress towards the criteria you've got, compare that progress to your schedule. Are you falling behind? If so, why? While you figure this out, don't try to offend your freelancers, don't try to make them guilty. (Both might lead to them falling into the state of procrastination). Just ask clarifying questions without assuming your contractors mean good or bad. But if you do find out they slack off consistently, grab what results you've got, pay as you agreed and replace them.
Quality Assurance / Acceptance Phase
Usually developers test what they've built using a happy path strategy. It's pretty much standard, unless otherwise agreed.
So you've got to manage QA for all the possible edge cases, or perform it yourself.
Either way, you've got to build a checklist against which the tests are performed. It can be small initially, but without it some things will avoid your attention (but your customers will surely stumble upon them). It's always better to find bugs and errors before your clients do! Checklist helps. Make sure it at least has all the steps essential for the minimal customer's path (from a visitor to your target action, be it a purchase, a confirmed registration, and so on).
You can try to ask your developer to do that, but that's not the best approach in my opinion. If one person implements a function it's unfair for them to test it, since they literally know inside out how it works. If they didn't think of something during development, chances are they won't think of it during the test. You need someone from the outside if you want a fair, clean experiment.
Deployment is another issue. Depending on your agreement with the developer, they either will or won't deploy your project to your production environment. But you've got to have that environment anyway. Take care of that until it's too late or you'll lose time. Make sure you've got backups. Make sure those backups work (try to restore from one of them, verify the result).
On a related issue — you can use sticks and stones to build your product's first version and then rebuild it with better tools and bigger budget. That's a usual practice in IT, nothing wrong with it. So when you start, you don't need to care about load balancing, load testing against 100k views per second, etc. Just make sure it works in production as well as it has been in the dev. env. (your checklist will become handy here again).
Support
Congrats! You've released your first version. Analytic (both quantitative and qualitative) are crucial at this stage, but that's out of scope for this post.
Make sure your contractor agrees to support the project via a retainer contract or on-demand. If they don't, ask if they know someone who can. Keep that contact. This way you'll help future you to have options when it comes to developing something again.
P. S. AMA, I guess. I'll try to answer related questions, you can also describe your current struggles regarding managing remote teams and I'll share my perspective on that.
How To Choose Contractors
It can be challenging to know for sure if the person/team are really capable of delivering, but there are ways to minimize risk.
1. Always prefer those who you have already worked with and who has delivered similar projects. Easy, right?
If you are here, I'll suppose that's not an option.2. Ask the people you know for a reference that satisfies the criteria above. If that doesn't work out, read further.
3. At this point your only option (that I know of) is to go public with your task. If you can, it is always better to start working with a new contractor on a small project first. Just to see if they deliver at all and if you are a fit. Keep in mind, that sometimes it can be not wise to split up a big project, because your contractor plans the workload ahead and the good ones are busy. So when you decide to proceed with the bigger part, you might have to wait. You've got to find the sweet spot between these extremes that works specifically for your situation.
4. If the task description is appealing enough, you'll get proposals. Pay close attention to their contents. Usually it's best to entirely skips all of them that seem generic, copy/pasted ones. I always go with those who try to point out potential bottlenecks, pitfalls, etc in the task I described and those who ask good questions. What questions are good? The ones answers to which will alter the project's scope, time and cost. And if that's a software dev. or a web design project, very good questions will be those that point out the ways to improve your users' UX. That means your potential contractor cares not only about your project, but also thinks ahead about how your customers will use it, what trouble they might have along the way. This is unique per project, proves they care, invested some time into it and didn't copy-paste the proposal, so I'd pick them. Besides, more expensive doesn't always mean better.
Starting The Project
Before commencing the execution I prefer to agree upon particular communication schedule.
Remember, to get the project done faster your contractor needs to do less, not more. (That's one reason why micromanagement is counter productive).
But until you get to know each other it might be useful to agree upon daily progress updates. It's ok if the contractor needs a couple days to get up to speed, but if a week later they are not fast enough, that's an issue to be discussed and resolved.
Good and experienced contractors know that to go fast you need to build trust. And to build trust you need timely, transparent and consistent communication. So it won't be a problem for them.
Once you get to know each other and feel comfortable, you can decrease the communication's frequency to 3 times per week, or twice a week.
It's also important to setup acceptance criteria beforehand.
Things To Watch For During The Project
If they ask no questions during an extended period of the execution, that's a red flag. Ask them yourself: where they are now, what can they show so far, what questions do they have.
Usually things come up along the way, even if you know each other and the specifications for the project appear to be clear.
On your regular calls measure the progress towards the criteria you've got, compare that progress to your schedule. Are you falling behind? If so, why? While you figure this out, don't try to offend your freelancers, don't try to make them guilty. (Both might lead to them falling into the state of procrastination). Just ask clarifying questions without assuming your contractors mean good or bad. But if you do find out they slack off consistently, grab what results you've got, pay as you agreed and replace them.
Quality Assurance / Acceptance Phase
Usually developers test what they've built using a happy path strategy. It's pretty much standard, unless otherwise agreed.
So you've got to manage QA for all the possible edge cases, or perform it yourself.
Either way, you've got to build a checklist against which the tests are performed. It can be small initially, but without it some things will avoid your attention (but your customers will surely stumble upon them). It's always better to find bugs and errors before your clients do! Checklist helps. Make sure it at least has all the steps essential for the minimal customer's path (from a visitor to your target action, be it a purchase, a confirmed registration, and so on).
You can try to ask your developer to do that, but that's not the best approach in my opinion. If one person implements a function it's unfair for them to test it, since they literally know inside out how it works. If they didn't think of something during development, chances are they won't think of it during the test. You need someone from the outside if you want a fair, clean experiment.
Deployment is another issue. Depending on your agreement with the developer, they either will or won't deploy your project to your production environment. But you've got to have that environment anyway. Take care of that until it's too late or you'll lose time. Make sure you've got backups. Make sure those backups work (try to restore from one of them, verify the result).
On a related issue — you can use sticks and stones to build your product's first version and then rebuild it with better tools and bigger budget. That's a usual practice in IT, nothing wrong with it. So when you start, you don't need to care about load balancing, load testing against 100k views per second, etc. Just make sure it works in production as well as it has been in the dev. env. (your checklist will become handy here again).
Support
Congrats! You've released your first version. Analytic (both quantitative and qualitative) are crucial at this stage, but that's out of scope for this post.
Make sure your contractor agrees to support the project via a retainer contract or on-demand. If they don't, ask if they know someone who can. Keep that contact. This way you'll help future you to have options when it comes to developing something again.
P. S. AMA, I guess. I'll try to answer related questions, you can also describe your current struggles regarding managing remote teams and I'll share my perspective on that.
Dislike ads? Remove them and support the forum:
Subscribe to Fastlane Insiders.
