1. Write a Project Outline. Say exactly what will (and just as importantly) won’t be carried out as part of the project. This can take a lot of time to put together, but is essential to avoid trouble later. Even better get the client to pay you to write this, as it’s vital for them as well.
2. Client dependencies. Do you depend on the client to get things done? If so, specify exactly what the must provide and when. Can’t specify exactly when you need (and there are many projects where this is the case)? Then do the work on a time and Materials basis only.
3. Be visible to end client. The temptation is to go into a dark corner and start coding. The trouble is that you emerge blinking into the daylight at the end to find (i) The client frantic with worry about how the project is going and (ii) that events have happened that you sh. ould have known about. Price in regular time on the client site to keep in touch.
4. Contingency. A wise man once said (In this case the instructor at the PMBOK course in Chicago): ‘If you can’t carry out the project with 15% time left over , don’t start it. For fixed price projects, make this something like 30% as the client will ask you to do little ‘extras’ and you can’t ask for extra money for every single one.
5. Almost as important as knowning when to start (see point 1) is knowing when to finish. Document everything and do a final ‘handover’ day (a good idea is to hand over a CD whith all project deliverables on it). If you don’t do this, the project will never end, and you will never get paid.

Notice that all these items are about process , and not technology. Put simply; you can mess up your project just as easily using Java , PHP or .Net . Mess up as an employee or consultant, you get shouted at by the boss. Mess up on a fixed price and you’re into serious pain as you burn through (unpaid) extra time.