Michael Stevens <[EMAIL PROTECTED]> writes:
> On Mon, Jan 22, 2001 at 10:26:18AM +0000, James O'Sullivan wrote:
> > 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.
> > >
> >
> > All changes no matter how small should be passed through a change control
> > process, normally put in place by the project manager assigned to that
> > specific job.
> >
> > A change control document will normally be produced which will detail what
> > the client wants, how much it will cost and what the effects are on the
> > project timeline. This will need to be read and physically signed off by
> > the client before any work is undertaken.
>
> a) you need to be able to persuade management this is a good idea
>
> b) you need to get someone writing specs who is actually able to be specific.
> And you need to have some way of dealing with a client who will
> refuse to pay until you implement something that they say is
> contained within the spec, and you don't. Despite the fact you're
> both reading the same spec.
Keep the specs/stories simple. If the team is unsure of what a story
means then they need to go back to the client for clarification, and
possibly to have the requirement broken down into simpler bits. As
time passes in the project, the client will get better at writing
requirements. And we'll get better at estimating how long they'll take
to implement.
--
Piers
