This is all valid and good advise, but there's another option, too, which should not be overlooked. That is to cut scope creep off at the pass. Hit it as early as possible, before expectations are set and estimates are made. The way to do that is to deeply understand your client (internal or external, whatever) and your client's goals. Don't let someone hand you a spec or a list of feature requirements without understanding what is behind them. This is an incredibly important and worthwhile investment of time.

If you understand what your client is ultimately wanting to achieving, you will see (much of) the scope creep before they do. Also, and perhaps more importantly, if you cannot understand what they ultimately want (not what software or features they want, but what results they want), then there are several potential problems awaiting you. Not the least of which is potential miscommunication and the need for late course correction (which often programmers incorrectly call "scope creep", but is frankly their own misunderstandings coming out late). But perhaps the greatest danger of failing to understand the ultimate needs of your clients is this: If you do not really understand what they ultimately want out of the project, then you don't know whether they really understand what they want. And a client who doesn't really understand why (s)he wants something is one of the surest ways to an unsuccessful project and tons of scope creep.

But definitely not a contradiction to your points, just an addition for the record.

If you understand what your client is ultimately wanting to achieving, you will see (much of) the scope creep before they do.

When you start thinking that you're smarter than your client, and that you can know what they want before they do, you're on very dangerous ground. You may be right much of the time, but when you're wrong you can find yourself down a deep hole.

If you do not really understand what they ultimately want out of the project, then you don't know whether they really understand what they want.

You avoid this trap by showing your client working software at frequent intervals, and by asking "Is this right? Is this what you meant?", letting them clarify, change their minds, let you know about new requirements, or smile and nod. You both gain understanding and trust incrementally.

I'm rather shocked at how rarely I see one phase of software development that I was taught: Needs analysis. If I'm working on an important project, I don't just take a spec that is handed to me; I study the needs of the client / customer and analyse them. The needs often start out as a spec. But, in my experience, if the client is savvy enough to get the spec right, then they don't usually go contracting the work out.

Most of the mistakes I've made in contracts is when I've let the client dictate what was to be done without analysing whether that really made sense and pushing back quite hard with what my analysis says should be done. If the client disagrees, then I need to work to find out whether I'm missing part of the picture or the client is.

There can be differences of opinion as to how to do something, and often the client gets to dictate those since they are paying (but sometimes I get to dictate them since I'm the expert being hired and so should know what I'm doing). But if there is a disconnect as to what is needed, then the project is going to go quite badly.

And the most common way I've seen for the needs analysis to be done wrong (other than "not at all") is for the person doing the design to not talk to the ultimate consumers of the proposed work. Talking to the boss who is going to pay you is just the first step. You need to talk to the peons doing the work and see how they really do things and discuss how they'd use what you are considering writing.

So, yes, I usually know what the client needs better than any one of them does once I've taken on a project. I may not know what they want better than they do, but I don't care as much about that so long as the paperwork is clear -- since I've experienced giving them what they want but didn't need and found that to be much worse for all involved than giving them what they need but didn't think they wanted that was also what was spelled out in the contract (which prevents them from easily dismissing the work which gives them time to realize that they did need it -- usually soon after they give it to their peons).

Of course, I make an effort to understand what they want and to explain what they'll be getting. Proper expectations make things go so much more smoothly. But wants are harder to pin down than needs and specifications, so I try harder to make sure the latter line up. You can do a lot to verify needs and specifications but for "wants" you are stuck with how well they can communicate what is in their head.

If I ever ask a client "Is this what you meant?" that's a red flag that I'm nearly driving blind.

When you start thinking that you're smarter than your client, and that you can know what they want before they do, you're on very dangerous ground.

Well, that's not what I said. You're right: it's dangerous (and basically always wrong, for all intents and purposes) to think that you are smarter than your clients. But that doesn't mean you should assume that they are smarter than you. What I meant to describe was more of a partnership. They are going to know the subject matter better than you. That's basically a given. You are going to know how to develop software better than them. That is also a given.

That's the point, really... if you get into the business of letting your clients design your (as in your and theirs, remember: it's a partnership) software, alone, with you as a passive requirements-to-code translator, that's where the problems start. When saying that you will see the scope creep coming before they do, what I mean is: you have experience developing software, and they don't. If you really understand what the client wants, and you have any experience with similar situations, then this will give you a heads-up to potential issues. Use that forewarning of danger as an opportunity to avoid it. When you encounter those watch-signs, ask questions that the client never bothered to give you the answers for in advance (because they, lacking your experience at software development, will not have thought of all the potential issues).

I think etcshadow (and tye too) you are right, if you have done all your analysis right, and have been in this business for long enough, you should surely be able too see the scope creap coming. This in no way implies anyone is smarter than the other, just that you have deep battle scars :)

Now one point which has not been touched on here is the politics of scope creep. I work for a small consultancy (we are down to 3 full time and a number of regular freelancers), and we do the majority of our work for one client, with whom we have had a relationship with for almost 10 years (predating the formation of the company actually). Our relationship with them is more along the lines of a partnership, rather than a contractor-contractee relationship. This basically implies much more give and take, since we want long term, not short term business from them.

I have found many times when small-to-medium-small scope creep comes up early in the project (after the coding has started, but before the "point of no return"). It is politically best to let it happen, all the while making sure they know that it is scope creep, and that you are willing to let it happen. The reason I say this is two-fold.

First, we as developers need to be flexible. In this modern era, users demand flexible and feature-full applications which can not only meet their current needs, but anticipate and meet their future needs. Now, nine times out of ten, that is impossible to do, but the best we can do is be flexible during the early stages, since the "design and discovery" phase is likely not not catch everything. If the client perceives you as being flexible and accomidating (but not just being a doormat), then you are that much more likely to get a call from them for the next project.

Second, like a squirrel storing up nuts for the winter, it is useful to build up some political clout early on in the project, as you might just need it later on down the road. Again, I do not in any way advodate abusing situations for political gain *. A client which perceives you to be flexible early on, will know that when you are waving your contract and saying "scope creep" later on, it is not because you are stubborn or a nay-sayer. That early flexibility will illustrate your commitment to the success of the project, and give you a platform from which to talk about adjusting priorities.

And of course, if your client is not being reasonable, and are pushing you to "just do it". They are clearly trying to take advantage of you, and you should act appropriately. And no matter how many times they bought you a beer when you were hanging out after work, or how many times you compared stories about your kids over lunch, when it comes to business, they are not and cannot be your friends. Business is business, and that is just how it has to be. If they try to drag friendship into it, then be wary.

* - I spent many a year working in the advertsing business where back-stabbing politics is just how things work, and I absolutely despised it. But, politics are there, they cannot and should not be ignored (even as a contractor, they may not directly affect you, but you need to be aware of their impact on your work).

This is all valid and good advise, but there's another option, too, which should not be overlooked. That is to cut scope creep off at the pass.

And when that scope creep comes from a federal bureaucracy regulation which requires you to do whatever a career bureaucrat with full power and no responsibility decides? And that decision changes without warning (and even notice) at rapid and irregular intervals?

Don't get me wrong, I agree with what you say, but when the first step of a process is random ravings of a bureaucratic mind, it's brown trouser time.