home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / sci / econ / 9605 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  1.9 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!wupost!csus.edu!netcom.com!erc
  2. From: erc@netcom.com (Eric Smith)
  3. Newsgroups: sci.econ
  4. Subject: Re: "Death of America"
  5. Message-ID: <1993Jan8.191820.24824@netcom.com>
  6. Date: 8 Jan 93 19:18:20 GMT
  7. References: <thompson.726422768@daphne.socsci.umn.edu> <1993Jan8.010630.25706@inel.gov> <canright.726514882@convex.com>
  8. Organization: Netcom - Online Communication Services (408 241-9760 guest)
  9. Lines: 26
  10.  
  11. In article <canright.726514882@convex.com> canright@convex.com (Robert Canright) writes:
  12. >Come on now, confess!  The inability to predict software projects in a
  13. >business setting is really a matter of being unwilling to confess the true
  14. >cost!  Get management a little pregnant & they've got to let the project
  15. >come to full term, right?  This is especially true in govenment/military
  16. >environments.
  17.  
  18.  
  19. The inability to predict software projects is caused by the fact that there
  20. are unknown factors which can't be taken into account until they are known.
  21. The best honest estimates have a very large stated error tolerance.  For
  22. example, we could say a particular project has a 95% probability of taking
  23. less than one year, and a 25% probability of taking less than one month.
  24. There is nothing flippant or lazy about such an estimate, because it's
  25. really the best honest estimate for a project of that size.
  26.  
  27. The real problem is that managers tend to feel very insecure with such
  28. estimates, and tend to insist on more precision.  But if the person making
  29. the estimate gives a worst case estimate to be safe, the manager thinks
  30. it is extravagant padding motivated by the fact that the person giving
  31. the estimate has nothing to lose from wasting time.  So, what usually
  32. happens in a case like that is that the 25% probability of completing the
  33. project in one month becomes a one-month estimate, period.
  34.  
  35. Thus, using those figures, 75% of all software projects like that would
  36. tend to be late.  Sometimes as much as 1100% late.
  37.