I don’t like working with contracts. There are reasons:
They take time to write. For small projects, that can be a big deal.
From my experience, many people want to see the contract while they are still deciding whether to proceed with their project. That means the time invested is often wasted.
Contracts fence in both parties. That makes sense for technical work, but writing is often as much art as science. Clients change their minds. Our writers come up with ideas mid-stream. It’s hard to work within the limits of contracts.
So there are times when we don’t work with contracts:
- When the project is small. The client hasn’t risked much money and we haven’t risked much time.
- When we are editing only. There are no copyright issues if we are just editing.
- When writing speeches. If it’s not being published, clients are not concerned about copyright.
But there are times we do use contracts. There are times when a contract is important. So I take steps to minimize the problems that contracts cause.
Work with a template
Depending on the nature of your services, a single template might do, or you might need several. We take on quite a variety of writing projects:
- Editing
- Articles
- Reports
- Speeches
- Blog posts
- Screenplays
- Web content
- Press releases
- Book manuscripts
The only projects big enough that also have a significant copyright concern are screenplays and book manuscripts. I am able to work with a single template for both. The same elements need customizing for screenplay and book contract, with only one element differing:
- Price
- Timeframe
- Writer name
- Payment schedule
- Special requirements, if any
- One-line summary of project
- Client/author name and coordinates
- Word count for books, minutes for screenplays
The template allows me to very quickly draft a contract. Very rarely does a client ask more than very simple edits. When they do, it has (so far) always been serious clients who end up signing the contract and hiring us.
Use an agile contract approach
Contracts box each party in. Long before the term “agile contracts” was coined, I was writing agile contracts meant to enable the work to be done to the client’s satisfaction, rather than to hold anyone to predetermined notions.
There are four steps to making an agile contract. We incorporate all of these in ours. A number of elements of our contract have been written as enablers rather than as jailers.
Flexible timelines
We don’t want a project to drag on forever any more than our clients do. But we also recognize that part way through a project, life happens.
Our clients are mostly individuals (writing fiction books, screenplays, biographies and speeches) or small businesses (writing business books, presentations, reports and articles). And life happens. A family member gets ill. A client has to go overseas for a few weeks. Changes in the marketplace or the supply chain need addressing more urgently than a writing project.
The fact is that no two books take the same time to write.
So we respect the client’s schedule in a collaborative approach by keeping timelines open.
Approximate word counts
We don’t specify the exact number of words in a manuscript.
Obviously, the number of words has a big impact on both us and the client. Imagine the difference in time it would take to write 45,000 words compared to 75,000 words. Imagine the difference in price to print the two. Imagine the difference in expectations for readers opening up books of those different lengths.
However, can you imagine how much extra work it would be to add in exactly 1,264 extra words to make the manuscript an even 55,000 words? It’s not just the extra work involved; the quality of the manuscript diminishes with unneeded words sprinkled in.
When it comes to word count, precision is counterproductive.
So we set approximate word counts or ranges of word counts. Sometimes, clients want more information added than would fit not well within the word count. In those cases, we give them the option of:
- compressing the information (if we are still near the start)
- amending the contract to accommodate the change in scope
- choosing what not to include (of what we haven’t yet written)
This is part of remaining flexible or “agile” beyond just the contract itself.
Optional add-ons
Very rarely do we specify in our contracts how much research is required or what face-to-face meetings a client might decide are needed. We normally just use the template language that outlines the cost for client-requested research and meetings. That transparent process leaves the client with freedom to manage optional aspects.
Only when a client absolutely insists on these elements do we quantify a base amount. That base amount is only what we know the client absolutely needs. We consider it better for clients to ask for more, if they wish, rather than to pay for research or meetings they don’t need.
This approach also makes the client think twice about asking for more meetings or research than is needed. If it’s all included, it’s like writing a blank check…which some clients would gleefully cash in over and over again.
No-questions-asked termination
This amazing clause has never been formally invoked. We offer a no-questions-asked termination. If clients change their minds, they can terminate. If clients run into financial challenges, they can terminate. If they don’t like the direction we are going, they can terminate. We’ve had clients disappear, but never pull out.
This is in part due to our agile payment schedule.
Payment by progress
We don’t ask for up-front payment on big projects. $10,000 or $15,000 is a lot to pay in one shot. We usually divide payment into three installments, although we are flexible about how to divide it. The installments are all tied to progress points in the manuscript, rather than to specific dates.
Typically those progress points are based on the project’s word count rather than passage of time. We feel that this is a more transparent and collaborative approach.
This means that clients are never pressured financially to rush their feedback. It also means that if they have financial challenges, we can slow the project down to respect their needs. And occasionally, it means that a client might disappear altogether , rather than ending a contract.
Client satisfaction
It is hard to guarantee client satisfaction in any artistic work. But if the client is watching closely and giving feedback as we write, satisfaction is almost guaranteed. So our contracts place the responsibility on the clients, and we encourage them to give as much feedback as possible. We are the writers, but the clients are the authors. This collaboration is critical if clients are to get the results they envisage.
Contracts can be made less of a burden
As much as I dislike contracts, I know that they can be important. By using templates, the burden of writing contracts can be greatly reduced. By applying agile contract principles, the burden of using them can be less taxing.
I am happy that we can focus on delivering the manuscripts our clients envisage, rather than on ticking off boxes in a contract.