>Most failing projects I encounter have problems not with tools or >coding as such but with: >- initial and continuing specification failure by the customer and analyst >- estimation error or unrealistic deadlines, with feeble risk >management [words highlighted in bright red] >- scope creep [words highlighted in red with clashing cymbals] both >in its natural form and feeding hungrily on the first two.
David, I can't thank you enough for you wonderful analysis. Every time I read about something like the California Dept. of Motor Vehicles abandoning an automated registration system after x years and $yM, I think, "give me this programmer, that programmer, and myself, and we could have done the whole job in six months [a manifestation of estimation error?], how is it with all those resources and all that money they had to give up?" I thought your entire analysis was right on except for one issue: scope creep. I think that some scope creep must be factored into original estimates. This is because I don't believe anyone can design any application of significance that won't show some design failures during real-world testing. I think initial specifications need to be viewed as general guidelines specifying desired functionality that are expected to evolve based on experience during testing. I recognize that undertaking a contract project makes it more necessary for specific specifications that when doing in-house development. In those instances I want the specifications as specific as possible; but the goal is to have a sound contractual basis when I come back and say "this and this are not in the original specs and will be billed separately". OTOH, I certainly suffer from the "let me just add this one new feature before I release this" syndrome. So I can see how this can get out of hand. Anyway, I tend to see scope creep as a natural result when people experience with the application design as implemented points out errors in judgement or approach, and as the users become more knowledgeable in computer capabilities & more involved in the design. It's the people who were not forthcoming during the initial design stage that always seem to complain the most when they see the final design. My guess is the leading cause of project failure--and this applies to small projects as well as large--is specification (communication?) failure between customer & analyst. After years of being told "this will never happen" and programming accordingly, only to later be told "I know we told you this would never happen, but..." (and that's from the "good" clients, the others say "No one here would ever have told you that...", and I write them off as long-term clients); after years of having someone spend hours drafting a sample report format & me spend some time programming it only to have them take one look at the output and "this isn't really what I want.."; after years of saying "I know there is a better way to do this, but that's how the specs read; so I'd better follow them..." only to later find myself down some dead end or otherwise having to implement the design I knew was right in the first place; and after other real-world experience of that ilk, I have come to see scope creep as the inevitable result of imperfections in the design process, and as a necessary part of the implementation of an application adjusted to accommodate the realities of user interaction. -- Rob Cozens CCW, Serendipity Software Company http://www.oenolog.com/who.htm "And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee." from "The Triple Foole" by John Donne (1572-1631) _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
