As part of my day job, I have to hire a lot of outside developers and development firms for projects. I’ve made a lot of mistakes along the way, and I’m going to tell you how to avoid them and find the best possible person or firm to tackle your project.

Right off the bat, let’s talk about why this process is fraught with peril.

You probably have a picture in your head that hiring outside developers and managing them will be easier than doing a project in-house. You wrap up the project details, fire it off and forget about it until it gets done.

Easy-peasy, right?

No.

Let’s break down the differences between in-house and outside developers.

When a project is done by an in-house staff, you get a slew of advantages. You can push scope if need be to keep a client happy. You can adjust the workload in other places to throw more people at a project in trouble. The communication is easy — after all, they’re in the same room or building or chat room as you. Status updates are easy; adjustments are easy; compared with outside developers, everything’s easy.

Your scope can be kind of loose because your in-house developers have the authority to fill in the blanks.

Most importantly, your in-house development team has a direct stake in the outcome. It’s your company’s name on the work, and, therefore, the team’s reputation. Caring makes a whole lot of things easy from a management perspective.

Almost everything about working with an outside development firm, on the other hand, is hard.

You don’t have insight into their other projects and workload. You can’t really dictate how many developers they have on a project or when they can come free without awkward drama.

If you’re on an hourly contract (more on that in later segments), goals can be misaligned — after all, if they work more hours, they’ll get paid more. I don’t think anybody does this intentionally, but it’s always an intrinsic motivation creeping in the background.

If you have a loosely defined scope, you’re going to get burned in one of three ways: cost overruns, timeline overruns or, best-case, not getting a perfect product at the end.

That’s because outside developers don’t have the same authority that your in-house developers have. It’s been my experience that they will build exactly what you told them to. No extras. No filled in blanks. If you didn’t tell them it needs to be SEO-friendly, it might not be.

Communication can be an absolute terror. I’ve lived circumstances where you have no idea of project status from day to day or sometimes week to week. I know of a project (not mine) where we saw a) no code, b) no staging link and c) nothing in progress at all until three days before launch.

That’s not going to work … ever.

At the end of the day, you need to realize that managing outside developers is going to take up a lot more of your time than if you had done it in-house. And that’s fine. Sometimes you don’t have the bandwidth. Sometimes, you don’t have the expertise.

Sometimes you have to hire outside developers, and based on my own experiences, I’m going to tell you how to do this right and avoid the sort of headaches I mentioned above.

Last time we talked about why you need to manage outside developers and why it’s so much more difficult than in-house work.

Today, let’s talk about how you find possible vendors.

You start off with a project. Said project has a fairly specific scope, timeline and budget.

It also has technical requirements.

So, the first thing you should do is write down those technical requirements — does your vendor need to be able to handle SharePoint development? Or a complicated bit of iOS development? Or long-term maintenance of an existing project?

Then, start hunting for possibilities that match those requirements. Google around a bit for firms or freelancers that match those technical requirements and keep an open mind.

Search for “<technology goes here> shop” or “<technology goes here> consultancy” and what have you.

Check out their work and look for any similar projects. Start a spreadsheet or text document and write down every vendor that can meet the project’s requirements. Remember to keep an open mind for now.

Once you have a list of possible vendors, start pinging them for a conversation. Mention the rough outline of the project, including timeline.

It has been my experience that right off the bat, you’re going to lose roughly a half to two-thirds of your possibles at this first step.

Some vendors will never get back to you — and you don’t want non-communicative ones, especially when it’s at the beginning stages. Don’t try to follow up at this stage; just write them off and move on.

Another segment will respond, but won’t work with the timeline. That’s fine. Make a note of it in case circumstances change and move on.

Schedule phone calls with the rest.

When the phone call comes around, outline the project scope and timeline in more detail. Get a good feel for their technical abilities, sure, but make a special effort to talk about how you’d like to communicate and how you’d like the relationship to work. Or ask how they like to manage projects and work.

I also generally like to ask about their other clients. You ideally want to hear a client list that roughly matches either your own size or your end client’s size.

Some other handy questions:

• What work are you most proud of?
• For firms: How big of a development staff do you have?
• For freelancers: How long have you been doing this?
• Do you sub-contract out the work? (Note: major red flag if the answer is “yes”)

You can also ask for references if you’d like. Following up with said references later is up to you: By and large, just their presence is enough for me. After all, it’s very rare that someone will give you a reference who will say something negative.

Take notes at this stage, including your gut reactions.

Once the calls are done, take a look at your notes and narrow down the list to three or so.

Narrow it down based on who you feel most comfortable with and go with your gut. Do they have the chops? Does the way they work fit well with how you like to work? Do they seem professional?

Does the relationship feel comfortable?

These are your finalists. And they’ll be getting The Packet, which I will go over next time.

You have your finalists for outside development partners, and now it’s time to get down to the nitty-gritty: bids, timelines and contracts.

But before you start shipping things off to your finalists, you need to do a good bit of research. Essentially, you need to “walk the coast” (sorry for the Quora link) so your potential partners can give you the best quote and estimate they can.

And you’re going to include all of this in The Packet - a zip file of documentation and project details that you’ll be expecting them to bid off of.

You need to include mocks so they can see what they’re building. You need to have a technical support matrix that outlines things such as devices and browsers you expect to support.

And you need to have a thorough set of functional specifications — how you expect the final product to behave — from end to end as you possibly can.

That means sitting down and writing down what every page of the site or app does. Where do the links go? What happens when somebody fills out this form? What if they do it incorrectly? What if there are no search results? Does this need to be responsive? Do we have mocks for that?

You need to think through this project as thoroughly as possible and you need to write it down in an understandable format. I tend to use Cucumber for this since, if you’re outsourcing Rails development, it can be plugged directly into a testing framework. For everybody else, it remains nice and readable.

Why go through all this work ahead of time? Two reasons:

1. More Accurate quotes Especially if you’re billing an end client later, you want this initial estimate to match as closely as possible to the final outcome. You’re not going to want to go back to your client to ask for more money or more time. The more you’ve thought through the app or site at this stage, the better your potential partners’ sense of the scope involved will be.
2. Speed Yes, doing this up front seems like it just slows everything down. But here’s the thing: The velocity you’ll see later will greatly make up for this. A development team that has all the information they need up front means they’re not going to be waiting on you later. Every little delay when they need to ask a question mid-development will slow down their work, break flow and end up pushing your timelines. Trust me: This work up front will pay off later.

Finally, you need to set the tone for the relationship. I have a standard document that gets thrown into The Packet that outlines how I expect the relationship to work once we get started — where code will live, what sort of contract I expect and a whole slew of other small bits that outline how I would like the relationship to work — both during and after the project.

The last file in The Packet (to go along with the mocks, specs and requirements we talked about previously) is what I call an “expectations document.”

You want to start the relationship off on the right foot by clearly outlining how you expect the relationship to work.

At work, I crafted a standard boilerplate document for all of this. You should as well.

Here’s the things that document covers:

The contract: I’m a big believer in fixed-price contracts. While we’ve “walked the coast” and done everything we can to lock down the scope and get an accurate bid, things will still come up. A fixed-price contract, one in which you end up paying the same amount regardless of how long it actually takes, protects you from most overruns and properly aligns your partner — since they’ll be making more money per hour if they can get the project done in less time.

A fixed-price contract will run you a bit more than a standard hourly contract — typically 20% or so, but sometimes up to a third more. Given the benefits above, I’ve almost always found it to be worth it — especially with client work. The last thing you want to have to do is go back to client for more money.

Communication: My document includes the following phrase:

Always err on the side of too much communication. As a general rule: If we feel the need to ask for a status update, you need to communicate more.

By far the largest and most-important section of this document outlines progress. As a project is going along, you want to be able to know how things are going — preferably without having to actively ask.

Insist on something like Basecamp or the like. Or weekly check-ins, or whatever else you feel will give you a proper level of comfort for how your project is progressing.

You’d think most developers and firms would have a good grasp of this … but they don’t. They tend to get heads down in code, or think it’s acceptable to crank away and then show you the shiny staging link right before launch — when it’s too late to course-correct or do anything about it.

Make sure you’re clear about what your expectations are as far as project updates and communication. It might seem like common sense, but you’ll be thanking me later when you’re not pinging your partner for updates and constantly wondering.

Where the code will live: Related to the above, I typically insist that the source code repository for a project live in our organization’s GitHub account.

This is primarily so I can check on the frequency of updates, have my in-house developers spot-check code as needed and even stand up a staging link if one is not provided (our document also strongly suggests this be done by our development partners).

This request can sometimes be tricky. I’ve never lost a partner because of it, though.

The reason it can be tricky is that it has obvious benefits if things go south later — you can always cut the partner out of the codebase by removing their access to the repository. This is a nuclear option for when the project and relationship is no longer salvageable.

If you were more nefarious (and, for the love of god, don’t do this), you could also remove your development partner at completion and then refuse to pay them.

This is why this is tricky. Firms and freelancers know this is a risk. They’re going to have to trust you. And you might need to split the payments on the contract up such that they know you have some skin in the game upfront to make this work — as in: a portion of the final fee paid at the start of the engagement.

The closing kick: This is another section that seems like common sense: At and around the launch, work will become frenzied and your development partner should be prepared to have additional resources at hand to support that launch.

When you’re doing work for an ultimate client, that closing kick can get even more frenzied. I’ve had situations where ultimate stakeholders (typically our client contact’s boss) didn’t look at the staging link until the day before launch.

And then down comes a rain of last-minute adjustments.

You do everything you can to avoid this, but it happens. You and your development partner need to be prepared for this.

What happens afterward: This will be your kind of wrap-up section. It can cover crediting (can they say they worked on the project? If they do, do they need to link back to you?), final contract payment, expected deliverables (and who owns said deliverables) and so on.

The other two things I insist on are a mention that we might need their help in the future to support or maintain the project and that we’d like to engage in a post-mortem after the project.

After sending out The Packet, it’s time to wait on the bids.

So, we’ve done our research, walked the coast, shipped out The Packet and now we wait for the bids to roll in.

Of course, if you’ve picked the right finalists there should be some valuable clues in this waiting period. For instance: No matter how detailed and thorough your specs, there should still be some questions flowing in.

You ideally want a development partner that finds nooks and crannies you didn’t consider and takes the time to suss those out before submitting a bid.

Another good sign is if they take note of the timeline, realizes what you want done in that timeframe can’t be done in said timeframe and, rather than just rejecting outright, suggests tweaks that can be made to fit it in.

All communication between proposal handoff and their bid is super valuable. You want to get the feeling they’ve been deeply considering the project plan and want to be a partner in its (and your) success with it.

When the bid comes in, you’re going to want to compare apples-to-apples. Even though we’re going with a fixed-price contract number, you still want to get an idea of the hours they have in mind to complete the project. So, if it’s not in their bid, ask for it.

What you’re looking for is if all three bids are in the same ballpark, aside from their hourly rate. Do all three think it will take 300 hours to produce? Or do you have one that says it’ll take 125?

If one’s way off from the others, be very wary — especially if it’s low. You want to make sure everyone has a sense of the same scope, and if you have two that match and one that’s way low, it means they might not have fully considered what the project is going to take.

If one is high, talk to them and find out why. It could be that they’ve considered something the others haven’t.

I know you’re thinking, “But I thought we went with fixed price so we didn’t have to worry if our partner underestimated the project?” To a degree, yes, but you also want this to be a harmonious relationship … And if your partner severely underestimated the time and complexity involved, fixed-price or not it’ll end up being anything but harmonious.

At the end of this, you have to go with your gut to a large degree. Who do you want to work with? Who feels like they’re on the same wavelength as you? Which of the three feels like it’s going to knock this out of the ballpark for you?

I generally lean toward picking the middle bid if all other things are equal and that’s served me well so far. Your mileage may vary, obviously.

At the end of the day, cost shouldn’t matter too terribly much. We all have budgets, but the cost of a project that’s gone off the rails is much greater than the cost of a higher initial contract — trust me.

Thanks for reading all the way through. I hope you learned something you can find useful.

If you want to follow along for more of this sort of thing, I have a blog, a twitter account, and a forthcoming book.

As a final note: I want to encourage you again to shoot me an email if you ever need help with hiring - whether inside or out. I'm also a pretty mean debug partner if you're dealing with load balancers, Ruby apps and general nerdery. I'm always happy to help.