This is the second of my four part series on how to communicate with your developer. Part 1 covered Interviewing Your Potential Developer. Part 3 will cover Version Control and Part 4 will cover Bug Reporting.
Planning
As the old adage goes, “Bad planning on your part doesn’t make it an emergency on mine.” This is exactly what your developer is thinking when you make last minute feature requests that were not in the original work scope.
Planning is about setting expectations. If expectations are spelled out up front, there should be no surprises. This is an ongoing process and expectations will need to be revised as you move forward. Your developer may lack the skills to proactively set expectations, but you can take on this responsibility. The developer will probably thank you for doing so.
The Statement Of Work
The most critical document you need for any size project is a Statement of Work (SOW). The SOW needs to contain a detailed description of the project, the milestones, a timeline and payment terms. Depending on the complexity of the project, your SOW may need to contain specific details about each feature and how that feature is supposed to operate. Include as many specifics as it takes so that little is left to interpretation later.
This is the time to address code ownership. Who owns the code that is generated as a result of the project? Different developers have different points of view on this subject so it is important establish this early. In my work for hire contracts, our clients own the iteration of the code that we develop for their site. This means that we are able to re-use our routines on other projects, but we cannot re-use an entire project elsewhere. If you want to own the code, then you will need to negotiate this in advance and the SOW is a perfect place to do this.
Take your time creating the SOW. Your developer should not write one line of code until this is finalized and agreed upon. When I create an SOW, it typically goes through several drafts. I will submit a draft to my client for their review and then they will make edits and submit it back and so on until we both agree that it is final. You can use Word, Pages or Google Docs for this process. Whatever software you use, make sure you use the “Track Changes” tool so that you can see the progression.
Once the SOW is complete, both parties need to sign a copy of it to signify that they agree. For larger projects, my SOWs get attached as an exhibit to the work for hire contract.
A couple of important notes:
- You can never over-plan! Good planning and documentation reduces the guesswork as your project gets developed. Anything you can do to cut down the margin for error will save you money in the long run.
- Always try to avoid doing anything as a rush. You are always asking for mistakes when rushing.
Project Management Site
Your developer should use a project management tool like Basecamp. This will allow you to track your deliverables and project schedule. The site needs to have a good commenting system so that your conversations around a particular task are centralized in one place.
DO NOT use email or instant messenger to track tasks! These conversations tend to get lost in the shuffle. I have found that important parts of the conversation get lost when someone accidentally forgets to cc the group. 
The SOW should become a road map for your project management site. All of the deliverables from the SOW need to be converted to tasks on the site. This can be done by you or the developer. In addition to task tracking, your project management site should be used as a central place to post feature discussions, technical notes and design comps. Your project schedule and major milestones should also be tracked on the site.
At Zeek, we use a site called GoPlan. GoPlan is similar to BaseCamp, but we switched because it has a good bug tracking ticket system built in.
Take an active part in the project management, but be careful not to micro-manage your developer. And when possible, ask your developer to use a screen sharing site like GoToMeeting.com to explain when you don’t understand something their saying. So many communication issues can be solved if a little extra time is taken at those critical moments in the project.
Up next: Part 3 – Version Control
