As part of my efforts to keep my posts short and sweet, I'll cut to the chase:
If you're working on a development project, development of just about anything, then you need a statement of work (SOW). Forget the terms and conditions (legalese) for a second - the SOW is the meat of the agreement when it comes to development deals. It answers the 5W's (and sometimes the How - but this should be avoided or at least kept to a minimum).
Here's a basic SOW structure (there's no ONE right way):
Section I: Project Overview;
Section II: Business Requirements;
Section III: Proposed Solution & Approach;
Section IV: Description of Deliverables;
Section V: Deliverables Schedule (ideally, a table with rows and columns spelling out which deliverables due by which milestone dates, milestone payments associated with acceptance of each deliverable, responsible party(ies);
Section VI: Acceptance Criteria (for customer, the ideal is absolute discretion: "upon acceptance by customer as determined in customer's sole discretion" whereas the opposite (seller view) extreme is acceptance is deemed to occur upon completion of deliverable - somewhere in between you might have to set out objective standards on which to determine if a deliverable is acceptable);
Section VII: Project Assumptions (level of customer involvement/committed personnel, equipment provided or needed, preexisting materials to leverage from or to build upon, technologies with which deliverables must be compatible with, etc.);
How many contracts actually contain such detailed SOWs in the Real World? Few, unfortunately, and it's usually the customer's fault due to lack of time and/or expertise to plan ahead and exercise diligence. This reminds me, Sellers, beware of customers who show a lack of diligence and preparation on the front end. In my experience, most development projects that fail stem not so much from sellers overpromising and underdelivering - but from customers who lack a clear vision for the project coupled with an unrealistic expectation regarding what it will take to do the project right. If you get a sense that the customer is hoping to "throw it over the wall" to you, watch out. This customer type thinks you're the expert who should be able to magically figure it all out at the price they're paying (they'll think this no matter how good a price you gave them).
Interview the person on the customer side who'll lead the project to assess how strong they are as a project manager and how well they grasp the project. Inexperienced project managers on large, complex projects can be your worst customer nightmare. Protect yourself and your company by beefing up the "Project Assumptions" provision and add lots of detail about what the customer will have to do to uphold their end of the bargain. For example, if you need a SME to allocate at least 10 hours per week for reviewing and signing off on deliverables, put it in there and keep track. This may come in handy down the road if the customer wants to terminate and blame the failed project on you (blaming the vendor is always the convenient scapegoat for incompent project manager/customers when they have to explain what went wrong to their boss).
Oops, this post is getting too long. One last critical thing to remember for ALL development projects: Include an intellectual property (IP) clause that spells out who owns what. Customers oftentimes want to own everything since they're paying for it, whereas sellers want to own everything to build out their IP assets, create new products for resale to new customers, charge customers for tweaking the deliverable down the road, etc. Customers will want the IP clause to treat all deliverables as work-for-hire, and as a fallback, an assignment of ownership. Sellers want to own and grant the customer a license to use (usually perpetual with rights to create derivative works). A third option in joint ownership - but customers have to live with the possibility that the vendor will resale to competitors; whereas sellers don't want customers with joint ownership to compete with the seller or have the ability to sell or license their rights to seller's competitors.