It is tough to identify these clients, but some of the tell-tale signs are, inability to identify specific features or needs, constant changes to requirements, a huge long laundry list of features that are loosely or completely unrelated to the core product, or unreasonably tight budget requirements.

The best way to control mission creep is to get the specs in writing before the first line of code is written and include steep fees for changes. I find that this usually takes 2 or 3 meetings to get things identified and get approval. Part of this approval is an agreement that they will not ask for changes on the fly unless they are willing to pay extra because it is a distraction from the original mission.

If they balk at this, suggest 2 or three review sessions during development where you can sit down with them and demo what you have so they can suggest changes. These reviews should alway be tied to payments so if the client changes their mind, at least you get paid up to that point.

Charles, Joshua Micah (UMKC-Student) wrote:

...

Beware the client who always changes the requirements... :)

Think there is a method of discovering such clients ahead of time? My experience so far has been that people with vague ideas of what they want are the worse. They don't know what they want, so you try to build what they describe, and as they see it forming, they can begin to define the end product. Creating an architecture that makes this possible in the least time consuming fashion seems to be the best route to me. _______________________________________________ Kclug mailing list [email protected] http://kclug.org/mailman/listinfo/kclug