>>>
>>>You learn as you go. One thing I learned (there is a long list) is to state what you will do, have it signed off and state, "Any changes or additions beyond the agreement will be billed at $105 per hour". I welcome changes and expect them. Some clients are very careful and others could care less.
>>>
>>>Tom
>>
>>Good idea. I now commit myself to a schedule of delivery dates *and* get the customer to commit to sign-off dates (it works both ways and the client gets a comfort factor: very hard work if I hit a problem though). I also insist on a core list of functionality which will be guaranteed by me to be present ('Must haves') additional functionality which I will add if ahead of schedule ('would like to have') and features which will cost extra and be in the next version or as a separate job at additional cost ('would ideally like'). Interestingly, I've found that if provided with a timetable, many customers are prepared to cut the spec rather than extend the timeline, as they have committed resources to be available for testing, etc., at certain dates.
>>
>>They should teach this sort of thing at college, along with the programming and analysis skills.
>
>Robert;
>
>Good idea! The relationship between client and developer should be 50-50. Deliver what was agreed to on time and get paid on time.
>
>Tom

Exactly, the more commitment you can get, the better. I now call my contract a 'Co-development agreement': it sounds a bit politically correct, but I view it as a 'psychological' ice-breaker.

RJL