Semi-OT: Programming Question

[Zscoundrel]

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
>Kclug at kclug.org
>http://kclug.org/mailman/listinfo/kclug
>
>  
>

-- 
If you examine how Bill Gates funded research into solving the social issues he is concerned about in 2003, you would notice that he is 14 times more concerned about the global threat of Linux than he is about AIDS.