Dave Mee <[EMAIL PROTECTED]> writes:
> >===== 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 is an XP thing. And it is good. Specs change. This is a law of
nature. If you plan up front for that to happen then you reduce the
cost of change dramatically.
--
Piers
