Brady commented earlier about the A-number-1 problem with being a contract software developer. I've been burned by this more often than not. So I've stopped allowing those kind of events to take place. Instead of playing Swammi The Magical Mind-Reading Bridgebuilder, I start out by charging a flat rate for what I call "Project Discovery". At this point, we build the bridge's blueprint. We interview everyone currently involved in the existing processes, and map them out. Then we separate manual from automated processes, and kill any steps that can be eliminated.
When this phase is finished, we have a complete recommendation for moving forward, including the dedication of resources, estimated timelines (with healthy buffer zones, AKA The Montgomery Scott Principle of Starship Repair) and project milestones. We then bid a flat rate for the project, with equally disbursed payments at each milestone. If the project is accepted, each section of the contract is initialed, and the document is signed by all parties involved. It then becomes etched in stone and unchangeable.
If the project is accepted, the entire project amount is deposited into an escrow account, and funds for each milestone's payment are released upon satisfaction of service for that milestone.
Changes to the plans are strongly discouraged, and therefore I make the change process as difficult as obtaining a Constitutional Amendment. Any deviations from the plan are agreed to in writing, signed by both parties, and are then billed on an hourly basis. If you went through the planning correctly (preferably using the MSF process, as Jesse corroborates), there shouldn't be too much need for deviation in about 60% of all cases.
This is an extremely simplified version of my consulting process, but it's a good overview. If you're going to start consulting, and just jump right in, you're doomed to fail. That's what I did, and I'm about $12,000 poorer because of it. YOU'RE the expert, so it's up to YOU to make sure that the framework for success is in place, because your contractor isn't going to have a frickin clue what they're doing. It's up to you to make sure that the job functions are delineated, and keep the project on course. Don't let businessmen start telling you how the database should be structured, that's not their area of responsibility. If the project gets out of hand, as the technical expert, it's your fault for not standing your ground and keeping it in check.