home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / bit / listserv / ibmmain / 3085 < prev    next >
Encoding:
Text File  |  1993-01-25  |  2.7 KB  |  52 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!gatech!udel!darwin.sura.net!paladin.american.edu!auvm!UCSFVM.BITNET!EJR9006
  3. Message-ID: <IBM-MAIN%93012517151371@RICEVM1.RICE.EDU>
  4. Newsgroups: bit.listserv.ibm-main
  5. Date:         Mon, 25 Jan 1993 15:05:22 PST
  6. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  7. From:         Ed Rovera <EJR9006@UCSFVM.BITNET>
  8. Subject:      Product Acquisition/Evaluation
  9. Lines: 41
  10.  
  11.    Someone here has asked our technical advisory group to develop a
  12. process for evaluating proposed products prior to their purchase.  The
  13. object here is to have a set of 'canned' steps that would be gone
  14. through to set up the specifications for a product or group of
  15. products.  In the past, products were purchased or developed based
  16. upon a task force's recommendations and each task force was supposed
  17. to develop their evaluation criteria as they saw fit, depending upon
  18. what they were looking at.  Now, some people want to see if a more
  19. structured approach to this can be developed so there will be
  20. something for a task force to use as a jumping off point.
  21.  
  22.    I envision this as starting out with what I will call the "General
  23. Specifications," or what we want whatever we buy to accomplish in very
  24. basic terms.  This might be nothing more than a glorified wish list
  25. but will cover what we want to accomplish.  Then, a set of "Functional
  26. Specifications," or *how* we need this to be done would follow this
  27. and contain such aspects as existing (i.e., related) products and
  28. procedures, operating system dependencies, etc., and probably
  29. information on possible future directions we might be taking in that
  30. area.  For example, a bullet on this list might be: "Contact Systems
  31. for current release of MVS, complete with PTF level of DFP" or:
  32. "Subsystem dependencies -- DB2 v.r.m." I suspect that some variation
  33. of the "Functional Specifications" might be given to a potential
  34. vendor as the equivalent of an RFP, too.
  35.  
  36.    For those who already have such product evaluation procedures in
  37. place, am I on the right track with my thinking or am I 180 degrees
  38. here?  If I'm heading into the rough, what am I missing?  What aspects
  39. of product acquisition/evaluation should be included in such a
  40. document?  Maybe I should ask an even more basic question: Does anyone
  41. have anything like what I'm describing that they'd be willing to
  42. share?
  43.  
  44.    Thank you.
  45.  
  46.                                       - Ed Rovera
  47.                                          UCSF ITS Division
  48.                                          415-476-3119
  49.                                         Internet: EJR9006@UCSFVM.ucsf.edu
  50.                                         Bitnet:   EJR9006@UCSFVM
  51.                                         IBMMAIL:  USUCACN5 at IBMMAIL
  52.