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.