Better Contracts Mean Better Outcomes
Because we specialize in custom development, every client is different. That’s awesome. Because it means we never get bored. But in this age of agility and flexibility, it also means that writing good project documentation is more important than ever. Rather than attempting to address the issue from every side, we wanted to start off with what we see as the most important form of written documentation a developer provides to their client: the contract.
Typically, a work agreement isn’t the first piece of documentation customers receive. It’s more like the second or third. Often only after they’ve received a written a response document and a proposal.
For that reason alone, contracts don’t always get the attention they deserve. It’s not uncommon for developers to put lots of work into getting a piece of business. A great deal of energy is spent writing an RFP response – and then spending lots of time on crafting the project proposal. By the time a client is ready to request a contract, substantial time and energy has usually been spent to earn their business. It’s only natural that there’s a desire to close – in order to recoup the time and effort spent.
At the start of every project, we like to work backwards from the finish line – just as an exercise. We imagine the best possible outcome; a happy client who’s thrilled with what we delivered. An internal team who feels gratified by the opportunity to do great work. And a balance sheet which shows that we were all fairly compensated for that work.
Not excessively compensated. Fairly compensated.
Not some of us. All of us.
Then we think about all the potential obstacles between that ideal outcome and the starting line. There are usually at least one or two aspects of every job that are less than ideal. Maybe the client doesn’t have enough content to accomplish their goals (common problem). Maybe there’s a rush timeline, but some doubts exist about whether or not they can hold up their end of the bargain, strategically-speaking. Maybe it’s a complex project that warrants extra QA time. Or we aren’t sure their production environment will hold up as well as your staging server –because they aren’t able to provide specs just then.
All of this is a strong case for spending as much or more time on writing (and reading) work agreements as earning (and shopping) a project. Think about the potential problems you envision. Get internal consensus on what the issues are. Industry conventions aside, every client is different. From the very biggest, to the very smallest; each one has their own objectives. Be honest. Be direct. Don’t be shy about talking money. But don’t let that come between you and satisfaction.
A good developer knows all of this, and doesn’t get uncomfortable talking about good faith.
Think about what isn’t being said. Then think about the ways in which your workflows will need to integrate. Do some soul searching about both the spoken and unspoken goals that you are each bringing to your project. Put yourself in the other guy’s shoes, and see what you would be most concerned about. Beyond the boilerplate which exists by necessity.
Just for a moment, forget about their proposal system. Think about the content; what’s actually written in that contract that so few of us really want to read. Maybe it’s precisely because we don’t want to read it ourselves that we work really, really hard on writing work agreements. Because at the end of the day, they help to ensure a happy outcome for all parties involved.
If there’s a substitute for elbow grease, we haven’t come across it yet. But a good developer takes time to write good paperwork. Even the legal stuff. If you’re worried about their workflow, establish time parameters for job completion. If you don’t think their hardware is up to snuff, insist that they establish who the responsibility for hosting rests with, and what exactly that entails. If HIPAA compliance is even mentioned, chances are there should be a BAA in place.
You get the picture.
Think about what you don’t want to think about. Then focus there.
It helps to have a punchlist on hand right out of the gate, so you have the basic requirements covered. But for a client relationship to be truly successful, the work agreement needs to not just address the responsibilities of the developer. It should also establish clear ground rules for work processes and the role that each party is expected to play. That includes timely approvals and feedback from you (the client), and delivery requirements related to any third parties.
Be honest about what you’re able to achieve with the time and resources at hand. Remember that there are times when a good developer may need to say “no”; if only to preserve your overall satisfaction with the end product. Beware of scope creep and vaguely written SOWs. They’re harbingers of lost revenue and client ire. If you’re smart, you already understand that they’re running a business. A business that needs to be there, down the road, to support your aims. When one side “loses”, nobody really wins.
A well-written work agreement isn’t cumbersome. It’s reassuring. You can read it and know your developer took the time to think through all the angles. It establishes the ground rules for a long-term relationship, based on mutual success. It means that they take your objectives seriously, and fully intend to be there to help realize them. When all is said and done, the contract is truly king. It’s a good way to know you’re working with the right partner.
It’s also the first step on the road to that ideal outcome.