This is the third post in a multi-part series on becoming an independent software consultant. The essence of the series is to share my experiences, accomplishments and shortcomings in the process of building my own software business.
One of the most nerve-wracking tasks a new independent contract must do is get a new statement of work (SOW) signed. No one wants a sales lead that doesn’t close when they’ve just ventured out on their own, and this often leads young consultants to create half-baked contracts (if they write a contract at all).
Perhaps it comes from a position of fear, which is very common for the new freelancer: I have to get this agreement signed as quickly as possible before they change their mind. If not, it comes from sheer ignorance or lack of experience. With a little forethought you can save yourself the experience of losing a client due to a faulty contract.
What Holds a Project Together?
If getting an SOW signed and executed is the left-hand bookend holding up a lofty workload, what is holding up the other end? More to the point: how do you know when you’re done with the work and does the client see it the same way?
Any indie consultant who’s rushed to get a contract signed can tell you what happens when you don’t think ahead.
Let’s make up a random, completely hypothetical, consultant and call him Josh S., no no, J. Stephenson. Eventually this fearless contractor gets to what he perceives as the end of the contract, he’s put in a lot of hours, probably more than he originally thought were needed. He had to make a number of concessions along the way, but he thinks he’s done and he’s ready to ship.
Only, the client is requesting a few more tweaks and bug-fixes. What is our fearless contractor do?
Q. When is a bug not a bug?
A. When you and the client disagree about whether it’s in-scope, that’s when.
All software has bugs, it doesn’t matter how production-ready it is. Production deployments in that sense are basically concessions about what is considered good enough, which brings us back to the agreement. Do you want to be on the hook for a bug free product forever? How do you decide what constitutes an in-scope bug versus an out-of-scope bug?
Questions like that are what lead people not to even take on fixed-fee software 1. That’s understandable, but there are some really big upsides to fixed-fee software:
- You ship often. Fixed fee projects can be great because they hit the AppStore or the public web. Nothing feels better than shipping real software. Time and materials contracts 2 can drag on for a long time without ever shipping.
- More opportunity. If you rule out all fixed-fee projects you might be leaving money on the table.
There are two ways to solve this problem. You can handle it with long, detailed specifications. Then, if it’s not in the specifications it’s not supported. This might sound like a good idea, but it really pits you and your client against each other. You don’t want to punish your client for not specifying something that he or she thought was obvious.
The second way is with strict scheduling. Add a schedule to your agreement that clearly delineates the phases of the project:
- When will development be completed?
- When will Quality Assurance start?
- How much time does the client have to identify and prioritize bugs, issues and requests?
- What is the time-frame for handling the above?
- What happens if any party is late with any of the above?
Essentially what works well in smaller projects is to have ample time to address bugs. If you take pride in what you do, you don’t want a poor, buggy product shipped any more than your client does. The critical item then becomes what happens if the client isn’t responsive enough to provide issues to you in a way that gives you time to resolve them.
Make sure these items are clearly documented in your emails and agreements. Meet in-person or over the phone and walk your client through it so there’s no confusion about what the completed project will look like. Plan on reminding your client leading up to the feedback period, that they will have a limited window available, after which you will need to bill for items as out-of-scope. Better yet, use a project management tool that will send email reminders in advance of feedback delivery dates.
When it comes time to send the final invoice, you’ll be confident that the client is happy and ready to pay.
Stay tuned for the next post in this series. If you enjoyed this post, you can follow me on twitter: @frivolousjosh