How to Develop Effective RFPs

  • Published on
    24-Mar-2017

  • View
    215

  • Download
    1

Transcript

  • This article was downloaded by: [Cornell University Library]On: 19 November 2014, At: 02:15Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House,37-41 Mortimer Street, London W1T 3JH, UK

    Journal of Information Systems ManagementPublication details, including instructions for authors and subscription information:http://www.tandfonline.com/loi/uism19

    How to Develop Effective RFPsJohn A. Guerrieri Jr.Published online: 31 May 2007.

    To cite this article: John A. Guerrieri Jr. (1984) How to Develop Effective RFPs, Journal of Information Systems Management,1:4, 40-47, DOI: 10.1080/07399018408963060

    To link to this article: http://dx.doi.org/10.1080/07399018408963060

    PLEASE SCROLL DOWN FOR ARTICLE

    Taylor & Francis makes every effort to ensure the accuracy of all the information (the Content) contained in thepublications on our platform. However, Taylor & Francis, our agents, and our licensors make no representationsor warranties whatsoever as to the accuracy, completeness, or suitability for any purpose of the Content. Anyopinions and views expressed in this publication are the opinions and views of the authors, and are not theviews of or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon and should beindependently verified with primary sources of information. Taylor and Francis shall not be liable for any losses,actions, claims, proceedings, demands, costs, expenses, damages, and other liabilities whatsoever or howsoevercaused arising directly or indirectly in connection with, in relation to or arising out of the use of the Content.

    This article may be used for research, teaching, and private study purposes. Any substantial or systematicreproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in anyform to anyone is expressly forbidden. Terms & Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions

    http://www.tandfonline.com/loi/uism19http://www.tandfonline.com/action/showCitFormats?doi=10.1080/07399018408963060http://dx.doi.org/10.1080/07399018408963060http://www.tandfonline.com/page/terms-and-conditionshttp://www.tandfonline.com/page/terms-and-conditions

  • How to Develop Effective RFPs- John A. Guerrieri, Jr.

    The goals of computer vendors and the users they senlice are often incompatible. And unfortunately, vendors are usually more skilled and experienced in selling computers than users are in purchasing a system that meets their requirements. A request for proposal (RFP), however, shifts control of system selection to the user.

    Hardware and software acquisition generally requirements that can alter the effectiveness of plays an important role in the support of critical the eventual solution. When users convey their organizational functions and future productivi- needs only to a sales representative, important ty. Many organizations, however, approach requirements might be overlooked until it is too comDuter purchases with a level of informality late. that 'would not be tolerated with other capital acquisitions. This casual method of systems se- lection seems to contradict the widespread awareness that computer systems often do not perform as expected or required. The problems associated with system selection (particularly with initial or infrequent purchases) do not oc- cur, however, with most other equipment. The extensive, complex, and unique tasks that a computer system is expected to perform often make it difficult for users to communicate their precise expectations and requirements to ven- dors. The user may forget to mention specific

    John A. Guerrieri, Jr.. COP, is an information systems consultant, Niles II.

    A second' problem occurs because vendors are primarily interested in selling systems and therefore may be somewhat unwilling to ad- dress user requirements that are not advanta- geous to their products or services. If user re- quirements cannot be thoroughly satisfied by a vendor's products, sales representatives often subtly restructure the requirements to match the strengths of the vendor's products. Although the revised requirements can initially appear logical and acceptable; the system often does not perform after installation. .

    Finally, when alternative solutions from sev- eral vendors have been obtained, the formal proposals that serve as the basis of the acquisi- tion contract usually are not directly compara-

    40 Fall 1984

    Dow

    nloa

    ded

    by [

    Cor

    nell

    Uni

    vers

    ity L

    ibra

    ry]

    at 0

    2:15

    19

    Nov

    embe

    r 20

    14

  • How to Develop Effective RFPs

    ble. The user must try to rework the vendors' subtly reinforcing their products and often recommendations into formats suitable for com- downgrading their competitors. This informa- parison and evaluation. tion can confuse decision making on final re-

    quirements and can bias evaluations. When an These problems can be minimized using RFp is used, the detailed requirements and

    a request for ~ r o ~ o s ~ l (RFP) proposals Specifications are developed before vendon are from vendors for systems that satisfy an 'Qani- contacted to eliminate the potential bias of out- zation's specific requirements. An RFP is a for- side sources. ma1 document given to a11 vendors identified as having cornput& systems that can potentially satisfy user needs. The RFP contains a11 the in-

    - formation a vendor needs to configure a system and quote acquisition and operation costs. Vendors use the RFP to decide whether their products and resources satisfy the requirements and, if so, to structure an efficient and econom- ic solution.

    Advantages of an RFP An RFP is preferable to informal methods of

    computer system identification and selection because it provides the benefits discussed in the following sections.

    Detailed Requirements and Specifications

    The most important advantage of an RFP is that users are forced to identify and communi- cate their needs and requirements in enough detail for the vendors to configure a system. Even if RFP development ends with the prepa- ration of the detailed requirements and specifi- cations, this process alone can highlight any omissions, misunderstandings, logical anoma- lies, and unreasonable requests. In addition, documentation for external purposes is pre- pared more carefully, completely, and accu- rately than internal correspondence. Detailed and accurate requirements increase an organi- zation's chances of selecting a successful com- puter system.

    Unbiased Evaluations

    An RFP also enables users to define their needs and requirements without being influ- enced by incompatible biases. Computer selec- tion usually starts with a cursory determination of requirements. Several vendors are contacted to determine whether the requirements are fea- sible and, if so, what additional needs can be satisfied. The vendors then each suggest differ- ent approaches to meeting the requirements,

    Consistent Information

    Because verbal communication between us- ers and vendors is generally unstructured, infor- mation may be distorted or incomplete. Verbal information given to the various vendors is usu- ally inconsistent, making proposal comparisons difficult because existing information must be reworked or additional information acquired. An RFP ensures that all vendors are provided with identical' information. This advantage is significant when numerous proposals must be evaluated.

    Another difficulty with providing require- ments verbally is that vendors can innocently (or intentionally) misunderstand the inforrna- tion or deny receiving the requirements if a sys- tem does not perform as expected. An RFP is the only way the user can document that the vendor has received accurate and complete information.

    Standardized Vendor Proposals

    Another advantage of an RFP concerns the evaluation of competing vendor proposals. Most vendors structure proposals according to their perception of what would be most advan- tageous to their products and services. If the format of the proposal is specified in the RI-P, however, weaknesses cannot be concealed and proposals that do not meet the user's specifica- tions can be rejected. Proposals that conform to the format can be compared more easily and accurately.

    In addition, the time vendors take to com- plete and submit proposals varies. When a deadline is set for the receipt of proposals, the evaluation can begin at a definite time and ven- dors cannot claim time limitations were unspecified.

    Quality o f Vendor Proposals

    An RFP forces vendors to respond to the re- quirements as defined by the user. Because a

    Fall 1984 41

    Dow

    nloa

    ded

    by [

    Cor

    nell

    Uni

    vers

    ity L

    ibra

    ry]

    at 0

    2:15

    19

    Nov

    embe

    r 20

    14

  • single product or service rarely satisfies all user requirements, vendors usually attempt to adjust the user needs to match the strengths of their product or service. If user requirements and vendor proposals are handled informally, the user can be easily influenced by the vendor. If , however, user requirements are detailed in a formal written document, the vendor must at- tempt to configure the products or services to meet user expectations as closely as possible. Consequently, an RFP can elicit higher-quality proposals from the user's standpoint.

    Increased User Preparation A psychological advantage is offered by an

    RFP in that, after defining requirements and specifications and incorporating them in a writ- ten document, the user appears well prepared and less likely to succumb to sales pressure. Vendors recognize that the user can make in- formed decisions on the validity and acceptabil- ity of their proposals and therefore concentrate on structuring a proposal that addresses the us- er needs at the most advantageous price.

    Disadvantages of an RFP Although an RFPxan be effective in system

    selection, its disadvantages must also be considered in the decision to use it.

    Extensive User Involvement An RFP mandates extensive user involve-

    ment, a major disadvantage. Theoretically, in- dividual user involvement is always an integral part' of system selection. In practice, however, these users seldom participate in determining their own needs and the subsequent develop- ment of system requirements and specifica- tions. The users are either unaware of the detail needed to define system requirements, or the MIS staff assumes that the users can readily provide this information. Although increased user involvement is clearly an advantage in es-

    the user organization. At a minimum, expenses include copying costs, paper, binders, enve- lopes, and postage to produce and mail copies of the RFP. If clerical resources are scarce, tem- porary or part-time employees may be needed to type and duplicate the RFP. Telephone charges may also increase as a result of identify- ing and contacting potential vendors.

    Outside Consultation Another disadvantage of an RFP is that out-

    side consultants may be needed if the user lacks the expertise to identify, coliect, and structure the information of an RFP for a sophisticated system.

    Increased Vendor Communication The use of an RFP can also necessitate in-

    creased communication with vendors. Vendors often try to modify the system requirements and specifications, to ascertain the acceptable system price range, and to uncover information on competing proposals. This communication is not critical and actually tends to be a nuisance, especially as the deadline for submitting pro- posals approaches.

    Vendor Pressure The final disadvantage of an RFP occurs in-

    frequently but is difficult to resolve tactfully. Oc- casionally, vendors can pressure the senior management of the user organization. A ven- dor may request that the RFP be modified to the,advantage of the vendor or may downplay the value of using an RFP. In most of these cases, vendors believe that their proposals are seriously deficient and are trying to win the ac- count at any cost. Unfortunately, little can be done to counteract vendor pressure; user se- nior management can be reminded that such action is unethical and indicates that the ven- dor's product may be inferior.

    tablishing system requirements and specifica- tions, it is also costly and time-consuming. Contents of an RFP

    Increased Costs The major section of an RFP is the user's re- quirements and specifications for computer The use of an RFP increases expenses. The ~ " ~ ~ o r t . Several other components, however,

    cost of preparing and distributing an RFP var- are necessary or desirable for the RFP to have a ies, depending on the resources available within maximum impact on vendors.

    Dow

    nloa

    ded

    by [

    Cor

    nell

    Uni

    vers

    ity L

    ibra

    ry]

    at 0

    2:15

    19

    Nov

    embe

    r 20

    14

  • How to Develop Effective RFPs

    Cover Letter

    Generally, a cover letter should be included that identifies the purpose of the RFP, specifies the deadline for submitting proposals or no-bid notices, summarizes the major features of the system being sought, specifies the rules of pro- posal submission, and identifies the liaison be- tween vendors and the user.

    General Informa tion

    The first section of the RFP should contain all general information and explain the proce- dure that will be used for system selection, as described in the following.

    RFP Structure. The structure of the RFP should be described by an annotated table of contents to alert the vendor to the sequence and importance of the RFP sections.

    RFP Objective. The objective of an RFP is straightforward: it solicits proposals for sys- tems that will accurately address user needs at the most advantageous price.

    System Description. This conceptual description outlines objectives and operations, including specific limitations on acceptable op- tions.' Vendors can use this brief overview of the requirements and specifications section to

    identify user expectations and to determine whether their products or services are suitable.

    Proposal Evaluation Criteria and Pro- cedures. Proposal evaluation criteria and Pro- cedures are the factors and steps involved in se- lecting a final system. Vendors must understand how their proposals will be evalu- ated so that they can tailor their configurations accordingly. Although any one system rarely meets each requirement and specification, a vendor that is familiar with the user's RFP eval- uation criteria can include incentives that mini- mize system weaknesses and improve the over- all proposal. The objective of the RFP is not to penalize vendors arbitrarily, but to encourage them to propose their best alternative.

    Timetable. A timetable of events specifies deadlines for all the steps in system selection and installation (see Exhibit 1). The critical milestone is the deadline for receiving vendor proposals. To ensure that the vendors have ad- equate time to understand the RFP and forrnu- late an appropriate proposal, a minimum of 60 days should be allowed between the releast! of the RFP and the deadline for submitting proposals.

    User Contacts. The user should specify a representative for the vendor to contact for fur- ther clarification of the RFP. Any limitations on

    EXHIBIT 1 Sample Timetable

    Activity Completion Date

    Release of RFP April 1, 19XX Receipt of vendor proposals June 1, 19XX First phase of proposal evaluation June 21, 19XX Second phase of proposal evaluation July 31, 19XX Contract negotiations August 31, 19XX Detailed system and programming specifications September 15, 19XX Approval of specifications September 30, 19XX Program development and modifications January 31, t9XY System demonstration and approval February 14, 19XY

    ' Site preparation February 14, 19XY Hardware delivery (plus or minus five days) February 21, 19XY Hardware and operating software installation March 1, 19XY User training March 1 , 1 9XY Application software package installation ' March 15, 19XY Data conversion March 31, 19XY Parallel operation and acceptance testing April 30, 19XY

    Fall 1984 43

    Dow

    nloa

    ded

    by [

    Cor

    nell

    Uni

    vers

    ity L

    ibra

    ry]

    at 0

    2:15

    19

    Nov

    embe

    r 20

    14

  • JOURNAL 06 IrlK)RMATION SYSTEMS MAl7ACEMENT

    when or how the user representative may be once the system is installed, the minimum ac- contacted should also be indicated. ceptable levels of service and support must be

    specified in the RFP. Statement of Confidentiality. Finally,

    the general information section should clearly To avoid selecting a vendor that will not state that the RFP is confidential and must not make the necessary contract concessions, the be disclosed to individuals outside the vendor should ensure that the RFP specify the organization without user approval. The confi- ~0"hact~'I ~rotections expected from the ven- dentiality statement should also stipulate that do'. Contract protection and inclusions are the RFP can be used only by vendor personnel and vary for each user; the general working on the development of a proposal. rule is to reference all contract inclusions that

    protect the user in the RFP.

    User Background Proposal Content Requirements The next section of the RFp should provide The last section of the RFP-proposal con-

    a general background on the user organization, tent requirements-itemizes the information including its business, functional structure, his- needed to ensure adequate proposal evalua- t o r ~ 1 need for computer support, and projected tion. This information supplements the detailed future growth as well as other information that hardware and software descriptions in the re- vendors can use to evaluate user requirements q,irements and specifications section, Content and specifications in the context of the organi- requirements generally correspond to the major ~ a t ~ o n ' s business philosophy and operation- component groupings: system, hard-

    ware, and operating and applications software Requirements and Specifications requirements. An additional section should be

    included for vendor organization requirements System requirements and specifications are and the content and format of price quotations.

    the of the RFP and the Section of (See box for a sample proposal content require- concern to vendors. The quality of this informa- ments section.) tion determines the suitability of the proposals that will be received. The requirements and specifications section is often divided into three RFP Preparation categories: overall system specifications, de- Determ jn ins User Needs tailed application requirements, and descrip- tions of desirable and future applications. Over- The malor activity in RFP preparation is de- all systems specifications address: termining user needs and developing related re- . Specific equipment needs (e.g., interfaces quirements and specifications. This complex

    process control mechanisms or special corn- task requires a large amount of time and effort munications interfaces) and significantly affects the final system. A dis- Typical system architecture requirements cussion on determining user needs is beyond System software (e .g., operating systems, the scope of this article, h~wever . utility programs, and programming languages) Establishing the Evalua tion Criteria Vendor service and support and Method Contract provisions The primary criterion for evaluating vendor Service and support considerations include proposals is whether the proposed system satis-

    the type of maintenance acceptable for hard- fies all system requirements and specifications. ware and software problems, who provides the Proposals that meet this criterion must be fur- service, the maximum response time, and pro- ther evaluated by other criteria. Generally, a cedures for acquiring outside expertise when a weight value is assigned to each proposal, de- problem cannot be solved at the local level. pending on how well it meets the requirements Service and support vary among vendors and and specifications for each required application. different geographic locations of the same ven- The sum of the weight values for each proposal dor. Because the user cannot be sure that the can then be directly compared. Other consider- vendor will stand by any verbal assurances ations in evaluating the proposals include sys-

    44 Fall 1984

    Dow

    nloa

    ded

    by [

    Cor

    nell

    Uni

    vers

    ity L

    ibra

    ry]

    at 0

    2:15

    19

    Nov

    embe

    r 20

    14

  • How to Develop Effective RFPs

    P!oposal Content ReCjuirementsV'~ndQ' R~qulu~m.nu

    1. How long haS thc vend bnn 1tI buSltlf.MlZ. Wh4 t II m. \I9lldors eu ...nt annu.! saIa~?

    N t InWmot>3 . Wh.u" the num~l Of emp~?4 Wh.>r vendor Iocancn IoUOUId $oOmriCe INs pro;m?S. How nwn."e~ llIe III ttus wrvlQ loc:arlon'6 How m./ln!.' Ol. Ih..,., otmp~ ere soitw""c pro-

    !nIlonals? H..vd\o./ltOl' SOl'fV'O! pcnomwd? Wh.ar osIhot a",~ ppc1l11l1Ce ,,"'II 01 orach~

    1 Huw m.ny penonn..1 WIll be: ass>gnad to lhr5proim" Wtw lhe sJulilorvel 01 rhi.s group? Wh.sIwould b. motll a"'otr.-go: II.m'I eommllmcnt to Ihorpro,om?

    8 . Wh.51" the _. rlHpOf'W 11..... fCI~ hord....a.Ol'WfV"? Sot!watlt suppott?

    9. b the IItndox ppnWllud IN1th ,yslcrm $imlt,.,. tothc .OtUI oul!notd?

    10 PLta.w ~ fIv'I w .... nl clmlS {p. cf", ably wi!h op-" .KIOOS Andrcqw rerncnlS 1Imllar to lh.~'Y'l"ml who tan be ecmeaed,

    OYi'rall S~t~'" R~qullf'm~nbI , Has thill'tardw.u" andaoftw.uc eornbt'Flllt!on been

    Ill'lt..n...d al ottwr Iocallo~? If to, how m",ny?'"z,,; How mlK/\ tUoltOmIZQIIOn II reqUlrw (",sllmahd'3 . Arc programs mOOuw and TlI/o(.,t abL.r?4 How meny programs art lnllOlwd In Ih" lYlftm?

    :a' s: W h at b ...ek up ' an d le eov "" y lIf(:hniquts ",,,Included?-Can nlla wnrlgur"tJoM boI uwd as IMoc:kup fa..(:11,111/11' It 10. whorror . re they Iocalwd?Whoal 4I"e tlW '''P''n~ ~r.lJ,"?AIo! DP profnoonals needed 10 op4lrate lhc'y"em?

    9. WIw ~ lr4in lng. 1s prtWMttd? Wh e n? Wlw, c?For how long? AI what roll?

    10 a,. 'Y'rem. progoam. and opcr.Uonal dOCl.urnrntan 4Vllllablor?

    n . I, U'lolirr dOairricnr"bOn 4....l.IJablOl? In wtl.at form'How compior1,,?

    12. Wh.JI ..".hlm wrncc a nd IoOftWIltOll ,uP()OI' ~ofl ..l'Ird'

    13. What IN "'llpiCto>d nDpOIlM tlmw for lolIf\Iicc'For ~ftwMe ~VPO'"

    H.rdw". and Opon-"Ung Softw.ro, Rcq\lirc".~"t.

    1 How long hoIItIw proposed ha rd........-" bun uwdcomnhlrd.'tlly'

    2. WhcI Is fh.o! numborr of wrrent UKnI'3 Wh.,1 Is !he moran l! rneber....eenf,lur~ hisrory of

    the m"fOl" compofUrnlS1.. Wh.... M~ lhe e"p-'ns!on capo>billrws of the h.ud

    .... M II1Cludmg m4ln 4I1d disk ~or"!l.'" ....d lhotnumb~r of d" "leOlS c. p"ble o f op"rallngeoncu "Ol'nlfy?

    5 hall h4I d ....""" ""'lin pd by on'" 'IOUrc. '6 . H.u In. h.ue nvl.onmcnl'7 Is IhO' OporT" llft9 IOltw ll, e uniqUOl!' 10 the propowd

    modei ee appkabk 10 oth"T", ndcr offen n'1l?8 Wtloll L,"'Ju~ ,}.rOll wpport",d?9 Wh.1l ...... thl! DBMS up..blftun ? Ho.... man!.' rl!o>s

    al l" portm,ltecl'? Wh al ~ th.. mw mum rlle ~l!'Rl'Cord we?

    10 Pu. Inqully.and r" P'K1 9"n".aI0l' ophons "v" lidblo,.....,In In", DBMS?

    I I How muda ovCfhco.d docs the opcorallng IY$lIffTlNqUiriJ'

    12. Whet h the tun...t dell-ry fOHQN ,.,.. the pr~posed hlard....~

    13 . Don th. hMdware op....at. III a ~pical otr 'e"~_mom?

    Application_ Solfw.tor Requirement,1 Does thil!' pfOPO"d ""''"" melud. lOll"""'. poKk

    "9'"" Qrigjnally ....rinom lor anoll'ktr o.~n1UlllOn' (Ifto. ~fy)

    2 How many ollwr eIlotn", at.. U~lng V"fSIOn, ofth..propoHd

  • JOURNAL OF IflfORMATIOfI SYSTfMS MANRGCMCIYT

    tem price, the vendor's commitment to service and support and willingness to negotiate on contract terms, and features that have been in- cluded beyond those that satisfy the mandatory applications requirements and specifications.

    Once the evaluation criteria have been es- tablished, the timetable of events can be devel- oped. At a minimum, milestones should include:

    Receipt of the proposals Completion of the first phase of proposal evaluation Performance of on-site visits and demon- strations Completion of the second phase of proposal evaluation Execution of contract negotiations Approval of the contracts

    If the timetable is extended through system in- stallation, milestones should be set for the following:

    Approval of the application system design Completion of all programming Approval of the system demonstration Completion of user training Installation of the system Completion of data conversion and accep- tance testing Acceptance of the operational system.

    Writing the RFP The only guideline for writing an RFP is clar-

    ity, simplicity, and brevity. Vendors must be able to interpret the information exactly as the user does. Requirements can be clearly convey- ed in short, simple sentences. Although the use of industry-specific jargon should be avoided, unambiguous computer terms can be used. Be- cause such terminology may be needed, the systems development manager should be ac- tively involved in writing the RFP.

    The two most commonly used formats for RFPs are narratives and lists with charts, dia- grams, and truth tables. Generally, narratives are used to provide information in a specific context. The user's background, for example, is presented narratively to give the reader an ac- curate overview of the organization. The overall expected operation of an applicz'ion system is also commonly presented in a narrative to de- tail the flow of information and functions. Nar- rative presentations, however, tend to be long,

    and important points buried in the text may be overlooked.

    System requirements and specifications are presented most effectively in lists, which set these points off from other material. Because lists can be referenced easily and repeatedly, the reader does not have to make separate notes or reread narrative passages. For empha- sis, important requirements can be presented in narrative form and then restated in a list. Com- plex information is more easily explained through illustrations, charts, graphs, or diagrams.

    RFP Distribution The objective of an RFP is to receive as

    many vendor proposals as possible and then to determine how the systems interact with users. Because only one in three vendors that receive an RFP generally respond with a proposal, at least fifteen vendors should be solicited to en- sure a meaningful response. Vendors can be identified through recommendations from col- leagues, magazine advertisements, telephone directories, and conventions. Before an RFP is released, vendor sales representatives should be contacted to determine whether the vendor is interested in submitting a proposal and able to provide the appropriate support. Contact with the sales representative also ensures that the RFP will not be ignored or discarded.

    Role of the Systems Development Manager

    The systems development manager plays a pivotal role in the entire RFP process and there- fore has a major effect on the quality of the sys- tem that is ultimately selected. When an organi- zation uses RFPs for system selection, the systems development manager serves as a liai- son between the user and the vendors. First, the systems development manager helps indi- vidual users define their requirements. Many users are inexperienced in determining their needs in sufficient detail to develop adequate requirements and specifications. The systems development manager can guide the users dur- ing the requirements analysis and RFP development.

    The systems development manager also

    46 Fall 1984

    Dow

    nloa

    ded

    by [

    Cor

    nell

    Uni

    vers

    ity L

    ibra

    ry]

    at 0

    2:15

    19

    Nov

    embe

    r 20

    14

  • How to Develop Effective RFPs

    provides the technical expertise and informa- tion required to translate the individual users' application requirements into hardware and software requirements that are compatible with the organization's existing and planned comput- er capabilities. User needs are built into a hard- ware and software structure that is detailed enough to develop concrete proposals but flexi- ble enough to encourage creative solutions.

    Another responsibility of the systems devel- opment manager is the preparation and distri- bution of the RFP. The systems development

    manager is usually most familiar with the pro- spective vendors and with the specialized terrni- nology required to present the system require- ments and specifications clearly.

    The systems development manager can also respond most effectively to vendor questions and requests that arise during RFP evaluation. Users must often rely on the systems develop- ment manager to translate certain sections of the vendor proposals and to determine whether. the proposed hardware and software satisfy the system requirements and specifications.

    Fall 1984 47

    Dow

    nloa

    ded

    by [

    Cor

    nell

    Uni

    vers

    ity L

    ibra

    ry]

    at 0

    2:15

    19

    Nov

    embe

    r 20

    14