How to Develop Effective RFPs

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/uism19

http://www.tandfonline.com/action/showCitFormats?doi=10.1080/07399018408963060

http://dx.doi.org/10.1080/07399018408963060

http://www.tandfonline.com/page/terms-and-conditions

http://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 selection 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 vendors. 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 address user requirements that are not advantageous to their products or services. If user requirements 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 several vendors have been obtained, the formal proposals that serve as the basis of the acquisition 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 communicate their needs and requirements in enough detail for the vendors to configure a system. Even if RFP development ends with the preparation of the detailed requirements and specifications, this process alone can highlight any omissions, misunderstandings, logical anoma- lies, and unreasonable requests. In addition, documentation for external purposes is prepared more carefully, completely, and accurately than internal correspondence. Detailed and accurate requirements increase an organization's chances of selecting a successful computer system.

Unbiased Evaluations

An RFP also enables users to define their needs and requirements without being influenced by incompatible biases. Computer selection 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 different approaches to meeting the requirements,

Consistent Information

Because verbal communication between users and vendors is generally unstructured, information may be distorted or incomplete. Verbal information given to the various vendors is usually 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 requirements verbally is that vendors can innocently (or intentionally) misunderstand the inforrna- tion or deny receiving the requirements if a system 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 advantageous 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 specifications can be rejected. Proposals that conform to the format can be compared more easily and accurately.

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

Quality o f Vendor Proposals

An RFP forces vendors to respond to the requirements 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 attempt 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 written 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 user 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, individual 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 development of system requirements and specifications. 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 proposals 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 vendor 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 senior management can be reminded that such action is unethical and indicates that the vendor's product may be inferior.

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

Increased Costs The major section of an RFP is the user's requirements 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


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 proposal submission, and identifies the liaison between 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 systems 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 selecting a final system. Vendors must understand how their proposals will be evaluated 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 evaluation criteria can include incentives that mini- mize system weaknesses and improve the overall 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 adequate 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 descriptions 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


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

1. How long haS thc vend« bnn 1tI buSltlf.MlZ. Wh4 t II m. \I9lldor·s 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~nb

I , Has thill'tardw.u" andaoftw.uc eornbt'Flllt!on beenIll'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.urnrnta·n 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! rne·ber....een·f,»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 p<ovido>d by on'" 'IOUrc. '6 . H.u In. h.u<!w.lfC bft: n USO!d In a com munic...llOrn.

e 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 <lppbllon.lOitwarc' Coin. hI of CQIl

~ be prQWJwd?3 . II. toft ....ere d~lopm",nl or m<1olhllutlon n edo!d

(adm.lll'I)?4 . AN the progrllm mcn ollh" Oflgl""r ..ppkllilool\

K.ftwarc SlID .vailable'5. Wh at Ianguegn are uwd"?6. An thll!N~ 0" hili !NIl'

7 DoCs th.- $OhWIlN hll"'" <k-v..... 'ncMJ)'ncMnt lil..t.'8 Heve th. IIppbtlon p«k.ogu ~n Ullo!rfdC"d 10

the propowd DBMS?9. wto...l~ ani rnada foo- con.amq aoftwar"

dorfOl'Cts?10. Is II softw~e m.mwn.nQ cqtC<Imornl ....aoIabIor'

At ......-.t cos(!'f"11. Who rmr*tm" nt. the toItvJl/Jui~

12. What trall'llng 1$IIVlldablc?13 Is IOUIWmdlIt ....Oil.oble?'14 c.. 'aha- M,h\llA.rll! openk on othcT ~w.,..?

IS.mples of ...va tlllble OUIPUI .nd kIINn form 15~ a.ko be- l/'dlded.}

Prlc:e Quot.ttona and Supporting lnlon,ultlonH ..rd....r r

Mod,,' nurnbW~ of mmpo<'l"nlQwntlly propowd

"""'"'"-T\o'P'" of s._. if Appkablor:[,t,mated freight cIlargatnllallction Charge. If appk.tJleDls«tunt . if awlublcNd purcha.w 4Il'lOUtItNO', lea.. amount~on1h/y ma,,wn.,)n(c dWlr9"Oel.lled , plIo-fle"tlons . nd p.oduct blulltur~ .

lncludll>g'

.......~~~§~~~~~~~CapacityCom""llbIlity....~".."''YR• .......,

F"~

S..,lt .....

AppllCalion d"5Crl~<k>~"~~:;;~=.~;~~;PUTeh""" or d",,,,,,lopme"l emMo.;MIc.allon c~ll

Mon th ly lIc",n$1I eO'il "ndICat. ....h...thol, thll eh",'1l" ror

pl.1cn the PUTC~ eost or II. Wp.1~~':":'~',:===;:In" .. II" llon eh"'9". If ",ppkabkr _Sol'""arol' ma lO' e nanc ", c h.lTgO'" If "ppHeabl"

Othn costs {qual' and d"tCl1bel

Fall 19B.. 4S

Dow

nloa

ded

by [

Cor

nell

Uni

vers

ity L

ibra

ry]

at 0

2:15

19

Nov

embe

r 20

14

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 included beyond those that satisfy the mandatory applications requirements and specifications.

Once the evaluation criteria have been es- tablished, the timetable of events can be developed. 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 installation, 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 acceptance 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, diagrams, 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 accurate overview of the organization. The overall expected operation of an applicz'ion system is also commonly presented in a narrative to detail 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 ensure 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 therefore has a major effect on the quality of the system that is ultimately selected. When an organization uses RFPs for system selection, the systems development manager serves as a liaison between the user and the vendors. First, the systems development manager helps individual 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 during 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


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

Another responsibility of the systems development manager is the preparation and distribution 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 requirements 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 development 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

Documents

How to Develop Effective RFPs