So you find that you have too much work to do, or maybe you're lacking in expertise on some facet of your project, and you need to subcontract part of it out. What steps do you need to take?
- Find a good subcontractor. This can be tough. If you don't know the subcontractor personally (like when you use an outsourcing firm), how can you know that the quality of work will match all the shiny buzzwords on their resume? On the other hand, if you contract out to a friend, you run the risk of spoiling your friendship should the project go sour. Nevertheless, the few times I've subbed out I have used one or more friends whose abilities I knew from long experience of working together. That way I knew exactly what I could expect from them, so it was easy to...
- Define expectations. Even if they're your friend, having a written contract is not a bad idea -- if for no other reason than that it makes you put down in writing most of what is expected from the relationship other than specific project milestones (usually): how much they will be paid, when they will be paid, contingencies for payment (do they have to wait for the end user to pay first?), hourly vs. per job, availability, expected contact with the end user (if any), warranties (if any), reasons for termination, and any other terms of the engagement. Besides having a contract, you'll also want to clearly specify as much as you can about the scope of the project and the subcontractor's expected role therein. Whether you want them to take the reins and be creative, or just follow instructions and churn out some code -- there will be fewer misunderstandings and more good feelings if your preferences are known up front rather than discovered along the way.
- Coordinate their efforts. One reason why I don't really like to subcontract if I can help it is that I rarely enjoy being a project manager, and that's exactly what you become when you don't do all of the work yourself. Communication is the #1 most important part here: not only the ongoing status of the subcontractor's work, but also any changes to expectations from the end user or from yourself. And if the subcontractor runs into a roadblock, make sure they know that they need to tell you right away instead of spinning their wheels trying to hack around the problem so they can conceal their prior ignorance and maintain their image as an expert.
- Don't be afraid to call BS. Even otherwise honest people are sometimes tempted to color reports of their own failings in a less than accurate tone. If the reason you hired them was because they know more than you do about the work, then you're even more susceptible to being unwittingly fitted with woolen eyewear. Apply the sniff test liberally, and challenge anything you doubt. Once they know that you will, they'll be more careful about the truthfulness of their communications so they don't have to endure the embarrassment of back-pedaling.
- Do a post-mortem. In any endeavor, the greatest long-term value comes from learning from your mistakes -- yet we often want to forget about those and move on instead. Take the time to sit down with your subcontractor and review what happened. Make two columns, "what rocked" and "what sucked" (or invent your own labels), then go through each aspect of the project and write things down under each heading. Afterwards, ask "if we had to do the whole thing over again, what would we do differently?" The subcontractor's answers will reveal a lot about whether you want to use them again in the future, because their ability to learn and improve far outweighs any prior knowledge they may bring to a project.
Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant blog, he also contributes to [Geeks Are Sexy] Technology News and his two personal blogs, Chip's Quips and Chip's Tips for Developers.