home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / software / 4394 < prev    next >
Encoding:
Text File  |  1992-11-18  |  3.0 KB  |  66 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!sun-barr!cs.utexas.edu!wupost!csus.edu!netcom.com!mcgregor
  3. From: mcgregor@netcom.com (Scott Mcgregor)
  4. Subject: Re: Estimating Large S/W Development Efforts
  5. Message-ID: <1992Nov19.042450.8419@netcom.com>
  6. Organization: Netcom - Online Communication Services (408 241-9760 guest)
  7. References: <1992Nov18.173255.3827@den.mmc.com>
  8. Distribution: usa
  9. Date: Thu, 19 Nov 1992 04:24:50 GMT
  10. Lines: 54
  11.  
  12. In article <1992Nov18.173255.3827@den.mmc.com> carnahan@possum.den.mmc.com (Rich Carnahan) writes:
  13. >Anyone had any *real* success estimating large (>1M LOC) s/W development
  14. >efforts?  I'm interested in hearing about any creative (sic) techniques.
  15. >
  16.  
  17. First of all, I would point out that *real success* in estimating
  18. large software projects should be measured in the same way that large
  19. civil engineering projects are.  Such projects often are successfully
  20. estimated to withing 50% of the mean cost and times.  But large civil
  21. engineering companies build in plenty of safety error to ensure that
  22. the projcts will still be profitable in a worst case scenario.
  23. Software people often fail to do the latter even though they might
  24. successfully estimate means and variances just as well.
  25.  
  26. Second of all, the collection of projects that I have looked at
  27. suggests that the very best predictor of project duration is the
  28. previous project done predominantly by the same organization,
  29. management or individuals.  If an organization has never done a
  30. project of that size before, historical evidence suggests that they
  31. won't finish it this time either--the project will be cancelled before
  32. it is completed.  The primary reason this seems to be so is that
  33. projects are more constrained by the EXPECTATIONS of the participants,
  34. which in turn are molded by past experience, than they are by things
  35. like lines of code, functionality or complexity.
  36.  
  37. The evidence seems to show that the only way to "break the cycle of
  38. expectations" is to bring in a new manager or team.  And this is only
  39. successful at a greater risk of conflict between the unchanged parts
  40. of the organization.  In other words, bringing in a new project
  41. manager might allow the organization to do a longer project that such
  42. a manager has experience with, but the organization does not.  But it
  43. may set that manager in conflict with more senior managers who fear
  44. that such a longer project can never succeed.  And it may set that
  45. project manager at odds with senior developers who work for the
  46. manager but who suspect that senior management will eventually pull
  47. the plug--and so they do things the old way as a personal safety
  48. valve.  If the project manager successfully avoids these twin shoals
  49. the project is most likely to complete on a schedule like their past
  50. projects. Otherwise the most likely result is cancellation when the
  51. project exceeds the organizations historical norms.
  52.  
  53. If anyone has data which illustrates different results, I would like
  54. to see it.
  55.  
  56. -- 
  57.  
  58. Scott L. McGregor        mcgregor@netcom.com
  59. President            tel: 408-985-1824
  60. Prescient Software, Inc.    fax: 408-985-1936
  61. 3494 Yuba Avenue
  62. San Jose, CA 95117-2967
  63.  
  64.  
  65.  
  66.