gbeary@uswat.uswest.com (Greg Beary) (02/05/91)
In the January '91 issue of IEEE's Software magazine, Barry Boehm has an interesting article on Risk Management. He makes very brief mention of a technique called "design to cost". If anyone is familiar with additional information on this technique/process/lifecycle I'd appreciate it. We're having some difficulties in that we are trying to apply "normal software business" lifecycles to in-house development. What happens is that a internal client has the concept for a product. They "pitch" the idea to a funding board. The funding board allocates $x to use to build the product. We now begin to gather detailed requirements, estimate the effort- $y, and architect the product. In no case has $x >= $y. What your are left with is a client that never has the dollars for the functinality they want and a development organization that always "comes up short" in the eyes of the client. I believe this is due to applying a build-to-suit lifecycle to what essentially is a build-to-cost situation. It's rather like hiring a taxi driver in California, telling them you want to go to New York, and oh by the way... I only have $100 to give you for gas. The driver can either refuse your offer, drive you as far as $100 goes, or hope that when they have you in god-knows-where Nebraska - you'll "find" some more money to get yourself out of there. Does anyone have a description of a Lifecycle or process that addresses this type of situation? The Spiral model is lots closer to this approach than the normal waterfall, but not really a total fit. Thanks, Greg Beary -- Greg Beary | (303)889-7935 US West Advanced Technology | gbeary@uswest.com 6200 S. Quebec St. | Englewood, CO 80111 |
pcooper@eecs.wsu.edu (Phil Cooper - CS495) (02/06/91)
In article <15038@uswat.UUCP> gbeary@uswat.uswest.com (Greg Beary) writes: > >We're having some difficulties in that we are trying to apply "normal >software business" lifecycles to in-house development. What happens is >that a internal client has the concept for a product. They "pitch" the >idea to a funding board. The funding board allocates $x to use to build >the product. We now begin to gather detailed requirements, estimate the >effort- $y, and architect the product. In no case has $x >= $y. What >your are left with is a client that never has the dollars for the >functinality they want and a development organization that always "comes >up short" in the eyes of the client. > Forgive my ignorance, but how in the world can your funding board allocate a sum of money for a particular software development effort before any requirements are known or estimation done? I don't see how they could possibly hope to be accurate in their forecast of the cost of the project. It seems to me that if the in-house client wants a particular software application developed badly enough, they can foot the bill for at least a preliminary estimation of the scope and cost before requesting funding from the board. Just $.02 worth from a future (hopefully) software engineer. Phil Cooper
heron@mars.jpl.nasa.gov (Vance Heron) (02/12/91)
In article <1991Feb06.102233.19301@eecs.wsu.edu> pcooper@yoda.UUCP (Phil Cooper - CS495) writes: > Forgive my ignorance, but how in the world can your funding board >allocate a sum of money for a particular software development effort >before any requirements are known or estimation done? By figuring what the finished product will be worth to the organization - if it will cost $1M to develop software that will make/save the company $100/year, the $1M wont be allocated (most of the time) Vance
alan@tivoli.UUCP (Alan R. Weiss) (02/14/91)
In article <1991Feb06.102233.19301@eecs.wsu.edu> pcooper@yoda.UUCP (Phil Cooper - CS495) writes: >In article <15038@uswat.UUCP> gbeary@uswat.uswest.com (Greg Beary) writes: >> >>We're having some difficulties in that we are trying to apply "normal >>software business" lifecycles to in-house development. What happens is >>that a internal client has the concept for a product. They "pitch" the >>idea to a funding board. The funding board allocates $x to use to build >>the product. We now begin to gather detailed requirements, estimate the >>effort- $y, and architect the product. In no case has $x >= $y. What >>your are left with is a client that never has the dollars for the >>functinality they want and a development organization that always "comes >>up short" in the eyes of the client. >> > > Forgive my ignorance, but how in the world can your funding board >allocate a sum of money for a particular software development effort >before any requirements are known or estimation done? I don't see how >they could possibly hope to be accurate in their forecast of the cost >of the project. It seems to me that if the in-house client wants a >particular software application developed badly enough, they can foot the >bill for at least a preliminary estimation of the scope and cost before >requesting funding from the board. Just $.02 worth from a future >(hopefully) software engineer. > >Phil Cooper Right. In large corporations such as Unisys and IBM with formal process models (Phase Review and Plan of Record, respectively), little experiements are often funded during Phase 0 and Phase 1 without a lot of paperwork. At some predefined point, a "stake in the ground" is planted and the experimenter has to bring their project under the process. In doing so, they have to justify the project and request additional funds. This can occur at the exit of Phase 1 (Requirements) or Phase 2 (Specifications). Phase 3 is Development, Phase 4 is QA and Manufacturing, Phase 5 is Support, Phase 6 is Death (this is from Unisys' process, which was lifted, er, gleaned from IBM's process). I am supportative of internal customer-supplier types of business models, or even internal market structures such as capital funding and transfer pricing schemes. However, I have yet to have heard of any software development organization who has employed internal markets successfully. Anyone else in net.land? _______________________________________________________________________ Alan R. Weiss TIVOLI Systems, Inc. E-mail: alan@tivoli.com 6034 West Courtyard Drive, E-mail: alan@whitney.tivoli.com Suite 210 Voice : (512) 794-9070 Austin, Texas USA 78730 Fax : (512) 794-0623 _______________________________________________________________________ "Quality is never an accident. It is always the result of high intention, sincere effort, intelligent direction, and skillful execution. It represents the wise choice of many alternatives."
johnb@srchtec.uucp (John Baldwin) (02/14/91)
In article <1991Feb11.203134.24438@jato.jpl.nasa.gov> heron@mars.UUCP (Vance Heron) writes: + > Forgive my ignorance, but how in the world can your funding board + >allocate a sum of money for a particular software development effort + >before any requirements are known or estimation done? + By figuring what the finished product will be worth to the organization - + if it will cost $1M to develop software that will make/save the company + $100/year, the $1M wont be allocated (most of the time) It sounds like his organization needs a tighter "feedback loop" in the implementation stage, or maybe even earlier. As Mr. Heron mentioned, it's unwise to invest money you can never recoup --- so it really doesn't make sense to me why they even let a group go ahead and start developing something without knowing whether or not they can achieve their objective within the specified cost constraints. -- John Baldwin | johnb@searchtech.com Search Technology, Inc. | srchtec!johnb@gatech.edu Atlanta, Georgia | johnb%srchtec.uucp@mathcs.emory.edu
mcgregor@hemlock.Atherton.COM (Scott McGregor) (02/20/91)
In article <1991Feb14.142129.26230@srchtec.uucp>, johnb@srchtec.uucp (John Baldwin) writes: > It sounds like his organization needs a tighter "feedback loop" in > the implementation stage, or maybe even earlier. As Mr. Heron mentioned, > it's unwise to invest money you can never recoup --- so it really doesn't > make sense to me why they even let a group go ahead and start developing > something without knowing whether or not they can achieve their objective ^^^^^^^ Fore-knowledge of the future is a rare talent. For many individuals and companies, an educated belief about the future is the best that can be hoped for. Often the proposed developers claim that they can do it when they start, and because they are presumed to be knowledgable about what they do, their estimates are trusted. Often, to have enough knowledge of the discipline to give a counter argument, you are probably beneficial to the company in the development organization itself--in which case the estimate will be based on your input in the first place. The knowledge of success or failure in meeting the cost constraints doesn't really occur until development is done. > within the specified cost constraints. --Scott McGregor Atherton Technology mcgregor@atherton.com