home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / misc / jobs / contract / 4617 < prev    next >
Encoding:
Internet Message Format  |  1992-12-23  |  2.5 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!spool.mu.edu!olivea!gossip.pyramid.com!pyramid!infmx!cshaver
  2. From: cshaver@informix.com (Craig Shaver)
  3. Newsgroups: misc.jobs.contract
  4. Subject: Re: contract payment methods question
  5. Message-ID: <1992Dec18.013644.8145@informix.com>
  6. Date: 18 Dec 92 01:36:44 GMT
  7. References: <1992Dec14.220237.244@netcom.com> <bobert.724629938@godzilla>
  8. Sender: news@informix.com (Usenet News)
  9. Organization: Informix Software, Inc.
  10. Lines: 40
  11.  
  12. In article <bobert.724629938@godzilla> bobert@informix.com (Robert Murphy) writes:
  13. ................
  14. .....
  15. >
  16. >Speaking of this kind of thing, my partner and I are having a problem which
  17. >perhaps somebody here has an answer for.  We're working on a project
  18. >which is basically to write an interface layer so that the client's
  19. >proprietary library code can be called from an Windows Excel spreadsheet.
  20. >These libraries had previously been ported to Lotus 123 for DOS and Unix,
  21. >and Wingz for the Sun, and also sold as independent libraries, so we
  22. >assumed they'd been thoroughly tested... heh heh...
  23. >
  24. >Well, over 80% of the bugs that have been reported against our project
  25. >have turned out to be in the client's libraries.  Fixing these libraries
  26. >is both outside the scope of the contract and far outside our expertise.
  27. >I'd guess we've spent an aggregate of 2-3 man-weeks on these bugs, and
  28. >the whole project was only supposed to take 2-3 man-weeks.  I can also
  29. >honestly say that there was no way at the beginning of the project that
  30. >we could have expected this kind of overrun.
  31. >
  32. >Right now, we're just eating the extra time.  In the future, though, what
  33. >should we do?  Should we build an automatic price increase into our
  34. >contracts for extra work caused by client screw-ups?  Are there other,
  35. >better ways of dealing with this sort of thing?
  36. >
  37. >Bob Murphy
  38. >
  39.  
  40. You should anticipate client related problems.  Break the job into parts
  41. and be specific about what you are going to deliver.  You should be able
  42. to just deliver a finished interface library with minimal testing.  The 
  43. contract should be broken into building the library and then specific
  44. amounts of testing.  You may have under bid at 2-3 weeks by the way.
  45.  
  46. I saw something similar recently involving a c++ class lib.  The testing
  47. was to go so far as to point out bugs but not to fix them.
  48.  
  49. -- 
  50. Craig Shaver  (cshaver@informix.com for now) (415)390-0654 (415)926-6407
  51. Productivity Group POB 60458 Sunnyvale, CA  94088
  52.