Contracts have a funny way of bringing enthusiastic and optimistic partners in a project quickly back to earth and miring them in angry back-and-forth that can soil the project before it even starts.

The following article is based on our experience issuing contracts for +Confluent Forms LLC as well as reviewing contracts on behalf of clients when performing technology advising services.

Be equally fair

By default, lawyers will craft a contract that is the most defensive posture for your company. They want you to be on the safe side and in control. The contract is meant to protect you, give you all the rights, and give nothing to the other side. If both sides take this posture you’ll end up in a Mexican Standoff with nothing but empty wasteland between you. Every good contract is built on compromise and the desire to see the project succeed. Too much pessimism can be a huge turnoff.

If you make a promise, keep a promise

Salesmen like to be optimistic and promise you the moon, executives want to be realistic and not be held accountable. This behavior often is seen when a sales person promises you the entire project for a specific amount, but then when you read the contract, you see language such as “this is only an estimate and the final project price might vary due to a number of factors“. Most customers never notice this line or realize its impact. We have heard of projects in which a price tag of $100,000 was promised, this line was in the contract, and the project ended up costing around $200,000 when all was said and done. Which brings us to our next point…

Definition and Statements of Work

Definition is something often sorely missing from a project. Spending more time defining the project and pricing, and being clear about what the project consists of and how the project will be billed, will save the project from countless misunderstandings, confusion and potential strife. The two sides can be looking at the same one sentence describing a piece of functionality but have widely disparate views on what the description entails. One view could be exceptionally complex and expensive, the other view could be a 30 min endeavor. This can turn into the following exchange:

“Well, the SOW says you’re going to implement a ‘user profile management’ feature to the site, but you’ve made it so it only captures first name, last name, email address and password. We want it to capture that, their home address, business address, areas of expertise, newsletters they’d like to receive, companies they are affiliated with, etc. etc.”

“None of those things are mentioned in the SOW so they aren’t going to be implemented in this project… perhaps an add-on phase?”

“What do you mean they aren’t in the SOW? It says USER PROFILE MANAGEMENT and those are the pieces of information that are captured in our existing system under the user’s profile.”

At which point both sides have the option to stand down and accept the other person’s point of view or to fight for their opinion of what is stated in the SOW and both yield to negative feelings. The moral of the story? Definition saves projects.

Use project milestones for the payment schedule

We were once involved in a project where the technology firm wanted 40% of a $100,000 project paid upon signing. There was no mention of this huge upfront payment during the project talks, but then upon receiving the contract, there was an invoice for that whopping amount. Needless to say this left a bad taste in the client’s mouth and they immediately balked. It is entirely fair to require a percentage upon initiating the project; it is also entirely fair to require a percentage held until the final project is delivered. But rather than having it be 50% upfront and 50% on completion where the client isn’t happy at the beginning and the firm isn’t happy at the end, we recommend schedules along the lines of 10%, 17.5%, 17.5%, 17.5%, 17.5%, 20%.

Prompt payment and late payment fees

A happy contractor is a contractor that gets paid regularly. An unhappy client is a client that gets billed late fees. Seems simple, right? Contracting firms want to make sure that they get paid for the work they are doing, get paid in a timely manner, and don’t get left holding unpaid invoices while the client has the finished product in-hand. At the same time clients rarely like to feel that their work is being held hostage or that they are being threatened into paying by excessive late fees.

Contractors should be entitled to putting a small late fee clause into their contract. They should issue invoices for periodic and smaller amounts so that they can be sure they are being paid regularly and that they aren’t left holding too much unpaid work. Clients should be good about paying timely and that timeliness should take the project length into account. If the project is scheduled for 3 months, a 60 day payment period simply can’t work. I recommend a 14 day turnaround on all invoices for projects until 4 months, and a 30-day turnaround for projects lasting greater than 4 months. Combined with the milestone payments above, everyone will know when monies are due and at what progress point they are to be paid.

Be clear about ownership of the final product

Technology and ownership can get tricky sometimes, especially when companies try to reuse code and software systems that they’ve built in the past as a way to build bigger projects quicker and with greater profit margins. In these cases lots of companies like to say that what they’ve built is a proprietary system and that they are licensing it to the client, which can be fine if the client is given a license to take the complete system and take it elsewhere without selling or distributing it.

But when this isn’t fair is when the company puts limitations on the license that it must be hosted on their platform or that the client only owns the data in the system and that the work the client has paid for is only a customization of a proprietary system and not transferable. While firms are entitled to sell ASP-model (Application Service Provider) systems, they should be clear with clients about how this works, the upside as well as the downside.

Be upfront about additional costs to the project

Most clients go into a technology project not knowing much about technology. Many would not know that hosting for a website is something that you need for a website nor how to go about getting “that name thing that I put into the browser”. They won’t know that the site requires a license for Oracle, or a dedicated server due to technology requirements, or anything like that. Clients need to know about upfront costs before they are sprung with them in the contract or notified about them after the project is completed and they are ready to go live with their site.

Don’t hold hostages, define breakaway clauses

The milestones and payment schedules mentioned earlier are good for another thing: breakaway clauses. Nobody wants to have to hold back work from the client until they get paid, and nobody wants to be in a project that is clearly going in the wrong direction. Breakaway clauses and clearly defined milestones allow both sides to amicably walk away from a project at predefined points if it is mutually decided that the project should be put to a stop.

Each contract is different; while the above items won’t cover all situations or guarantee that your project goes well, hopefully they’ll cause you to take a second look at the contract you are handing to a client or another glance at the contract you are about to sign. And for God’s sake, read and re-read that contract, don’t skim!

If you run into an impasse, call a mediator

Sometimes both parties really want the project to happen, but at the same time, reach an impasse. They both believe they are in “the right” and need to protect their interests, while at the same time not wanting to back down. A technical mediator can often assist both sides reach an amicable agreement, bridging the gap between the sides and making sure that both sides continue to appreciate the other’s opinion. It’s never good to start a project on the wrong foot!

[formerly titled: “How not to destroy a project during the contract phase”]