>===== Original Message From "James O'Sullivan"
<[EMAIL PROTECTED]>
=====
>On Mon, 22 Jan 2001, Michael Stevens wrote:
>> On Mon, Jan 22, 2001 at 08:47:35AM +0000, Roger Burton West wrote:
>> > Contracts _should_ say that the client pays for changes to what he
>> > originally said he wanted. Sometimes they do. It's quite rare, in my
>> > experience, for this payment actually to be demanded. (Usually some
>> > excuse along the lines of "it's a big customer and we don't want to
>> > annoy them".) This XP approach seems to require a lot more firmness
>> >
>> I've also found a lot of customers are absolute *geniuses* at fudging the
>> issue of what they did and didn't agree to, no matter how specific
>> you attempt to be.
>>
>This, in theory, should make the client think whether they really need
>this "small change" or if it can wait until a later date. It also gives
>you some ammo if the client changes their mind as there should be no
>ambiguity.
>
Apologies if I'm walking in late on this one...
One of the best solutions I've come accross to this problem is to take an
iterative approach to development. Instead of a three month deadline, you work
towards three one month deadlines. the client prioritises at each stage what
is
most important for them, along with the developers; then you work to the
deadline, and slip functionality (rather than time). Any things that are
missing
are then rolled into the next iteration, and again prioritised along with any
new functionality the client feels they need.
This has the benefit that you generally meet deadlines, and the client is much
more aware of what is going on. Generally they will also have agreed to what
has
and hasn't happened, and they don't suddenly turn around and scream 'waht the
hell is this', as they have watched and been involved in the development
process.
easy!
Dave
-----------------------
SKI FOR FREE!!! For every passenger that travels another goes free.
http://www.thefirstresort.com/index.asp?linkfrom=tot1
