This post is about how contracts benefit both sides, and gives some practical advice on how to use them as a communication tool.
What is one of the most important aspects of development work that is also probably the most boring and overlooked? The paperwork! Once you decide to play with the varsity, you need to take contracts seriously. To quote Mike Monteiro “if they show you theirs [lawyer], you gotta show them yours.”
So why then, if we talk about how the core of our company is based around ‘giving value’, do we care so much about building trust, and then send that same trusted client 15 pages of legalese and CYA? Because building something, even with pixels and 1's and 0's is emotional,and stressful. The other, nicer, better answer is because contracts are a communication tool - we can clearly express deliverables and expectations with a contract better than any other forum.
”...building something, even with pixels and 1's and 0's is emotional and stressful.”
Contracts can be viewed in a positive light as a communication tool between two parties. From a development or technical services standpoint their importance can’t be overstated - but it doesn’t have to be a sore spot.
This post is meant to be informative, but I’m not a lawyer, and this is not legal advice — Hopefully this is some good information for you to take to your lawyer so that your contracts are fair to both sides.
Contracts are a communication tool:
If you are a client, setting expectations of what you want the final output to be is obviously really important. Setting realistic expectations with your client if you are the development shop is often one of the biggest helpers to a ’successful’ relationship. If you over-promise, there is no turning back. The same is true for the client; if your expectations are not realistic, then nobody can make you happy no matter how good the service. If there isn’t enough clarity up front so that BOTH parties understand what service they should receive, then the chances of the relationship going well are really small.
Often, one of the toughest things for both businesses and clients to talk about is money and you really want to make sure both sides are on the same page. Contracts are a great way to summarize the expectations that both sides have concerning payment, delivery of the product, and what happens when weird stuff happens. Some key points around communicating how money and IP are transferred:
- Set payment terms (on receipt, 30 days, 60 days, etc..)
- Set rates or project cost, be super clear about what resources/rates will be used on the project
- The business is usually creating the Intellectual Property (IP) (source code, designs, strategy, etc.) so make it clear when that IP transfers to the client. Usually happens when the client pays their bills.
- Budget! Even if this is a ‘time and materials’ project, a budget can be defined and adhered to. It’s very reasonable to put a statement in the contract that says something to the affect of “let me know when I’m halfway through my budget.”
Another point of consideration is actually putting some language in your contract about how often the client is expected to communicate with you (This one bit us in the butt on a couple of our earlier projects). Or, from the clients perspective, make sure the business you hire will commit to keeping you in the loop - we put that in all of our contracts.
“It’s important for a doctor to use their stethoscope to listen to your chest, but damn, warm that thing up first!”
Warm up first - contracts are cold.
Once upon a time, in a land close to here, and not very long ago Anthroware lost a client because we showed up with a contract too soon. We really wanted to get started, to start providing value for the client, but the scope of the work wasn’t well defined yet (our first mission with the project) and the deal ultimately fell apart with a true and compelling comment from the client that “there was more in the paperwork about making sure you get paid and legal stuff than language about the work to be performed.” True statement— lesson learned.
That legal stuff is important. Getting a contract in place before you touch any of the client's data or project materials is important. Contracts, by nature, aren’t really exciting warm and fuzzy reading material. It’s important for a doctor to use their stethoscope to listen to your chest, but damn, warm that thing up first!
The point is that once you are confident that you have a solid contract, spend some time telling a story about how it’s mutually protective of their interests and yours. Mention the legalese, and walk them through it. Spending that time up front not only helps the client focus on the project, but if you have a fair contract and explain it well to your client then the expectations for the engagement will be set from the beginning. Contracts are legal, but they are also about managing expectations.
Ownership
As I mentioned before, transferring IP is important. The client wants to eventually own what they’ve paid you to build, so lets make sure there is a clear legal way for them to do that. Their leverage to own it is the contract and their money — the development shop’s leverage is that they own the IP until the client pays them. This is fair to both sides, and it works out cleanly if everyone upholds their end of the bargain.
Scope of Work
Ah, the specification… This is the blueprint of your project. Good agencies always define a scope. Some are more detailed than others. For large projects we may have 70-page documents with screen mockups, architecture diagrams, use cases, and pages of business spec and technical spec writing- and that is still just a starting point. We know that planning up front is important, but that we also want to be agile as the process flows forward. For simple projects the scope might just say “Anthroware will perform some technical/design services. And you agree to pay us for it.” Well that’s an oversimplification, but you get the idea.
You always want a scope of work with your contract. How much information is needed? That’s up to you and the development shop - don’t stop until you are comfortable. Keep in mind that you want to be flexible so that the maximum amount of time is spent doing the work you want, and not updating the legal contract. Clients should expect to pay for time and materials to develop a really detailed scope of work. I rant on about how important requirements and design phase is here.
Summary - Contracts should make you happy.
So there you go… some reasons why contracts are important (we all knew that) and some information about how they can be used as a communication tool between clients and the dev shops. The posture of how contracts are presented is of the utmost importance with how this part of the client interaction is perceived.
Hope this helps you out.
