I believe that an important key to controlling scope creep is persistent documentation. I have found that if I can point at a piece of paper and just remind the customer that s/he said (or did not say) they needed a particular feature, then the may reconsider their new request. Granted that this doesn't always work, and must be done in a tasteful and tactful way to work, it seems to help more often than not.
Also, it is helpful to define the contract into distinct segments. I used to use 15%, 35%, 75%, 100%, FINAL. 15% is simply the initial mockup. Customer reviews this for scope adherence and also might ask for scope changes, which are then negotiated before proceeding. 35% is the revised mockup, where the customer comments have been incorporated (or evaluated to 'not feasible'). Customer reviews this for revised scope adherence. Can't add new scope items, just point out deficiencies and defects. Any scope added after this point goes into specifications for the next revision (not in contract) of the application. 75% is the revised mockup + any corrected customer comments. This is more or less just a progress review. Pick up the minor interaface bugs (code bugs should never be seen by the customer) 100% means a complete application, performing fully to the 35% scope and specifications and should be ready for immediate release to public. Customer reviews this one carefully, making sure that everything works as scoped out. This should be just a go/no-go. FINAL is the packaged / installed application. ----- Original Message ----- From: "Ian Lurie" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Thursday, March 14, 2002 8:03 AM Subject: RE: Fusebox pros and cons > Yup. That works. But it still ticks off the clients. > > If everyone was reasonable we wouldn't need governments, I guess... > > -----Original Message----- > From: Christopher Olive [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 14, 2002 8:02 AM > To: CF-Talk > Subject: RE: Fusebox pros and cons > > > that's the point of having an appendix b in your contract, with this sort of > thing specified. > > the clause in the contract referencing said appendix shoul dhave something > along the lines of "if Client requests more, this is my/our fee for changes, > per hour." > > then jack the hourly rate up REAL high. if they want it that bad, they'll > pay for it. > > christopher olive > cto, vp of web development, vp it security > atnet solutions, inc. > 410.931.4092 > http://www.atnetsolutions.com > > > -----Original Message----- > From: Jeffry Houser [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 14, 2002 10:49 AM > To: CF-Talk > Subject: RE: Fusebox pros and cons > > > Bingo, that is correct. > As an example: > "I want a one-time rating system. I really want to capture the user's > first impression without them being able to change it." > [create a one time rating system] > "What if the user wants to change there rating? It does happen." > > At 08:04 AM 3/14/2002 -0600, you wrote: > >I think he meant that clients often expand and dilute development > >methodology by adding features and functions to an application after the > dev > >plan is locked down... you know, your client comes in during the beta and > >says ".... hey you know I was thinking, what if we......". Personally, the > >best ideas I've ever had have come from clients <g> - so I don't resent it. > > > >-----Original Message----- > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > >Sent: Thursday, March 14, 2002 8:56 AM > >To: CF-Talk > >Subject: RE: Fusebox pros and cons > > > > > >not being contradictory here but, > > > >how does too much client envolment hinder a well written application? most > >of the clients i've worked with don't have the CF skillset in the > >organization so I've been able to keep everything pretty clean, as our > >individual interpretations of "clean" go. I would think that our service > >is applying technology to business rules. if they, the consumers, don't > >know the tech., how can they have destructive input? > > > >possibly just lucky w/ the clients i've had?...savan > > > > > > > > > >Jeffry Houser <[EMAIL PROTECTED]> on 03/13/2002 07:05:04 PM > > > >Please respond to [EMAIL PROTECTED] > > > >To: CF-Talk <[EMAIL PROTECTED]> > >cc: > > > >Subject: RE: Fusebox pros and cons > > > > > > I think he meant Daves. > > There is usually too much client involvement for a well written > >applications to exist. It is the curse of being the service industry. > > > >At 04:24 PM 3/13/2002 -0600, you wrote: > > >What? well written applications? Or Daves? > > > > > >-----Original Message----- > > >From: Cary Gordon [mailto:[EMAIL PROTECTED]] > > >Sent: Wednesday, March 13, 2002 11:31 AM > > >To: CF-Talk > > >Subject: RE: Fusebox pros and cons > > > > > > > > >Based on his contributions to this list, I'd guess that there are about a > > >dozen... > > > > > >At 09:11 AM 3/12/2002 -0800, you wrote: > > >--- snip --- > > > >it is > > > >true that any well written CF Application should be logical and > >structured > > > >but there aren't that many Dave Watt's et al in the real CF World, My > > > >sixpence worth. > > > > > > > >Mike Brunt > > > >Sempra Energy > > > >213.244.5226 > > > > > > > > > > > > > > > > > > ______________________________________________________________________ Why Share? Dedicated Win 2000 Server · PIII 800 / 256 MB RAM / 40 GB HD / 20 GB MO/XFER Instant Activation · $99/Month · Free Setup http://www.pennyhost.com/redirect.cfm?adcode=coldfusionc FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
