This article is about how contracts are key to communication, set the right expectations, benefit both parties, and give some practical advice on how to use them as an effective tool when signing up for dev work.
Table of Contents:
- Leveraging Contracts as Essential Communication Tools
- Realistic Expectations & Budget Management for Success
- Balancing Legal Aspects with a Human Touch in Contracts
- Navigating IP Ownership and Transfer Using Contracts
- Defining a Comprehensive Scope of Work
- Harnessing Contracts for Successful Collaboration
Leveraging Contracts as Essential Communication Tools
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 have to show them yours. “Mike Monteiro: F*ck You, Pay Me: CreativeMornings/SF.” CreativeMornings, creativemornings.com/talks/mike-monteiro--2/1. Accessed 3 May 2023.
Building Trust and Clear Communication
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 that contracts are a communication tool. We can clearly express deliverables and expectations with a contract better than any other forum.
Contracts can be viewed in a positive light as a communication tool between two parties. From a software 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.
Realistic Expectations & Budget Management for Success
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.
Avoiding Over-Promising and Ensuring Financial Clarity
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 is. If there isn’t enough clarity upfront 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 costs, 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. This usually happens when the client pays their bills.
- Budget! Even if this is a time and materials (T&M) 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 effect of “Let me know when I’m halfway through my budget.”
Fostering Regular Client-Developer Communication
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 client's perspective, make sure the firm 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!
Balancing Legal Aspects with a Human Touch in Contracts
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.” A true statement, and a lesson learned.
Protecting Interests and Setting Expectations
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, but 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 upfront not only helps the client focus on the project; 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. Creating a software consulting agreement is not only for legal purposes, but they are also about managing expectations.
Navigating IP Ownership and Transfer Using Contracts
As I mentioned before, transferring IP is important. The client wants to eventually own what they’ve paid you to build, so let's make sure there is a clear legal way for them to do that. Their leverage to own 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. This can be slightly different for a project solely based on research, but it's still very similar.
Defining a Comprehensive 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 upfront is important, but 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.
Balancing Detail and Flexibility in Scope of Work
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. This is key when creating a software consulting agreement. 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 the requirements and design phase are, here.
Harnessing Contracts for Successful Collaboration
So there you go… some reasons why contracts are important (we all knew that) and some information about how they can be used as an effective tool between clients and software development firms. 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 understand how contracts can be vital to communication and expectations for dev work.
