Every now and then as a developer I'm asked to get involved in projects where the goal posts continuously move into the distance.  No matter how close you seem to get to finishing, there is alway just 'one more thing' that needs to be added or finished or updated or changed, in the industry this is called 'spec-creep'.  Projects like this seem to come about in two different ways: Either they weren't specified properly in the first place so no one know when the job is actually finished, or the client just ignores the spec and imposes their will on the client handler and development team.

Some projects cope worse than others when this happens.  Highly technical projects where many components need to be built to work together in concert will suffer the worst when the client suddenly changes their mind about something fundamental 80% of the way to completion.  Billing systems, booking systems, CMS system, large-scale flash work, anything that requires carefully co-ordinated interaction with the user will suffer badly in this situation.

There are ways, however, of limiting or even avoiding spec-creep altogether.  In my experience the following techniques always seem to work well and will usually avoid embarrassing or confrontational situations down the road.

1. Project initiation is key:  Spend time taking a detailed brief from the client, write up meetings as soon as they've occurred an if you're not technical run any technical points past your dev team as soon as you can so they are aware of what was discussed.  Don't promise the client on things you're not sure about, try never to get pinned down on things where you don't know, this will always come back to haunt you.
2. Once you've taken your brief from the client and written it up and run it past your dev team, you should then put the brief as you understand it back to the client to check you've understood correctly, if there are any questions at all they should be asked and answers gleaned before you press on.  You should repeat this step as many times as you need to in order to get a clear understanding of what you are supposed to be building.
3. At this point, once you and the client are happy you have understood the brief you should work on the spec.  The spec should basically drop out of the brief at this point and should literally be a bullet-point document covering everything the brief does.  Ideally the spec should cover as many technical details of the project as possible including where necessary wireframes and detailing user interactions.
4. Once the spec is complete and both the client and yourself are happy with it, at this point you should provide a final quotation.  If you've provided a rough quote prior to this point you should have made it clear to the client that the final quote is subject to specification sign-off and that they should expect a final quote from you before you start work.  
5. Within the final quote you should make it clear what happens when something that is outside the specification is requested, how you will handle and charge for this situation.  If you charge and hourly rate, what it it?  If it is a grey-area in the spec then you should have contingency in your quote to deal with this where possible, how are disputes dealt with?
6. Taking part-payments is key.  Clearly defined milestones where you will expect to be paid for progress up to that point.  Believe it or not many clients actually like this because it frees them from having to pay a possibly huge lump sum at the end of the project.  Also, if they've already paid you some money, you are then contracted and it makes it more difficult for you to walk away from the job (at least from a moral standpoint).  It also effectively stops the "I'll pay when you've done x, y and z" carrot tactics that some clients use as, if you've done it right, your part payments should cover most of your project risk allowing you to bargain more effectively when things get bogged down.
7. During the build be flexible, but not too flexible.  The spec is there for a reason, its to tell you when you've finished the job.  If you stray too far from it then it becomes difficult to draw the line and get paid leading to a situation where you are forever chasing the end of the project.  If the client is asking for something to be changed which is fundamental to the project/spec then don't be afraid to simply say 'no' or suggest that it is pushed into a second project phase to be started after the end of the current development.  You don't have to be unreasonable, just simply remind them of what was previously agreed and stand your ground.  Many times the client will accept the situation and carry on as before.  
8. If the client is insistent on large deviations from the spec, then before you do the work, re-spec the project accordingly, re-quote for the work and be sure to work out a revised payment plan with the client.  Don't be afraid to talk about money, people like to know where they stand so there are no unexpected surprises.  Being clear at this point also prevents the "I thought this was included in the original quote" line which is a common get out clause for unscrupulous clients.  
9. If the client is reluctant to pay additional money then clearly break down why they need to pay extra, usually showing the client an hourly breakdown of hours of work for each spec item with clearly marked figures next to each one stops the debate going any further.  The client needs to know what they are paying you for so they can then judge whether they should be paying you more.
10. Thoroughly test your work before handing it over.  We've all done it, we're in a hurry, there's too much to do and not enough time and the client is pushing you for a progress update.  Sometimes holding your ground and reminding the client you want to provide them with a quality product so they should wait just a little longer is the best course of action.  Providing something half-broken will often cause you more grief later down the line and you'll be swamped with feedback on thing you already know don't work and the client will start loosing confidence in you.  Its better to be late but looking good, than on-time but in a total mess!  
11. Of course this may not be an option is some circumstances, especially when there is direct marketing or offline publicity riding on a job, in these cases you should try and agree specification revisions with the client and concentrate on providing a core product that works well, knocking off unnecessary bells and whistles where you can, and tackling them later when the pressure is off.

I've only just scratched the surface here, there are probably another 50 points I could add to the list.  But these ones cover a nice mix of how not to get in trouble, and what to do when you do get in trouble.  If I could boil it down to one piece of advice, it would be this:  Communicate with your client as much as you can, spec the project as much as you can, and hold your ground when under pressure.