Xref: utzoo comp.sw.components:312 comp.software-eng:2121 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ico!vail!rcd From: rcd@ico.ISC.COM (Dick Dunn) Newsgroups: comp.sw.components,comp.software-eng Subject: Re: Schedule and budget are secondary Summary: More probabilities (and more complexity) to consider Message-ID: <16188@vail.ICO.ISC.COM> Date: 10 Oct 89 23:52:32 GMT References: <6630@hubcap.clemson.edu> <16168@vail.ICO.ISC.COM> <1989Oct7.170247.17849@mrspoc.Transact.COM> Organization: Interactive Systems Corp, Boulder, CO Lines: 105 itkin@mrspoc.Transact.COM (Steven M. List) writes: >...In reading what Dick said, I can only believe that he's never worked on > a project for which someone ELSE was paying. Or a project for which the > market window is critical to the continued survival of the company or the > project or the product... You are quite wrong on both counts. I have worked on both for many years; currently most of my work falls into projects paid for by customers. I think it's not that we are in any fundamental disagreement (we'll see) so much as that we're driving at different points. > Dick's statements strike me as somewhat ivory tower. While those of us > who consider ourselves professionals in the field of "software engineering" > presumably ALWAYS strive for quality products, we can't just turn off our > systems and refuse if someone comes along and says "we have a deadline". Understood completely. I'm NOT trying to put quality at the very top of the list, to the exclusion of schedule and budget...but I want to get schedule/budget off the top of the list. One of the things we have to consider in bidding a software project is that we want to set a reasonable cost which will allow us to produce a product of sufficient quality that the customer is not only happy with it in the short-term (meeting the immediate needs) but in the long term when it comes time to modify it. If it's our own product, we don't want to do a quick hack that will save us 10% on the first release and cost us 50% more in the second release when we have to repair the damage we did by hurrying. Sometimes, market pressures are extreme enough that it's the only way to hit close enough to the market window that there can BE a second release--but we need to avoid that. > "How much can I get in that meets MY/OUR/OUR CUSTOMER'S standards > of quality within the time and budget constraints set forth? Can > we modify the constraints? Are we willing to adjust our standards?" This is a good statement. The software MUST meet its requirements, but that's a separate issue. We MUST schedule enough time and money to do that. Then we try to schedule enough to produce a product of sufficient quality that we won't hate ourselves for it later on. > Dick's statement that producing a schedule that meets a lower confidence > factor would permit a favorable decision is frightening to me. This > implies that it's okay to plan based on 80% or 70% or lower confidence. Sure--why not? Wait, let me qualify that...There are circumstances where it's OK to work at that confidence level. Just remember that nothing is black and white here. Suppose we're talking about a product aimed at a particular market window. What's the accuracy of the end date on the market window? Probably 50% at best! (That is, the window is at least as likely as not to close AFTER the estimated end date.) Also, the window doesn't just slam shut...it means that the longer you delay, the smaller your market share. You have to work with the probabilities involved. If there's a 70% chance you can make the stated market window, you also need to know something like what your 90%-confidence completion date is, and whether that might come in acceptably close to the window that it will still give you a good product--enough to make some money even if not as much as you "should" make. There are literally SCORES of other factors to consider. The better the condition of the company, the more of a gamble you can afford to take. You may build the company's reputation in a new technology area; you may gain expertise you need as a side-effect of the project. You have to look at the type of contract you're going to work with, if it's contract work. You can bid base cost plus T&M at a lower confidence level than fixed-price, which in turn can be lower than fixed-price-with- penalty-for-late, which is different from fixed-price-with-bonus-for-early, etc. to endless detail. Sometimes you don't even bid because the terms your customer wants don't fit with the amount of risk (which translates into level of confidence for a plausible schedule) for the project. > This implies that he is willing to proceed based on the assumption that > HE CANNOT SUCCEED in meeting time or budget constraints... No, it implies that I might be willing to proceed even with the knowledge that the desired (ideal) outcome is less than certain. But it involves lots of other considerations, per above, if you're going to go ahead from a lower confidence value. >...Dick - who's > funding you?... Our customers. >...What happens when the date for which you had 70% > confidence comes and goes? Who eats it?... If the project is begun at a low confidence level, there will be aspects of the contract which anticipate that. If an estimate carries a low confi- dence, that's taken into account. >...I would rather produce a > realistic project plan up front, including specifying the compromises, > than to produce a falsely optimistic plan with a qualifier ("this is > only 70% certain") and have to scramble to adjust near the end. It depends on what the curve of confidence level vs schedule looks like. All such curves have a tail asymptotic to 100%. With some, the shape of the tail heading out past 75% or so is unpleasantly long...that tells you that the project is riskier than average, and you have to decide whether you can live with the risk. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...No DOS. UNIX.